[lng-odp] [PATCH API-NEXT v6 1/1] api: ipsec: rework ODP_IPSEC_SA_DISABLE into warning bit

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

It is expected that platforms that are not able to support
odp_ipsec_sa_disable() status result in a form of separate event will
set SA hard expiry time to 0, submit a dummy packet to that SA. Then
after receiving this packet after IPsec processing (which should result
in hard expiry breach) odp_ipsec_result() will detect this packet
through the combination of hard_expiry, size, contents, etc and will
report it as a packet with odp_ipsec_warn_t->sa_disabled bit set.

Signed-off-by: Dmitry Eremin-Solenikov 
Cc: Nikhil Agarwal 
Cc: Balasubramanian Manoharan 
---
/** Email created from pull request 197 (lumag:ipsec_sa_disable_proposal)
 ** https://github.com/Linaro/odp/pull/197
 ** Patch: https://github.com/Linaro/odp/pull/197.patch
 ** Base sha: 60a1a4f1cc531d7f0117cd79daf1cbe4206e12ef
 ** Merge commit sha: d9f4c01b8bc64ca94b5efee6e33be711c423b766
 **/
 include/odp/api/spec/ipsec.h | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 3bd80b266..bd62875ef 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -839,8 +839,10 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
odp_ipsec_sa_param_t *param);
  *
  * When in synchronous operation mode, the call will return when it's possible
  * to destroy the SA. In asynchronous mode, the same is indicated by an
- * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA. The
- * status event is guaranteed to be the last event for the SA, i.e. all
+ * sa_disabled bit in odp_ipsec_warn_t. Warning can be delivered either by an
+ * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA or by
+ * a packet having this bit set in corresponding odp_ipsec_result_t instance.
+ * This warning is guaranteed to be the last event for the SA, i.e. all
  * in-progress operations have completed and resulting events (including status
  * events) have been enqueued before it.
  *
@@ -923,7 +925,12 @@ typedef struct odp_ipsec_error_t {
 
 } odp_ipsec_error_t;
 
-/** IPSEC warnings */
+/** IPSEC warnings
+ *
+ * For outbound SAs in ODP_IPSEC_OP_MODE_INLINE mode warnings can be reported
+ * only as status events. In all other cases warnings can be reported either as
+ * a part of packet result or via separate ODP status event.
+ */
 typedef struct odp_ipsec_warn_t {
/** IPSEC warnings */
union {
@@ -934,6 +941,9 @@ typedef struct odp_ipsec_warn_t {
 
/** Soft lifetime expired: packets */
uint32_t soft_exp_packets : 1;
+
+   /** SA was disabled */
+   uint32_t sa_disabled : 1;
};
 
/** All warnings bits */
@@ -1129,26 +1139,14 @@ typedef struct odp_ipsec_packet_result_t {
  * IPSEC status ID
  */
 typedef enum odp_ipsec_status_id_t {
-   /** Response to SA disable command
-*
-*  Following status event (odp_ipsec_status_t) fields have valid
-*  content, other fields must be ignored:
-*  - sa:   The SA that was requested to be disabled
-*  - result:   Operation result
-*/
-   ODP_IPSEC_STATUS_SA_DISABLE = 0,
-
/** Warning from inline IPSEC processing
 *
 *  Following status event (odp_ipsec_status_t) fields have valid
 *  content, other fields must be ignored:
 *  - sa:   The SA that caused the warning
 *  - warn: The warning(s) reported by this event
-*
-*  This status event is generated only for outbound SAs in
-*  ODP_IPSEC_OP_MODE_INLINE mode.
 */
-   ODP_IPSEC_STATUS_WARN
+   ODP_IPSEC_STATUS_WARN = 0,
 
 } odp_ipsec_status_id_t;
 

[lng-odp] [PATCH API-NEXT v6 0/1] api: ipsec: rework ODP_IPSEC_SA_DISABLE into warning bit

[Github ODP bot]

It is expected that platforms that are not able to support
odp_ipsec_sa_disable() status result in a form of separate event will
set SA hard expiry time to 0, submit a dummy packet to that SA. Then
after receiving this packet after IPsec processing (which should result
in hard expiry breach) odp_ipsec_result() will detect this packet
through the combination of hard_expiry, size, contents, etc and will
report it as a packet with odp_ipsec_warn_t->sa_disabled bit set.
Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org
Cc: Nikhil Agarwal nikhil.agar...@linaro.org
Cc: Balasubramanian Manoharan bala.manoha...@linaro.org

github
/** Email created from pull request 197 (lumag:ipsec_sa_disable_proposal)
 ** https://github.com/Linaro/odp/pull/197
 ** Patch: https://github.com/Linaro/odp/pull/197.patch
 ** Base sha: 60a1a4f1cc531d7f0117cd79daf1cbe4206e12ef
 ** Merge commit sha: d9f4c01b8bc64ca94b5efee6e33be711c423b766
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 61 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] Moving scalable scheduler to master

[Bill Fischofer]

I've looked over the code and the biggest issue surrounds the use of
#ifdefs in open code. The issue is that the scheduler behaves
significantly different based on whether it's running on AArch64 vs.
other architectures. This means that code coverage is dependent on the
target platform.

>From a modularization standpoint we're going to need to split this up
so that the architecture paths are more dynamic.

The key file for setting this up is
platform/linux-generic/include/odp_schedule_scalable_config.h where
the key lines are:

/*
* Split queue producer/consumer metadata into separate cache lines.
* This is beneficial on e.g. Cortex-A57 but not so much on A53.
*/
#define CONFIG_SPLIT_PRODCONS
/*
* Use locks to protect queue (ring buffer) and scheduler state updates
* On x86, this decreases overhead noticeably.
*/
#if !defined(__arm__) && !defined(__aarch64__)
#define CONFIG_QSCHST_LOCK
/* Keep all ring buffer/qschst data together when using locks */
#undef CONFIG_SPLIT_PRODCONS
#endif

An example problematic section is:

#ifndef CONFIG_QSCHST_LOCK
/* The scheduler is the only entity that performs the dequeue from a queue. */
static void
sched_update_deq(sched_elem_t *q,
uint32_t actual,
bool atomic) __attribute__((always_inline));
static inline void
sched_update_deq(sched_elem_t *q,
uint32_t actual, bool atomic)
{
qschedstate_t oss, nss;
uint32_t ticket;

...
}
#endif

#ifdef CONFIG_QSCHST_LOCK
static void
sched_update_deq_sc(sched_elem_t *q,
  uint32_t actual,
  bool atomic)
__attribute__((always_inline));
static inline void
sched_update_deq_sc(sched_elem_t *q,
 uint32_t actual, bool atomic)
{
qschedstate_t oss, nss;
uint32_t ticket;

...
}
#endif

Where two different routines are defined depending on the architecture
and then the reset of the code refers to one or the other, again using
#ifdefs:

static inline void _schedule_release_atomic(sched_scalable_thread_state_t *ts)
{
#ifdef CONFIG_QSCHST_LOCK
sched_update_deq_sc(ts->atomq, ts->dequeued, true);
ODP_ASSERT(ts->atomq->qschst.cur_ticket != ts->ticket);
ODP_ASSERT(ts->atomq->qschst.cur_ticket ==
 ts->atomq->qschst.nxt_ticket);
#else
sched_update_deq(ts->atomq, ts->dequeued, true);
#endif
ts->atomq = NULL;
ts->ticket = TICKET_INVALID;
}

In general, we shouldn't have name variants and this sort of
conditional compilation. If sched_update_deq() should behave
differently based on architecture then that should be contained within
that routine rather than cascading into the main code. Ideally these
variants should be factored into an arch subdirectory.

#ifdefs also cause problems with maintenance because the compiler
doesn't see all code paths (only those selected by the #ifdefs). So I
may inadvertently make a change on one code path that breaks the other
code path but I don't detect that.

A way to avoid this problem is to replace the #ifdefs with inlined
functions. For example instead of:

#ifdef PREDICATE
some code
#else
some other code
#endif

Using a function:

if (predicate_function()) {
some code
} else {
some other code
}

We can have predicate_function() evaluate to 0 or 1 statically based
on the target architecture so there's no loss of efficiency compared
to #ifdefs but all code is always compiled so a single compile pass
can check all configuration variations for errors.

[lng-odp] [Linaro/odp] 90c3fd: api: packet_io: add MAC address set function

[GitHub]

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 90c3fdd7124ad1ed887fa6b09b7665a39021e895
  
https://github.com/Linaro/odp/commit/90c3fdd7124ad1ed887fa6b09b7665a39021e895
  Author: Bogdan Pricope 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M include/odp/api/spec/packet_io.h

  Log Message:
  ---
  api: packet_io: add MAC address set function

Add support for setting default MAC address of a
packet IO interface and for reporting availability
of this operation.

Signed-off-by: Bogdan Pricope 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 2fb72324f0a247ffb800b54f112eb75716b42c22
  
https://github.com/Linaro/odp/commit/2fb72324f0a247ffb800b54f112eb75716b42c22
  Author: Bogdan Pricope 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/include/odp_packet_io_internal.h
M platform/linux-generic/odp_packet_io.c
M platform/linux-generic/pktio/dpdk.c
M platform/linux-generic/pktio/ipc.c
M platform/linux-generic/pktio/loop.c
M platform/linux-generic/pktio/netmap.c
M platform/linux-generic/pktio/pcap.c
M platform/linux-generic/pktio/socket.c
M platform/linux-generic/pktio/socket_mmap.c
M platform/linux-generic/pktio/tap.c

  Log Message:
  ---
  linux-gen: pktio: implement MAC address set function

Add implement of MAC address set API. It calls packet IO
specific MAC address set function.

Signed-off-by: Bogdan Pricope 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 60a1a4f1cc531d7f0117cd79daf1cbe4206e12ef
  
https://github.com/Linaro/odp/commit/60a1a4f1cc531d7f0117cd79daf1cbe4206e12ef
  Author: Bogdan Pricope 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M test/common_plat/validation/api/pktio/pktio.c

  Log Message:
  ---
  test: validation: pktio: validate MAC address set function

Add validation tests for MAC address set API.

Signed-off-by: Bogdan Pricope 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/9d65b4659d98...60a1a4f1cc53

[lng-odp] [Linaro/odp] d340de: test: packet: remove references to odp_packet_unsh...

[GitHub]

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: d340de6d0a6002d7f145d278ccf18d4c9c9b233d
  
https://github.com/Linaro/odp/commit/d340de6d0a6002d7f145d278ccf18d4c9c9b233d
  Author: Bill Fischofer 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M test/common_plat/performance/odp_bench_packet.c
M test/common_plat/validation/api/packet/packet.c

  Log Message:
  ---
  test: packet: remove references to odp_packet_unshared_len()

Signed-off-by: Bill Fischofer 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Petri Savolainen 
Reviewed-by: Nikhil Agarwal 
Signed-off-by: Maxim Uvarov 


  Commit: beff45d25a614e7b4c84fc734fc588f1c26bb8c4
  
https://github.com/Linaro/odp/commit/beff45d25a614e7b4c84fc734fc588f1c26bb8c4
  Author: Bill Fischofer 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/include/odp_packet_internal.h
M platform/linux-generic/odp_packet.c

  Log Message:
  ---
  linux-generic: packet: remove odp_packet_unshared_len() implementation

Signed-off-by: Bill Fischofer 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Petri Savolainen 
Reviewed-by: Nikhil Agarwal 
Signed-off-by: Maxim Uvarov 


  Commit: 39126ab23611e57d4015b376f1e7222489ca2c63
  
https://github.com/Linaro/odp/commit/39126ab23611e57d4015b376f1e7222489ca2c63
  Author: Bill Fischofer 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M include/odp/api/spec/packet.h

  Log Message:
  ---
  api: packet: remove odp_packet_unshared_len()

Signed-off-by: Bill Fischofer 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Petri Savolainen 
Reviewed-by: Nikhil Agarwal 
Signed-off-by: Maxim Uvarov 


  Commit: 9d65b4659d98c0c5c2b45c2733d7cc2ef3d13123
  
https://github.com/Linaro/odp/commit/9d65b4659d98c0c5c2b45c2733d7cc2ef3d13123
  Author: Bill Fischofer 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
R doc/images/reflen.svg
M doc/users-guide/users-guide-packet.adoc

  Log Message:
  ---
  doc: userguide: remove references to odp_packet_unshared_len()

Signed-off-by: Bill Fischofer 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Petri Savolainen 
Reviewed-by: Nikhil Agarwal 
Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/e943f8213505...9d65b4659d98

[lng-odp] [Bug 3249] odp_cpu_hz() does not work on all Linux distros

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=3249

Ilias Apalodimas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Linaro/odp] a197b3: linux-gen: chksum: correct uninitialized variable ...

[GitHub]

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: a197b3ca3ae732cb8b9aa8237e3ffd5249ecb361
  
https://github.com/Linaro/odp/commit/a197b3ca3ae732cb8b9aa8237e3ffd5249ecb361
  Author: Petri Savolainen 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/odp_chksum.c

  Log Message:
  ---
  linux-gen: chksum: correct uninitialized variable bug

Initialize left_over variable, so that the pad byte
is initialized to zero.

Signed-off-by: Petri Savolainen 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: e943f8213505508125e39bf228ba80dab1cb8378
  
https://github.com/Linaro/odp/commit/e943f8213505508125e39bf228ba80dab1cb8378
  Author: Petri Savolainen 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M test/common_plat/validation/api/chksum/chksum.c
M test/common_plat/validation/api/chksum/chksum.h

  Log Message:
  ---
  validation: chksum: add long UDP packet test

Added test for a 1517 bytes long UDP packet. The checksum is
checked using both a single call as well as multiple consecutive
calls (to emulate checksumming over fragments).

Signed-off-by: Petri Savolainen 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/bf803098eb15...e943f8213505

[lng-odp] [Linaro/odp] 7f3624: linux-gen: timer: drop odp prefix from odp_timer_p...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 7f3624154ff59ab85352c35e1c6df3c9597f9f51
  
https://github.com/Linaro/odp/commit/7f3624154ff59ab85352c35e1c6df3c9597f9f51
  Author: Maxim Uvarov 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/odp_timer.c

  Log Message:
  ---
  linux-gen: timer: drop odp prefix from odp_timer_pool_new

Internal static function does not need odp_ prefix.

Signed-off-by: Maxim Uvarov 
Reviewed-by: Bill Fischofer 


  Commit: 72a4e9f9bad9dfeaafba4e29a7450ee7edca5d1c
  
https://github.com/Linaro/odp/commit/72a4e9f9bad9dfeaafba4e29a7450ee7edca5d1c
  Author: Maxim Uvarov 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/odp_timer.c

  Log Message:
  ---
  linux-gen: timer: drop odp prefix from odp_timer_pool

internal data type should not be named with odp api prefix.

Signed-off-by: Maxim Uvarov 
Reviewed-by: Bill Fischofer 


  Commit: 3f3d7651c7cd7ba3b941904bbcbdabcac9a7dfd0
  
https://github.com/Linaro/odp/commit/3f3d7651c7cd7ba3b941904bbcbdabcac9a7dfd0
  Author: Maxim Uvarov 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/include/odp/api/plat/timer_types.h
M platform/linux-generic/odp_timer.c

  Log Message:
  ---
  linux-gen: timer: drop odp prefix from odp_timer_pool_s

internal structure should not be named with odp_. Also make
code a little bit more consistent to pass type instead of struct
to 2 more functions.

Signed-off-by: Maxim Uvarov 
Reviewed-by: Bill Fischofer 


  Commit: 5a2376365df984e160b92463be37740786a10bd6
  
https://github.com/Linaro/odp/commit/5a2376365df984e160b92463be37740786a10bd6
  Author: Maxim Uvarov 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/odp_timer.c

  Log Message:
  ---
  linux-gen: timer: drop odp prefix from odp_timer_s

Signed-off-by: Maxim Uvarov 
Reviewed-by: Bill Fischofer 


Compare: https://github.com/Linaro/odp/compare/bbefeae66a2a...5a2376365df9

[lng-odp] [Bug 3249] odp_cpu_hz() does not work on all Linux distros

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=3249

--- Comment #6 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/a08dba6c24af81142efc6176eae2bdd561b478e3
refs/heads/master
2017-10-11T18:37:11+03:00
Ilias Apalodimas ilias.apalodi...@linaro.org
linux-gen: use /proc/cpuinfo if sysfs is not available to get cpu info

PR#171 broke some of the functionality we had on getting cpu speed.
This patch reverts parts of that commit adding a fallback when
/sys/devices/system/cpu/cpuX/cpufreq/ is not available.

Solves https://bugs.linaro.org/show_bug.cgi?id=3249

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Linaro/odp] a08dba: linux-gen: use /proc/cpuinfo if sysfs is not avail...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: a08dba6c24af81142efc6176eae2bdd561b478e3
  
https://github.com/Linaro/odp/commit/a08dba6c24af81142efc6176eae2bdd561b478e3
  Author: Ilias Apalodimas 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/arch/default/odp_sysinfo_parse.c
M platform/linux-generic/arch/mips64/odp_sysinfo_parse.c
M platform/linux-generic/arch/powerpc/odp_sysinfo_parse.c
M platform/linux-generic/arch/x86/odp_sysinfo_parse.c
M platform/linux-generic/include/odp_internal.h
M platform/linux-generic/odp_system_info.c

  Log Message:
  ---
  linux-gen: use /proc/cpuinfo if sysfs is not available to get cpu info

PR#171 broke some of the functionality we had on getting cpu speed.
This patch reverts parts of that commit adding a fallback when
/sys/devices/system/cpu/cpuX/cpufreq/ is not available.

Solves https://bugs.linaro.org/show_bug.cgi?id=3249

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: bbefeae66a2a6ac6c9386bb8a083022b7f323fc9
  
https://github.com/Linaro/odp/commit/bbefeae66a2a6ac6c9386bb8a083022b7f323fc9
  Author: Ilias Apalodimas 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/arch/x86/odp_sysinfo_parse.c

  Log Message:
  ---
  linux-gen: x86: fix on odp_cpu_arch_hz_current() declaration for x86

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/1c02e217fac2...bbefeae66a2a

[lng-odp] [Linaro/odp] 1c02e2: example: use odp_sys_info_print

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 1c02e217fac2ed2d015205ad36bd86c4924ce6cc
  
https://github.com/Linaro/odp/commit/1c02e217fac2ed2d015205ad36bd86c4924ce6cc
  Author: Ilias Apalodimas 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M example/classifier/odp_classifier.c
M example/generator/odp_generator.c
M example/ipsec/odp_ipsec.c
M example/l3fwd/odp_l3fwd.c
M example/packet/odp_pktio.c
M example/switch/odp_switch.c
M example/timer/odp_timer_test.c
M test/common_plat/performance/odp_bench_packet.c
M test/common_plat/performance/odp_l2fwd.c
M test/common_plat/performance/odp_pktio_ordered.c
M test/common_plat/performance/odp_scheduling.c
M test/linux-generic/pktio_ipc/ipc_common.c

  Log Message:
  ---
  example: use odp_sys_info_print

Use unified odp_sys_info_print() instead of copying the same code
on every example.

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 

[lng-odp] [Linaro/odp] a3bc05: linux-gen: pool: avoid allocating packets which cr...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: a3bc051085b95170101a3f81379e78c48e5a636c
  
https://github.com/Linaro/odp/commit/a3bc051085b95170101a3f81379e78c48e5a636c
  Author: Matias Elo 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M platform/linux-generic/odp_pool.c

  Log Message:
  ---
  linux-gen: pool: avoid allocating packets which cross huge page boundaries

When packet pool memory page size is >= FIRST_HP_SIZE, leave those memory
buffers unused which cross page boundary. This is required by zero-copy
dpdk pktio (NIC drivers don't support buffers which cross page boundaries).

Signed-off-by: Matias Elo 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 

[lng-odp] [Linaro/odp] fa2819: test: pktio_perf: increase maximum number of worke...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: fa281989523b82177f974abe7b4adfec47705dfa
  
https://github.com/Linaro/odp/commit/fa281989523b82177f974abe7b4adfec47705dfa
  Author: Matias Elo 
  Date:   2017-10-11 (Wed, 11 Oct 2017)

  Changed paths:
M test/common_plat/performance/odp_pktio_perf.c

  Log Message:
  ---
  test: pktio_perf: increase maximum number of workers threads

Increase maximum number of workers to 128. Also, fixes a buffer overflow
which happened when system's maximum thread count  was larger than the
value of MAX_WORKERS.

Signed-off-by: Matias Elo 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 

Re: [lng-odp] Code review and discussion on mailing list only

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Savolainen, Petri (Nokia - FI/Espoo)
> Sent: Monday, October 02, 2017 5:53 PM
> To: lng-odp-forward 
> Subject: Suspected SPAM - [lng-odp] Code review and discussion on mailing
> list only
> 
> Hi,
> 
> Let's stop using Github for code review and design discussions. Mailing
> list is far more flexible and robust for human-to-human interaction than a
> web-based tool. We can continue to use Github for sending/bookkeeping pull
> requests (and run Travis on those), but all discussions should happen on
> the mailing list only.
> 
> 1) Plain text messages on the mailing list enable easy/flexible access
> (various clients, bad network connection, work offline, ...)
> 
> 2) A mail defines context (patch v3 2/7 ...) for a discussion and may
> include all comments / replies in one shot, and thus is fast to read /
> browse through. Whereas, comments on a Github web page are inherently
> scattered / mixed up, and need much more clicking / scrolling through to
> find the information. My experience is that code review on Github is 2-4x
> slower than on mails.
> 
> 3) Code review on Github is slow and has lots of issues
>* Mixes patch order in a patch series (don't see which patch is e.g.
> 1/7, 2/7, ...)
>* Mixes comments from between patches (based on file + line, so a
> comment is shown also with other patches which have the same file + line
> in context)
>* Comments are mixed between different versions of a patch set
>* No way to comment git log entry text
>* Mail <-> web page comment conversions does not produce readable mails
> or web pages. Based on scripts, but never optimal. How much context is the
> right amount? Who maintains the scripts? What if the Github API stop
> supporting things that those scripts use?
>* A long diffs in a patch does not open automatically, but reader need
> to click through those to find out if there are comments inside
>* A reviewer cannot filter out other reviewers comments, just add on
> top. Multiple comment/answer threads get mixed up on the same comment box,
> or new threads needs to be placed on artificially different but close
> together lines.
>* ... etc. End result => lots of clicking on a messy page, instead of
> getting the work done.
> 
> 
> Kernel developers use mailing lists for the same / similar reasons:
> https://lwn.net/Articles/702177/
> 
> 
> -Petri
> 

Ping.

I still think we should move discussion from Github back to the mailing list:
 * Github cannot be used for sane discussion (see above)
 * Mailing list is filled with this kind of nonsense mails:

In include/odp/api/spec/pool.h:
> @@ -290,10 +290,16 @@ odp_pool_t odp_pool_lookup(const char *name);
 /**
  * Pool information struct
  * Used to get information about a pool.
+ * @note The difference between end_addr & start_addr
+ * will result in buffers address range belong to this pool.
OK. agreed


-Petri

Re: [lng-odp] [PATCH API-NEXT v2] API: pool: Return address range for pool objects

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/pool.h
line 13
@@ -290,10 +290,16 @@ odp_pool_t odp_pool_lookup(const char *name);
 /**
  * Pool information struct
  * Used to get information about a pool.
+ * @note The difference between end_addr & start_addr
+ * will result in buffers address range belong to this pool.
  */
 typedef struct odp_pool_info_t {
const char *name;  /**< pool name */
odp_pool_param_t params;   /**< pool parameters */
+   /** Minimum address of any packet contained in this pool */
+   uintptr_t start_addr;
+   /** Maximum address of any packet contained in this pool */
+   uintptr_t end_addr;


Comment:
This spec should apply for all pool types (also other than packet). 0 address 
may be used when there's no data in an event (e.g. timeout).

/** Minimum data address.
   * This is the minimum address that application accessible data of any 
   * object (event) allocated from the pool may locate. When there's no 
   * application accessible data (e.g. ODP_POOL_TIMEOUT pools), the 
   * value maybe zero. */
uintptr_t min_data_addr;

/** Maximum data address.
   * This is the maximum address that application accessible data of any 
   * object (event) allocated from the pool may locate. When there's no 
   * application accessible data (e.g. ODP_POOL_TIMEOUT pools), the 
   * value maybe zero.  */
uintptr_t max_data_addr;


> sachin-saxena wrote
> I will wait for other's comments, if any, before sending V3 patchset


>> sachin-saxena wrote
>> 1.  Agreed for first suggestion.
>> 2.  For Second, As per my understanding, the VPP only needs to know the 
>> range of addresses in order to calculate OFFSET within. VPP doesn't 
>> assume/store packet address beyond its lifetime (Rx to Tx)


>>> sachin-saxena wrote
>>> OK. agreed


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 The only other ambiguity is whether the address that applications see for 
 a packet is constant. VPP clearly assumes this but this is not implied by 
 the ODP spec. The "lifetime" of packet visibility is from the time a call 
 like `odp_packet_data()` is made until the thread releases the 
 `odp_packet_t` that was used to obtain this address. If some other thread 
 receives that handle and calls `odp_packet_data()` there's no requirement 
 or guarantee that it will get the same address as the previous owner. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I'd change these to "visible address" rather than "address". The point is 
> that the spec says nothing about how packets are represented within an 
> implementation. It only states what applications may see by using other 
> ODP APIs that manipulate odp_packet_t object.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> I'd delete this note as it's not necessary and not complete for the ODP 
>> API spec. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> As we discussed earlier today. We should only need an extension to 
>>> `odp_pool_info()` to return the `min_addr` and `max_addr` of any packet 
>>> contained in the pool. This can simply be added to the end of the 
>>> `odp_pool_info_t` struct. The application (in this case VPP) can then 
>>> verify that the range is usable by it (_i.e.,_ is containable in 32 
>>> bits) and can store the info it needs to do its indexing from this 
>>> info. 


 Petri Savolainen(psavol) wrote:
 How sparse a "linear pool" may be? All implementations can claim 
 linear pool support by returning info.first_addr = 0, info.last_addr = 
 (uintptr_t) -1, where address size may be 64bits.
 
 Addresses could be used for debugging, but not much more than that. 
 What VPP is going to do with this information ?
  
 
 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> @muvarov To your points:
> 
> 1. No, VPP only deals with packets so there's no need to generalize 
> this since it is an accommodation for VPP, not something we want to 
> encourage other applications to use.
> 
> 2. We abandoned that approach because it required the application to 
> know how much memory the ODP implementation needed for its internal 
> use, which is not something it can reasonably know. So 
> `odp_pool_create()` is responsible for allocating any shm used by the 
> pool based on input provided by the caller. 
> 
> 3. Agree, the union seems strange here. Since having an output 
> parameter in the `odp_pool_param_t` is not something we want this 
> will have to be reworked anyway.


>> muvarov wrote
>> 1) is it needed for tmo and bufs also? why it's on only inside 
>> packets? 2) How memory for *start_addr is allocated in VPP? In 
>> previous version of 

Re: [lng-odp] [PATCH API-NEXT v2] API: pool: Return address range for pool objects

[Github ODP bot]

sachin-saxena replied on github web page:

include/odp/api/spec/pool.h
line 13
@@ -290,10 +290,16 @@ odp_pool_t odp_pool_lookup(const char *name);
 /**
  * Pool information struct
  * Used to get information about a pool.
+ * @note The difference between end_addr & start_addr
+ * will result in buffers address range belong to this pool.
  */
 typedef struct odp_pool_info_t {
const char *name;  /**< pool name */
odp_pool_param_t params;   /**< pool parameters */
+   /** Minimum address of any packet contained in this pool */
+   uintptr_t start_addr;
+   /** Maximum address of any packet contained in this pool */
+   uintptr_t end_addr;


Comment:
I will wait for other's comments, if any, before sending V3 patchset

> sachin-saxena wrote
> 1.  Agreed for first suggestion.
> 2.  For Second, As per my understanding, the VPP only needs to know the range 
> of addresses in order to calculate OFFSET within. VPP doesn't assume/store 
> packet address beyond its lifetime (Rx to Tx)


>> sachin-saxena wrote
>> OK. agreed


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> The only other ambiguity is whether the address that applications see for a 
>>> packet is constant. VPP clearly assumes this but this is not implied by the 
>>> ODP spec. The "lifetime" of packet visibility is from the time a call like 
>>> `odp_packet_data()` is made until the thread releases the `odp_packet_t` 
>>> that was used to obtain this address. If some other thread receives that 
>>> handle and calls `odp_packet_data()` there's no requirement or guarantee 
>>> that it will get the same address as the previous owner. 


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 I'd change these to "visible address" rather than "address". The point is 
 that the spec says nothing about how packets are represented within an 
 implementation. It only states what applications may see by using other 
 ODP APIs that manipulate odp_packet_t object.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I'd delete this note as it's not necessary and not complete for the ODP 
> API spec. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> As we discussed earlier today. We should only need an extension to 
>> `odp_pool_info()` to return the `min_addr` and `max_addr` of any packet 
>> contained in the pool. This can simply be added to the end of the 
>> `odp_pool_info_t` struct. The application (in this case VPP) can then 
>> verify that the range is usable by it (_i.e.,_ is containable in 32 
>> bits) and can store the info it needs to do its indexing from this info. 


>>> Petri Savolainen(psavol) wrote:
>>> How sparse a "linear pool" may be? All implementations can claim linear 
>>> pool support by returning info.first_addr = 0, info.last_addr = 
>>> (uintptr_t) -1, where address size may be 64bits.
>>> 
>>> Addresses could be used for debugging, but not much more than that. 
>>> What VPP is going to do with this information ?
>>>  
>>> 
>>> 


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 @muvarov To your points:
 
 1. No, VPP only deals with packets so there's no need to generalize 
 this since it is an accommodation for VPP, not something we want to 
 encourage other applications to use.
 
 2. We abandoned that approach because it required the application to 
 know how much memory the ODP implementation needed for its internal 
 use, which is not something it can reasonably know. So 
 `odp_pool_create()` is responsible for allocating any shm used by the 
 pool based on input provided by the caller. 
 
 3. Agree, the union seems strange here. Since having an output 
 parameter in the `odp_pool_param_t` is not something we want this will 
 have to be reworked anyway.


> muvarov wrote
> 1) is it needed for tmo and bufs also? why it's on only inside 
> packets? 2) How memory for *start_addr is allocated in VPP? In 
> previous version of odp_pool_create() was odp_shm_t parameter which 
> said to reuse already created shm.  Maybe that needs to be 
> reconsidered. 3) why union is needed? why it's not with uintptr_t ?


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> @Bill-Fischofer-Linaro yes, this looks like a good approach.
>> @sachin-saxena could you please reimplement your PR following 
>> @Bill-Fischofer-Linaro 's suggestion?


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Got confused between single-segment packet and linear space for 
>>> packets, sorry.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Yes the existing `seg_len` parameter is set to the minimum size 
 segment that the application requires. This can be set to be equal 
 to 

Re: [lng-odp] [PATCH API-NEXT v2] API: pool: Return address range for pool objects

[Github ODP bot]

sachin-saxena replied on github web page:

include/odp/api/spec/pool.h
line 13
@@ -290,10 +290,16 @@ odp_pool_t odp_pool_lookup(const char *name);
 /**
  * Pool information struct
  * Used to get information about a pool.
+ * @note The difference between end_addr & start_addr
+ * will result in buffers address range belong to this pool.
  */
 typedef struct odp_pool_info_t {
const char *name;  /**< pool name */
odp_pool_param_t params;   /**< pool parameters */
+   /** Minimum address of any packet contained in this pool */
+   uintptr_t start_addr;
+   /** Maximum address of any packet contained in this pool */
+   uintptr_t end_addr;


Comment:
1.  Agreed for first suggestion.
2.  For Second, As per my understanding, the VPP only needs to know the range 
of addresses in order to calculate OFFSET within. VPP doesn't assume/store 
packet address beyond its lifetime (Rx to Tx)

> sachin-saxena wrote
> OK. agreed


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> The only other ambiguity is whether the address that applications see for a 
>> packet is constant. VPP clearly assumes this but this is not implied by the 
>> ODP spec. The "lifetime" of packet visibility is from the time a call like 
>> `odp_packet_data()` is made until the thread releases the `odp_packet_t` 
>> that was used to obtain this address. If some other thread receives that 
>> handle and calls `odp_packet_data()` there's no requirement or guarantee 
>> that it will get the same address as the previous owner. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> I'd change these to "visible address" rather than "address". The point is 
>>> that the spec says nothing about how packets are represented within an 
>>> implementation. It only states what applications may see by using other ODP 
>>> APIs that manipulate odp_packet_t object.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 I'd delete this note as it's not necessary and not complete for the ODP 
 API spec. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> As we discussed earlier today. We should only need an extension to 
> `odp_pool_info()` to return the `min_addr` and `max_addr` of any packet 
> contained in the pool. This can simply be added to the end of the 
> `odp_pool_info_t` struct. The application (in this case VPP) can then 
> verify that the range is usable by it (_i.e.,_ is containable in 32 bits) 
> and can store the info it needs to do its indexing from this info. 


>> Petri Savolainen(psavol) wrote:
>> How sparse a "linear pool" may be? All implementations can claim linear 
>> pool support by returning info.first_addr = 0, info.last_addr = 
>> (uintptr_t) -1, where address size may be 64bits.
>> 
>> Addresses could be used for debugging, but not much more than that. What 
>> VPP is going to do with this information ?
>>  
>> 
>> 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> @muvarov To your points:
>>> 
>>> 1. No, VPP only deals with packets so there's no need to generalize 
>>> this since it is an accommodation for VPP, not something we want to 
>>> encourage other applications to use.
>>> 
>>> 2. We abandoned that approach because it required the application to 
>>> know how much memory the ODP implementation needed for its internal 
>>> use, which is not something it can reasonably know. So 
>>> `odp_pool_create()` is responsible for allocating any shm used by the 
>>> pool based on input provided by the caller. 
>>> 
>>> 3. Agree, the union seems strange here. Since having an output 
>>> parameter in the `odp_pool_param_t` is not something we want this will 
>>> have to be reworked anyway.


 muvarov wrote
 1) is it needed for tmo and bufs also? why it's on only inside 
 packets? 2) How memory for *start_addr is allocated in VPP? In 
 previous version of odp_pool_create() was odp_shm_t parameter which 
 said to reuse already created shm.  Maybe that needs to be 
 reconsidered. 3) why union is needed? why it's not with uintptr_t ?


> Dmitry Eremin-Solenikov(lumag) wrote:
> @Bill-Fischofer-Linaro yes, this looks like a good approach.
> @sachin-saxena could you please reimplement your PR following 
> @Bill-Fischofer-Linaro 's suggestion?


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Got confused between single-segment packet and linear space for 
>> packets, sorry.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Yes the existing `seg_len` parameter is set to the minimum size 
>>> segment that the application requires. This can be set to be equal 
>>> to `max_len` to require single-segment packets.
>>> 
>>> However @sachin-saxena mentioned at SFO17 that VPP can deal with 
>>> multi-segment packets, 

Re: [lng-odp] [PATCH API-NEXT v2] API: pool: Return address range for pool objects

[Github ODP bot]

sachin-saxena replied on github web page:

include/odp/api/spec/pool.h
line 5
@@ -290,10 +290,16 @@ odp_pool_t odp_pool_lookup(const char *name);
 /**
  * Pool information struct
  * Used to get information about a pool.
+ * @note The difference between end_addr & start_addr
+ * will result in buffers address range belong to this pool.


Comment:
OK. agreed

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> The only other ambiguity is whether the address that applications see for a 
> packet is constant. VPP clearly assumes this but this is not implied by the 
> ODP spec. The "lifetime" of packet visibility is from the time a call like 
> `odp_packet_data()` is made until the thread releases the `odp_packet_t` that 
> was used to obtain this address. If some other thread receives that handle 
> and calls `odp_packet_data()` there's no requirement or guarantee that it 
> will get the same address as the previous owner. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> I'd change these to "visible address" rather than "address". The point is 
>> that the spec says nothing about how packets are represented within an 
>> implementation. It only states what applications may see by using other ODP 
>> APIs that manipulate odp_packet_t object.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> I'd delete this note as it's not necessary and not complete for the ODP API 
>>> spec. 


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 As we discussed earlier today. We should only need an extension to 
 `odp_pool_info()` to return the `min_addr` and `max_addr` of any packet 
 contained in the pool. This can simply be added to the end of the 
 `odp_pool_info_t` struct. The application (in this case VPP) can then 
 verify that the range is usable by it (_i.e.,_ is containable in 32 bits) 
 and can store the info it needs to do its indexing from this info. 


> Petri Savolainen(psavol) wrote:
> How sparse a "linear pool" may be? All implementations can claim linear 
> pool support by returning info.first_addr = 0, info.last_addr = 
> (uintptr_t) -1, where address size may be 64bits.
> 
> Addresses could be used for debugging, but not much more than that. What 
> VPP is going to do with this information ?
>  
> 
> 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> @muvarov To your points:
>> 
>> 1. No, VPP only deals with packets so there's no need to generalize this 
>> since it is an accommodation for VPP, not something we want to encourage 
>> other applications to use.
>> 
>> 2. We abandoned that approach because it required the application to 
>> know how much memory the ODP implementation needed for its internal use, 
>> which is not something it can reasonably know. So `odp_pool_create()` is 
>> responsible for allocating any shm used by the pool based on input 
>> provided by the caller. 
>> 
>> 3. Agree, the union seems strange here. Since having an output parameter 
>> in the `odp_pool_param_t` is not something we want this will have to be 
>> reworked anyway.


>>> muvarov wrote
>>> 1) is it needed for tmo and bufs also? why it's on only inside packets? 
>>> 2) How memory for *start_addr is allocated in VPP? In previous version 
>>> of odp_pool_create() was odp_shm_t parameter which said to reuse 
>>> already created shm.  Maybe that needs to be reconsidered. 3) why union 
>>> is needed? why it's not with uintptr_t ?


 Dmitry Eremin-Solenikov(lumag) wrote:
 @Bill-Fischofer-Linaro yes, this looks like a good approach.
 @sachin-saxena could you please reimplement your PR following 
 @Bill-Fischofer-Linaro 's suggestion?


> Dmitry Eremin-Solenikov(lumag) wrote:
> Got confused between single-segment packet and linear space for 
> packets, sorry.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Yes the existing `seg_len` parameter is set to the minimum size 
>> segment that the application requires. This can be set to be equal 
>> to `max_len` to require single-segment packets.
>> 
>> However @sachin-saxena mentioned at SFO17 that VPP can deal with 
>> multi-segment packets, though I'm not sure how that works.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> VPP will not run on such platforms without modification. If the 
>>> goal is to not modify VPP then an `odp_pool_capability()` output 
>>> that says whether pools can present a linear interface. During 
>>> Connect @psavol also mentioned that a separate API to get this info 
>>> would be more appropriate than bending the input to 
>>> `odp_pool_create()` to give output parameters.
>>> 
>>> My personal preference would be something like:
>>> 
>>> * `odp_pool_capability()` indicates whether 

Re: [lng-odp] [PATCH v9] Another build system update

[Github ODP bot]

muvarov replied on github web page:

Makefile.am
@@ -4,12 +4,13 @@ AM_DISTCHECK_CONFIGURE_FLAGS = --enable-user-guides   \
   --with-testdir
 
 #@with_platform@ works alone in subdir but not as part of a path???
-SUBDIRS = @platform_with_platform@ \
+SUBDIRS = \
+ test_common \


Comment:
to compile tests you need odp library compiled. To execute performance tests 
examples are needed to be compile. "." defines order for parallel make. Moving 
test_common to the top should bake parallel make.

> muvarov wrote
> this atomic things are specific to linux-generic. Are you panning to use they 
> anywhere else?


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> @Bill-Fischofer-Linaro updated


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> just for the sake of 80 chars limit? Fine, I will update this.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 What's wrong with factoring this like:
 ```
 VALIDATION_TESTDIR=platform/$ODP_PLATFORM/test/validation
 PLATFORM_VALIDATION=${TEST_SRC_DIR}/../../$VALIDATION_TESTDIR
 ```
 That seems to solve the line length problem cleanly.


> Dmitry Eremin-Solenikov(lumag) wrote:
> Not in a clean way


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Checkpatch flags this line as being > 80 chars. Can it not be split into 
>> two lines or otherwise shortened?


https://github.com/Linaro/odp/pull/213#discussion_r143687853
updated_at 2017-10-11 08:09:08

Re: [lng-odp] [PATCH v9] Another build system update

[Github ODP bot]

muvarov replied on github web page:

m4/odp_atomic.m4
line 1
@@ -0,0 +1,95 @@
+# ODP_ATOMIC


Comment:
this atomic things are specific to linux-generic. Are you panning to use they 
anywhere else?

> Dmitry Eremin-Solenikov(lumag) wrote:
> @Bill-Fischofer-Linaro updated


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> just for the sake of 80 chars limit? Fine, I will update this.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> What's wrong with factoring this like:
>>> ```
>>> VALIDATION_TESTDIR=platform/$ODP_PLATFORM/test/validation
>>> PLATFORM_VALIDATION=${TEST_SRC_DIR}/../../$VALIDATION_TESTDIR
>>> ```
>>> That seems to solve the line length problem cleanly.


 Dmitry Eremin-Solenikov(lumag) wrote:
 Not in a clean way


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Checkpatch flags this line as being > 80 chars. Can it not be split into 
> two lines or otherwise shortened?


https://github.com/Linaro/odp/pull/213#discussion_r143686710
updated_at 2017-10-11 08:09:08

Re: [lng-odp] [PATCH v9] Another build system update

[Github ODP bot]

muvarov replied on github web page:

.travis.yml
line 4
@@ -232,6 +232,7 @@ jobs:
   CXXFLAGS="-O0 -coverage" LDFLAGS="--coverage"
 --enable-debug=full
 --enable-helper-linux
+  - make -j $(nproc)


Comment:
make check will build it. Optional  change.

> muvarov wrote
> this patch needs to be revising. EXEEXT somewhere is remove somewhere exist. 
> EXEEXT was added by Kalrey to run make check on their platform where they can 
> not run binaries without EXEEXT. I think we should leave extensions in the 
> code.


>> muvarov wrote
>> to compile tests you need odp library compiled. To execute performance tests 
>> examples are needed to be compile. "." defines order for parallel make. 
>> Moving test_common to the top should bake parallel make.


>>> muvarov wrote
>>> this atomic things are specific to linux-generic. Are you panning to use 
>>> they anywhere else?


 Dmitry Eremin-Solenikov(lumag) wrote:
 @Bill-Fischofer-Linaro updated


> Dmitry Eremin-Solenikov(lumag) wrote:
> just for the sake of 80 chars limit? Fine, I will update this.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> What's wrong with factoring this like:
>> ```
>> VALIDATION_TESTDIR=platform/$ODP_PLATFORM/test/validation
>> PLATFORM_VALIDATION=${TEST_SRC_DIR}/../../$VALIDATION_TESTDIR
>> ```
>> That seems to solve the line length problem cleanly.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Not in a clean way


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Checkpatch flags this line as being > 80 chars. Can it not be split 
 into two lines or otherwise shortened?


https://github.com/Linaro/odp/pull/213#discussion_r143689369
updated_at 2017-10-11 08:09:08

Re: [lng-odp] [PATCH v9] Another build system update

[Github ODP bot]

muvarov replied on github web page:

example/traffic_mgmt/Makefile.am
line 3
@@ -1,9 +1,5 @@
 include $(top_srcdir)/example/Makefile.inc
 
 bin_PROGRAMS = odp_traffic_mgmt$(EXEEXT)


Comment:
this patch needs to be revising. EXEEXT somewhere is remove somewhere exist. 
EXEEXT was added by Kalrey to run make check on their platform where they can 
not run binaries without EXEEXT. I think we should leave extensions in the code.

> muvarov wrote
> to compile tests you need odp library compiled. To execute performance tests 
> examples are needed to be compile. "." defines order for parallel make. 
> Moving test_common to the top should bake parallel make.


>> muvarov wrote
>> this atomic things are specific to linux-generic. Are you panning to use 
>> they anywhere else?


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> @Bill-Fischofer-Linaro updated


 Dmitry Eremin-Solenikov(lumag) wrote:
 just for the sake of 80 chars limit? Fine, I will update this.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> What's wrong with factoring this like:
> ```
> VALIDATION_TESTDIR=platform/$ODP_PLATFORM/test/validation
> PLATFORM_VALIDATION=${TEST_SRC_DIR}/../../$VALIDATION_TESTDIR
> ```
> That seems to solve the line length problem cleanly.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Not in a clean way


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Checkpatch flags this line as being > 80 chars. Can it not be split 
>>> into two lines or otherwise shortened?


https://github.com/Linaro/odp/pull/213#discussion_r143689050
updated_at 2017-10-11 08:09:08