[lng-odp] [PATCH] test: tm: skip tm result under travis run

[Maxim Uvarov]

tm test fails time to time in Travis environment. Because
of we can not control that machine we can not do things like
taskset and core isolation there. So simple run test and ignore
it's result. Threat only segfault as actual error. Linaro CI
will still do full test.
https://bugs.linaro.org/show_bug.cgi?id=2881

Signed-off-by: Maxim Uvarov 
---
 .../validation/api/traffic_mngr/Makefile.am| 12 +--
 .../validation/api/traffic_mngr/traffic_mngr.sh| 25 ++
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100755 test/common_plat/validation/api/traffic_mngr/traffic_mngr.sh

diff --git a/test/common_plat/validation/api/traffic_mngr/Makefile.am 
b/test/common_plat/validation/api/traffic_mngr/Makefile.am
index 35e689a0..a012c1b3 100644
--- a/test/common_plat/validation/api/traffic_mngr/Makefile.am
+++ b/test/common_plat/validation/api/traffic_mngr/Makefile.am
@@ -1,10 +1,18 @@
 include ../Makefile.inc
 
+TESTS_ENVIRONMENT += TEST_DIR=${builddir}
+
+TESTSCRIPTS = traffic_mngr.sh
+TEST_EXTENSIONS = .sh
+
+TESTS = $(TESTSCRIPTS)
+
 noinst_LTLIBRARIES = libtesttraffic_mngr.la
 libtesttraffic_mngr_la_SOURCES = traffic_mngr.c
 
-test_PROGRAMS = traffic_mngr_main$(EXEEXT)
+bin_PROGRAMS = traffic_mngr_main$(EXEEXT)
 dist_traffic_mngr_main_SOURCES = traffic_mngr_main.c
 traffic_mngr_main_LDADD = libtesttraffic_mngr.la -lm $(LIBCUNIT_COMMON) 
$(LIBODP)
 
-EXTRA_DIST = traffic_mngr.h
+EXTRA_DIST = traffic_mngr.h $(TESTSCRIPTS)
+dist_check_SCRIPTS = $(TESTSCRIPTS)
diff --git a/test/common_plat/validation/api/traffic_mngr/traffic_mngr.sh 
b/test/common_plat/validation/api/traffic_mngr/traffic_mngr.sh
new file mode 100755
index ..a7d54162
--- /dev/null
+++ b/test/common_plat/validation/api/traffic_mngr/traffic_mngr.sh
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (c) 2017, Linaro Limited
+# All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+#
+
+# directory where test binaries have been built
+TEST_DIR="${TEST_DIR:-$(dirname $0)}"
+
+# exit codes expected by automake for skipped tests
+TEST_SKIPPED=77
+
+${TEST_DIR}/traffic_mngr_main${EXEEXT}
+ret=$?
+
+SIGSEGV=139
+
+if [ "${TRAVIS}" = "true" ] && [ $ret -ne 0 ] && [ $ret -ne ${SIGSEGV} ]; then
+   echo "SKIP: skip due to not isolated environment"
+   exit ${TEST_SKIPPED}
+fi
+
+exit $ret
-- 
2.11.0.295.gd7dffce

Re: [lng-odp] [PATCHv4] linux-generic: debug: enable helper use from c++ programs

[Maxim Uvarov]

rechecked this patch and it fails:
https://travis-ci.org/muvarov/odp/jobs/217195437

Maxim.

On 02/08/17 04:04, Bill Fischofer wrote:
> I've done a fair amount of experimentation with using variants of
> Brian's suggested macros. This works for C but for C++ it results in
> an error message saying that it can't do relocation and to please
> compile with -fPIC, which we've already determined is an unacceptable
> requirement for ODP programs. These sort of issues are why
> _Static_assert() and static_assert() were introduced to the languages
> in the first place.
> 
> Can we require -std=c++11 when using ODP?
> 
> On Tue, Feb 7, 2017 at 8:42 AM, Bill Fischofer
>  wrote:
>> Given these issues with obsolete compiler levels, it may be simpler to
>> go with Brian's suggestion and just use some simple macros. I'll post
>> a v4 along those lines.
>>
>> On Tue, Feb 7, 2017 at 7:51 AM, Maxim Uvarov  wrote:
>>> On 02/07/17 16:39, Bill Fischofer wrote:
 The errors being reported here are on unchanged code paths with an
 older clang version (3.4.0 vs.4.2.1). Not sure why you'd see that here
 and not in the unchanged code.

 Also, this run is reporting doxygen issues with the traffic manager
 that I don't see running locally:

 $ make doxygen-doc
   DXGEN  doc/application-api-guide/Doxyfile
 warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
 26, file ./doc/Doxyfile_common
 error: Unexpected start tag `services' found in scope='class/memberdecl/'!
 error: Unexpected start tag `interfaces' found in 
 scope='class/memberdecl/'!
 error: Unexpected start tag `services' found in scope='class/memberdef/'!
 error: Unexpected start tag `interfaces' found in scope='class/memberdef/'!
 error: Unexpected start tag `constantgroups' found in
 scope='namespace/memberdecl/'!
 error: Unexpected start tag `constantgroups' found in 
 scope='file/memberdecl/'!
 /home/travis/build/muvarov/odp/doc/application-api-guide/api_guide_lines.dox:10:
 warning: Found unknown command `\tableofcontents'
 /home/travis/build/muvarov/odp/doc/application-api-guide/release.dox:8:
 warning: Found unknown command `\tableofcontents'
 /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1717:
 warning: expected whitespace after param command
 /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
 warning: argument 'inout' of command @param is not found in the
 argument list of odp_tm_node_fanin_info(odp_tm_node_t tm_node,
 odp_tm_node_fanin_info_t *info)
 /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
 warning: The following parameters of
 odp_tm_node_fanin_info(odp_tm_node_t tm_node, odp_tm_node_fanin_info_t
 *info) are not documented:
   parameter 'info'
   DXGEN  doc/helper-guide/Doxyfile
 warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
 31, file ./doc/helper-guide/Doxyfile
 error: Unexpected start tag `services' found in scope='class/memberdecl/'!
 error: Unexpected start tag `interfaces' found in 
 scope='class/memberdecl/'!
 error: Unexpected start tag `services' found in scope='class/memberdef/'!
 error: Unexpected start tag `interfaces' found in scope='class/memberdef/'!
 error: Unexpected start tag `constantgroups' found in
 scope='namespace/memberdecl/'!
 error: Unexpected start tag `constantgroups' found in 
 scope='file/memberdecl/'!

 So do we also have a doxygen version issue on these systems?

>>>
>>>
>>> looks like yes. I also do not see comment locally.
>>>
>>> we also need some way to return non 0 if doxygen reported an error.
>>>
>>> The command "make doxygen-doc" exited with 0.
>>>
>>>
>>>
 On Tue, Feb 7, 2017 at 7:30 AM, Maxim Uvarov  
 wrote:
> I pushed it to github and test failed:
>
> https://api.travis-ci.org/jobs/199201799/log.txt?deansi=true
>
> Maxim.
>
>
> On 02/07/17 05:51, Brian Brooks wrote:
>> On 02/06 13:14:17, Bill Fischofer wrote:
>>> Ping. Brian can you please verify that this now works on your system.
>>> It works on my Ubuntu 16.04 system.
>>
>> Just built on:
>>
>> Ubuntu 16.10 - x86_64
>> Ubuntu 16.04 - aarch64
>> Arch - aarch64 & x86_64
>>
>> so the previous build error I reported seems to have been resolved.
>>
>>> A review would also be nice. :)
>>
>> LGTM, please...
>>
>> Reviewed-and-tested-by: Brian Brooks 
>>
>>> On Thu, Feb 2, 2017 at 4:51 PM, Bill Fischofer
>>>  wrote:
 The ODP_STATIC_ASSERT() macro expands to _Static_assert(), however when
 used in C++ programs this needs to expand to static_assert().

 This resolves Bug https://bugs.linaro.org/show_bug.cgi?id=2852

 Reported-by: Moshe Tubul 
 Signed-off-by: Bill Fischofer 
 ---
>>

Re: [lng-odp] [API-NEXT PATCH v2 1/2] api: queue: added queue size param

[Bill Fischofer]

On Fri, Mar 31, 2017 at 6:46 AM, Petri Savolainen
 wrote:
> Added capability information about maximum number of queues
> and queue sizes. Both are defined per queue type, since
> plain and scheduled queues may have different implementations
> (e.g. one uses HW while the other is SW).
>
> Added queue size parameter, which specifies how large
> storage size application requires in minimum.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/queue.h | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
> index 7972fea..55b7e44 100644
> --- a/include/odp/api/spec/queue.h
> +++ b/include/odp/api/spec/queue.h
> @@ -100,7 +100,7 @@ typedef enum odp_queue_op_mode_t {
>   * Queue capabilities
>   */
>  typedef struct odp_queue_capability_t {
> -   /** Maximum number of event queues */
> +   /** Maximum number of event queues of any type */

The documentation note that a value of zero means unlimited should be
included here, however this does raise a question of how we deal with
implementations where the max number of event queues is fixed (HW
limit) but the number of plain queues is unlimited since they are just
malloc'd.  Given this possibility, does a consolidated max_queues
value even make any sense since applications would always need to
double-check the individual queue type limits anyway?

> uint32_t max_queues;
>
> /** Maximum number of ordered locks per queue */
> @@ -112,6 +112,28 @@ typedef struct odp_queue_capability_t {
> /** Number of scheduling priorities */
> unsigned sched_prios;
>
> +   /** Plain queue capabilities */
> +   struct {
> +   /** Maximum number of a plain queues. */
> +   uint32_t max_num;
> +
> +   /** Maximum number of events a plain queue can store
> + * simultaneously. The value of zero means unlimited. */
> +   uint32_t max_size;
> +
> +   } plain;
> +
> +   /** Scheduled queue capabilities */
> +   struct {
> +   /** Maximum number of a scheduled queues. */
> +   uint32_t max_num;
> +
> +   /** Maximum number of events a scheduled queue can store
> + * simultaneously. The value of zero means unlimited. */
> +   uint32_t max_size;
> +
> +   } sched;
> +
>  } odp_queue_capability_t;
>
>  /**
> @@ -165,6 +187,15 @@ typedef struct odp_queue_param_t {
>   * The implementation may use this value as a hint for the number of
>   * context data bytes to prefetch. Default value is zero (no hint). 
> */
> uint32_t context_len;
> +
> +   /** Queue size
> + *
> + * The queue must be able to store in minimum this many events

grammar: at minimum

> + * simultaneously. The value must not exceed 'max_size' queue
> + * capability. The value of zero means implementation specific
> + * default size. */
> +   uint32_t size;
> +
>  } odp_queue_param_t;
>
>  /**
> --
> 2.8.1
>

Re: [lng-odp] [API-NEXT PATCH v2 2/2] validation: queue: test queue max_num per type

[Bill Fischofer]

This patch is incomplete. Since you're adding a max_size, we need to
add a test for that. If an implementation says the max size of a queue
is n (n > 0) then we have to attempt to allocate a queue of that size
and verify that trying to add an n+1st element to it will fail.
Otherwise, we shouldn't have a max_size at all (which we had
discussed) since applications only care about minimums. If the
application's requested minimum exceeds any implementation-defined
max_size then the queue_create() call will simply fail.


On Fri, Mar 31, 2017 at 6:46 AM, Petri Savolainen
 wrote:
> Updated implementation and test with type specific number of
> queues.
>
> Signed-off-by: Petri Savolainen 
> ---
>  platform/linux-generic/odp_queue.c|  2 ++
>  test/common_plat/validation/api/queue/queue.c | 43 
> ---
>  2 files changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/platform/linux-generic/odp_queue.c 
> b/platform/linux-generic/odp_queue.c
> index fcf4bf5..1114c95 100644
> --- a/platform/linux-generic/odp_queue.c
> +++ b/platform/linux-generic/odp_queue.c
> @@ -175,6 +175,8 @@ int odp_queue_capability(odp_queue_capability_t *capa)
> capa->max_ordered_locks = sched_fn->max_ordered_locks();
> capa->max_sched_groups  = sched_fn->num_grps();
> capa->sched_prios   = odp_schedule_num_prio();
> +   capa->plain.max_num = capa->max_queues;
> +   capa->sched.max_num = capa->max_queues;

Shouldn't odp_queue_create() also be checking that queue_params.size > 0?

>
> return 0;
>  }
> diff --git a/test/common_plat/validation/api/queue/queue.c 
> b/test/common_plat/validation/api/queue/queue.c
> index 1f7913a..8a874a4 100644
> --- a/test/common_plat/validation/api/queue/queue.c
> +++ b/test/common_plat/validation/api/queue/queue.c
> @@ -56,7 +56,7 @@ void queue_test_capa(void)
> odp_queue_param_t qparams;
> char name[ODP_QUEUE_NAME_LEN];
> odp_queue_t queue[MAX_QUEUES];
> -   uint32_t num_queues, i;
> +   uint32_t num_queues, i, j;
>
> memset(&capa, 0, sizeof(odp_queue_capability_t));
> CU_ASSERT(odp_queue_capability(&capa) == 0);
> @@ -65,34 +65,43 @@ void queue_test_capa(void)
> CU_ASSERT(capa.max_ordered_locks != 0);
> CU_ASSERT(capa.max_sched_groups != 0);
> CU_ASSERT(capa.sched_prios != 0);
> +   CU_ASSERT(capa.plain.max_num != 0);
> +   CU_ASSERT(capa.sched.max_num != 0);
>
> for (i = 0; i < ODP_QUEUE_NAME_LEN; i++)
> name[i] = 'A' + (i % 26);
>
> name[ODP_QUEUE_NAME_LEN - 1] = 0;
>
> -   if (capa.max_queues > MAX_QUEUES)
> -   num_queues = MAX_QUEUES;
> -   else
> -   num_queues = capa.max_queues;
> -
> odp_queue_param_init(&qparams);
>
> -   for (i = 0; i < num_queues; i++) {
> -   generate_name(name, i);
> -   queue[i] = odp_queue_create(name, &qparams);
> +   for (j = 0; j < 2; j++) {
> +   if (j == 0) {
> +   num_queues = capa.plain.max_num;
> +   } else {
> +   num_queues = capa.sched.max_num;
> +   qparams.type = ODP_QUEUE_TYPE_SCHED;
> +   }
> +
> +   if (num_queues > MAX_QUEUES)
> +   num_queues = MAX_QUEUES;
> +
> +   for (i = 0; i < num_queues; i++) {

This code is incorrect since if either max_num is 0 (indicating
unbounded numbers of queues supported) num_queues will be set to zero
so this loop will not create any queues at all.

> +   generate_name(name, i);
> +   queue[i] = odp_queue_create(name, &qparams);
>
> -   if (queue[i] == ODP_QUEUE_INVALID) {
> -   CU_FAIL("Queue create failed");
> -   num_queues = i;
> -   break;
> +   if (queue[i] == ODP_QUEUE_INVALID) {
> +   CU_FAIL("Queue create failed");
> +   num_queues = i;
> +   break;
> +   }
> +
> +   CU_ASSERT(odp_queue_lookup(name) != 
> ODP_QUEUE_INVALID);
> }
>
> -   CU_ASSERT(odp_queue_lookup(name) != ODP_QUEUE_INVALID);
> +   for (i = 0; i < num_queues; i++)
> +   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
> }
> -
> -   for (i = 0; i < num_queues; i++)
> -   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
>  }
>
>  void queue_test_mode(void)
> --
> 2.8.1
>

Re: [lng-odp] [PATCH] helper: iplookuptable: fix prefix_entry_t member order

[Elo, Matias (Nokia - FI/Espoo)]

> On 31 Mar 2017, at 16:54, Maxim Uvarov  wrote:
> 
> On 03/31/17 10:43, Matias Elo wrote:
>> Fixes https://bugs.linaro.org/show_bug.cgi?id=2910
>> 
> 
> Matias please add some description here. Link to problem is good
> but people like to read only git logs.
> 
> Maxim.

Sure, fixed in v2.

-Matias

[lng-odp] [PATCH v2] helper: iplookuptable: fix prefix_entry_t member order

[Matias Elo]

Depending on the alignment/padding odph_iplookup_table_put_value() could
end up overwriting the wrong fields in prefix_entry_t. Fix this by
reverting the order of prefix_entry_t members.

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

Signed-off-by: Matias Elo 
---
V2:
- Improved commit log (Maxim)

 helper/iplookuptable.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/helper/iplookuptable.c b/helper/iplookuptable.c
index aae2199..37d31e3 100644
--- a/helper/iplookuptable.c
+++ b/helper/iplookuptable.c
@@ -42,6 +42,10 @@
  */
 typedef struct {
union {
+   odp_buffer_t nexthop;
+   void *ptr;
+   };
+   union {
uint8_t u8;
struct {
 #if ODP_BYTE_ORDER == ODP_BIG_ENDIAN
@@ -53,10 +57,6 @@ typedef struct {
 #endif
};
};
-   union {
-   odp_buffer_t nexthop;
-   void *ptr;
-   };
 } prefix_entry_t;
 
 #define ENTRY_SIZE (sizeof(prefix_entry_t) + sizeof(odp_buffer_t))
-- 
2.7.4

Re: [lng-odp] [PATCH] helper: iplookuptable: fix prefix_entry_t member order

[Maxim Uvarov]

On 03/31/17 10:43, Matias Elo wrote:
> Fixes https://bugs.linaro.org/show_bug.cgi?id=2910
> 

Matias please add some description here. Link to problem is good
but people like to read only git logs.

Maxim.

> Signed-off-by: Matias Elo 
> ---
>  helper/iplookuptable.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/helper/iplookuptable.c b/helper/iplookuptable.c
> index aae2199..37d31e3 100644
> --- a/helper/iplookuptable.c
> +++ b/helper/iplookuptable.c
> @@ -42,6 +42,10 @@
>   */
>  typedef struct {
>   union {
> + odp_buffer_t nexthop;
> + void *ptr;
> + };
> + union {
>   uint8_t u8;
>   struct {
>  #if ODP_BYTE_ORDER == ODP_BIG_ENDIAN
> @@ -53,10 +57,6 @@ typedef struct {
>  #endif
>   };
>   };
> - union {
> - odp_buffer_t nexthop;
> - void *ptr;
> - };
>  } prefix_entry_t;
>  
>  #define ENTRY_SIZE (sizeof(prefix_entry_t) + sizeof(odp_buffer_t))
> 

Re: [lng-odp] [API-NEXT 2/4] linux-generic: ring.c: use required memory orderings

[Maxim Uvarov]

Merged to master branch.

Maxim.

On 03/31/17 16:45, Ola Liljedahl wrote:
> On 31 March 2017 at 15:21, Maxim Uvarov  wrote:
>> On 03/28/17 22:23, Brian Brooks wrote:
>>> From: Ola Liljedahl 
>>>
>>> Signed-off-by: Ola Liljedahl 
>>> Reviewed-by: Brian Brooks 
>>> ---
>>>  platform/linux-generic/pktio/ring.c | 30 ++
>>>  1 file changed, 14 insertions(+), 16 deletions(-)
>>>  mode change 100644 => 100755 platform/linux-generic/pktio/ring.c
>>>
>>> diff --git a/platform/linux-generic/pktio/ring.c 
>>> b/platform/linux-generic/pktio/ring.c
>>> old mode 100644
>>> new mode 100755
>>
>>
>> no need of setting executable permissions to c file. And of course you
> Very strange. I can assure you that I have not actively changed
> permissions on this file (I made the original changes on our local
> copy).
> 
>> have to run checkpatch.pl or push that code to github and it will do all
>> required checks.
>>
>> I will fix it, no need to resend.
>>
>> Maxim.
>>
>>> index aeda04b2..e3c73d1c
>>> --- a/platform/linux-generic/pktio/ring.c
>>> +++ b/platform/linux-generic/pktio/ring.c
>>> @@ -263,8 +263,8 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
>>> *obj_table,
>>>   /* Reset n to the initial burst count */
>>>   n = max;
>>>
>>> - prod_head = r->prod.head;
>>> - cons_tail = r->cons.tail;
>>> + prod_head = __atomic_load_n(&r->prod.head, __ATOMIC_RELAXED);
>>> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>>>   /* The subtraction is done between two unsigned 32bits value
>>>* (the result is always modulo 32 bits even if we have
>>>* prod_head > cons_tail). So 'free_entries' is always 
>>> between 0
>>> @@ -306,12 +306,12 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
>>> *obj_table,
>>>* If there are other enqueues in progress that preceded us,
>>>* we need to wait for them to complete
>>>*/
>>> - while (odp_unlikely(r->prod.tail != prod_head))
>>> + while (odp_unlikely(__atomic_load_n(&r->prod.tail, __ATOMIC_RELAXED) 
>>> !=
>>> + prod_head))
>>>   odp_cpu_pause();
>>>
>>>   /* Release our entries and the memory they refer to */
>>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>>> - r->prod.tail = prod_next;
>>> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>>>   return ret;
>>>  }
>>>
>>> @@ -328,7 +328,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
>>> *obj_table,
>>>   int ret;
>>>
>>>   prod_head = r->prod.head;
>>> - cons_tail = r->cons.tail;
>>> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>>>   /* The subtraction is done between two unsigned 32bits value
>>>* (the result is always modulo 32 bits even if we have
>>>* prod_head > cons_tail). So 'free_entries' is always between 0
>>> @@ -361,8 +361,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
>>> *obj_table,
>>>   }
>>>
>>>   /* Release our entries and the memory they refer to */
>>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>>> - r->prod.tail = prod_next;
>>> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>>>   return ret;
>>>  }
>>>
>>> @@ -385,8 +384,8 @@ int ___ring_mc_do_dequeue(_ring_t *r, void **obj_table,
>>>   /* Restore n as it may change every loop */
>>>   n = max;
>>>
>>> - cons_head = r->cons.head;
>>> - prod_tail = r->prod.tail;
>>> + cons_head = __atomic_load_n(&r->cons.head, __ATOMIC_RELAXED);
>>> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUIRE);
>>>   /* The subtraction is done between two unsigned 32bits value
>>>* (the result is always modulo 32 bits even if we have
>>>* cons_head > prod_tail). So 'entries' is always between 0
>>> @@ -419,12 +418,12 @@ int ___ring_mc_do_dequeue(_ring_t *r, void 
>>> **obj_table,
>>>* If there are other dequeues in progress that preceded us,
>>>* we need to wait for them to complete
>>>*/
>>> - while (odp_unlikely(r->cons.tail != cons_head))
>>> + while (odp_unlikely(__atomic_load_n(&r->cons.tail, __ATOMIC_RELAXED) 
>>> !=
>>> + cons_head))
>>>   odp_cpu_pause();
>>>
>>>   /* Release our entries and the memory they refer to */
>>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>>> - r->cons.tail = cons_next;
>>> + __atomic_store_n(&r->cons.tail, cons_next, __ATOMIC_RELEASE);
>>>
>>>   return behavior == _RING_QUEUE_FIXED ? 0 : n;
>>>  }
>>> @@ -441,7 +440,7 @@ int ___ring_sc_do_dequeue(_ring_t *r, void **obj_table,
>>>   uint32_t mask = r->prod.mask;
>>>
>>>   cons_head = r->cons.head;
>>> - prod_tail = r->prod.tail;
>>> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUI

Re: [lng-odp] My last day at linaro/LNG

[Bill Fischofer]

Au revoir! It was great working with you and I hope our paths will
cross again. Best wishes for your future success.

On Fri, Mar 31, 2017 at 6:20 AM, Mike Holmes  wrote:
> Sad to see you go Christophe, it really was energizing to work with you.
>
> Mike
>
> On Mar 31, 2017 7:13 AM, "Maxim Uvarov"  wrote:
>
>> Thanks Christophe for all that work which you did! It's really good impact
>> to the project. And all the best wishes in future.
>>
>> Maxim.
>>
>> On 31 March 2017 at 11:32, Yi He  wrote:
>>
>>> Hi, Christophe,
>>>
>>> Wish you all the best and joy in your new endeavors.
>>>
>>> Best Regards, Yi
>>>
>>> On 31 March 2017 at 16:27, Francois Ozog 
>>> wrote:
>>>
>>> > Hi Christophe,
>>> >
>>> > It is a big loss for LNG.
>>> >
>>> > On the technical side you have both conceptual talent and great
>>> > implementation skills. This is not so common and DDF was a challenge at
>>> > your "measure" (as a French you will know what I mean as I don't know
>>> if it
>>> > translates well in English).
>>> >
>>> > Despite all that you were still a cool guy to interact with ;-)
>>> >
>>> > I don't know if Ericsson know how lucky they are but Linaro know what
>>> it is
>>> > loosing.
>>> >
>>> > Have fun in your new endeavors.
>>> >
>>> > Cordially
>>> >
>>> > FF
>>> >
>>> > Le ven. 31 mars 2017 à 10:19, Christophe Milard <
>>> > christophe.mil...@linaro.org> a écrit :
>>> >
>>> > > Hi all,
>>> > > As most of you know, my assignment for linaro/LNG is ending today.
>>> > > I was really willing to join connect in Budapest as this would have
>>> > > given me an opportunity to see you a last time face to face but this
>>> > > did not happen, sadly.
>>> > > I wish to thank all of you that helped me growing in this open source
>>> > > world. It has been a very interesting time.
>>> > > I do regret that the DDF work did not fully land before my departure.
>>> > > Hopefully my work helped on the way...
>>> > >
>>> > > I'd be happy to see ODP growing... I'll keep an eye on it
>>> > >
>>> > > I wish you all the best,
>>> > >
>>> > > Regards,
>>> > >
>>> > > Christophe.
>>> > >
>>> > --
>>> > [image: Linaro] 
>>> > François-Frédéric Ozog | *Director Linaro Networking Group*
>>> > T: +33.67221.6485 
>>> > francois.o...@linaro.org | Skype: ffozog
>>> >
>>>
>>
>>

[lng-odp] [Linaro/odp] 8286cf: linux-generic: ring.c: use required memory orderin...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 8286cff9c5bb890d169b58857e3ab6cd118a2af4
  
https://github.com/Linaro/odp/commit/8286cff9c5bb890d169b58857e3ab6cd118a2af4
  Author: Ola Liljedahl 
  Date:   2017-03-31 (Fri, 31 Mar 2017)

  Changed paths:
M platform/linux-generic/pktio/ring.c

  Log Message:
  ---
  linux-generic: ring.c: use required memory orderings

Signed-off-by: Ola Liljedahl 
Reviewed-by: Brian Brooks 
Signed-off-by: Maxim Uvarov 

Re: [lng-odp] [API-NEXT 2/4] linux-generic: ring.c: use required memory orderings

[Ola Liljedahl]

On 31 March 2017 at 15:21, Maxim Uvarov  wrote:
> On 03/28/17 22:23, Brian Brooks wrote:
>> From: Ola Liljedahl 
>>
>> Signed-off-by: Ola Liljedahl 
>> Reviewed-by: Brian Brooks 
>> ---
>>  platform/linux-generic/pktio/ring.c | 30 ++
>>  1 file changed, 14 insertions(+), 16 deletions(-)
>>  mode change 100644 => 100755 platform/linux-generic/pktio/ring.c
>>
>> diff --git a/platform/linux-generic/pktio/ring.c 
>> b/platform/linux-generic/pktio/ring.c
>> old mode 100644
>> new mode 100755
>
>
> no need of setting executable permissions to c file. And of course you
Very strange. I can assure you that I have not actively changed
permissions on this file (I made the original changes on our local
copy).

> have to run checkpatch.pl or push that code to github and it will do all
> required checks.
>
> I will fix it, no need to resend.
>
> Maxim.
>
>> index aeda04b2..e3c73d1c
>> --- a/platform/linux-generic/pktio/ring.c
>> +++ b/platform/linux-generic/pktio/ring.c
>> @@ -263,8 +263,8 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
>> *obj_table,
>>   /* Reset n to the initial burst count */
>>   n = max;
>>
>> - prod_head = r->prod.head;
>> - cons_tail = r->cons.tail;
>> + prod_head = __atomic_load_n(&r->prod.head, __ATOMIC_RELAXED);
>> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>>   /* The subtraction is done between two unsigned 32bits value
>>* (the result is always modulo 32 bits even if we have
>>* prod_head > cons_tail). So 'free_entries' is always between >> 0
>> @@ -306,12 +306,12 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
>> *obj_table,
>>* If there are other enqueues in progress that preceded us,
>>* we need to wait for them to complete
>>*/
>> - while (odp_unlikely(r->prod.tail != prod_head))
>> + while (odp_unlikely(__atomic_load_n(&r->prod.tail, __ATOMIC_RELAXED) !=
>> + prod_head))
>>   odp_cpu_pause();
>>
>>   /* Release our entries and the memory they refer to */
>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>> - r->prod.tail = prod_next;
>> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>>   return ret;
>>  }
>>
>> @@ -328,7 +328,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
>> *obj_table,
>>   int ret;
>>
>>   prod_head = r->prod.head;
>> - cons_tail = r->cons.tail;
>> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>>   /* The subtraction is done between two unsigned 32bits value
>>* (the result is always modulo 32 bits even if we have
>>* prod_head > cons_tail). So 'free_entries' is always between 0
>> @@ -361,8 +361,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
>> *obj_table,
>>   }
>>
>>   /* Release our entries and the memory they refer to */
>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>> - r->prod.tail = prod_next;
>> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>>   return ret;
>>  }
>>
>> @@ -385,8 +384,8 @@ int ___ring_mc_do_dequeue(_ring_t *r, void **obj_table,
>>   /* Restore n as it may change every loop */
>>   n = max;
>>
>> - cons_head = r->cons.head;
>> - prod_tail = r->prod.tail;
>> + cons_head = __atomic_load_n(&r->cons.head, __ATOMIC_RELAXED);
>> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUIRE);
>>   /* The subtraction is done between two unsigned 32bits value
>>* (the result is always modulo 32 bits even if we have
>>* cons_head > prod_tail). So 'entries' is always between 0
>> @@ -419,12 +418,12 @@ int ___ring_mc_do_dequeue(_ring_t *r, void **obj_table,
>>* If there are other dequeues in progress that preceded us,
>>* we need to wait for them to complete
>>*/
>> - while (odp_unlikely(r->cons.tail != cons_head))
>> + while (odp_unlikely(__atomic_load_n(&r->cons.tail, __ATOMIC_RELAXED) !=
>> + cons_head))
>>   odp_cpu_pause();
>>
>>   /* Release our entries and the memory they refer to */
>> - __atomic_thread_fence(__ATOMIC_RELEASE);
>> - r->cons.tail = cons_next;
>> + __atomic_store_n(&r->cons.tail, cons_next, __ATOMIC_RELEASE);
>>
>>   return behavior == _RING_QUEUE_FIXED ? 0 : n;
>>  }
>> @@ -441,7 +440,7 @@ int ___ring_sc_do_dequeue(_ring_t *r, void **obj_table,
>>   uint32_t mask = r->prod.mask;
>>
>>   cons_head = r->cons.head;
>> - prod_tail = r->prod.tail;
>> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUIRE);
>>   /* The subtraction is done between two unsigned 32bits value
>>* (the result is always modulo 32 bits even if we have
>>* cons_head > prod_tail). So 'entries' is always between 0
>>

Re: [lng-odp] [API-NEXT 2/4] linux-generic: ring.c: use required memory orderings

[Maxim Uvarov]

On 03/28/17 22:23, Brian Brooks wrote:
> From: Ola Liljedahl 
> 
> Signed-off-by: Ola Liljedahl 
> Reviewed-by: Brian Brooks 
> ---
>  platform/linux-generic/pktio/ring.c | 30 ++
>  1 file changed, 14 insertions(+), 16 deletions(-)
>  mode change 100644 => 100755 platform/linux-generic/pktio/ring.c
> 
> diff --git a/platform/linux-generic/pktio/ring.c 
> b/platform/linux-generic/pktio/ring.c
> old mode 100644
> new mode 100755


no need of setting executable permissions to c file. And of course you
have to run checkpatch.pl or push that code to github and it will do all
required checks.

I will fix it, no need to resend.

Maxim.

> index aeda04b2..e3c73d1c
> --- a/platform/linux-generic/pktio/ring.c
> +++ b/platform/linux-generic/pktio/ring.c
> @@ -263,8 +263,8 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
> *obj_table,
>   /* Reset n to the initial burst count */
>   n = max;
>  
> - prod_head = r->prod.head;
> - cons_tail = r->cons.tail;
> + prod_head = __atomic_load_n(&r->prod.head, __ATOMIC_RELAXED);
> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>   /* The subtraction is done between two unsigned 32bits value
>* (the result is always modulo 32 bits even if we have
>* prod_head > cons_tail). So 'free_entries' is always between 0
> @@ -306,12 +306,12 @@ int ___ring_mp_do_enqueue(_ring_t *r, void * const 
> *obj_table,
>* If there are other enqueues in progress that preceded us,
>* we need to wait for them to complete
>*/
> - while (odp_unlikely(r->prod.tail != prod_head))
> + while (odp_unlikely(__atomic_load_n(&r->prod.tail, __ATOMIC_RELAXED) !=
> + prod_head))
>   odp_cpu_pause();
>  
>   /* Release our entries and the memory they refer to */
> - __atomic_thread_fence(__ATOMIC_RELEASE);
> - r->prod.tail = prod_next;
> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>   return ret;
>  }
>  
> @@ -328,7 +328,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
> *obj_table,
>   int ret;
>  
>   prod_head = r->prod.head;
> - cons_tail = r->cons.tail;
> + cons_tail = __atomic_load_n(&r->cons.tail, __ATOMIC_ACQUIRE);
>   /* The subtraction is done between two unsigned 32bits value
>* (the result is always modulo 32 bits even if we have
>* prod_head > cons_tail). So 'free_entries' is always between 0
> @@ -361,8 +361,7 @@ int ___ring_sp_do_enqueue(_ring_t *r, void * const 
> *obj_table,
>   }
>  
>   /* Release our entries and the memory they refer to */
> - __atomic_thread_fence(__ATOMIC_RELEASE);
> - r->prod.tail = prod_next;
> + __atomic_store_n(&r->prod.tail, prod_next, __ATOMIC_RELEASE);
>   return ret;
>  }
>  
> @@ -385,8 +384,8 @@ int ___ring_mc_do_dequeue(_ring_t *r, void **obj_table,
>   /* Restore n as it may change every loop */
>   n = max;
>  
> - cons_head = r->cons.head;
> - prod_tail = r->prod.tail;
> + cons_head = __atomic_load_n(&r->cons.head, __ATOMIC_RELAXED);
> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUIRE);
>   /* The subtraction is done between two unsigned 32bits value
>* (the result is always modulo 32 bits even if we have
>* cons_head > prod_tail). So 'entries' is always between 0
> @@ -419,12 +418,12 @@ int ___ring_mc_do_dequeue(_ring_t *r, void **obj_table,
>* If there are other dequeues in progress that preceded us,
>* we need to wait for them to complete
>*/
> - while (odp_unlikely(r->cons.tail != cons_head))
> + while (odp_unlikely(__atomic_load_n(&r->cons.tail, __ATOMIC_RELAXED) !=
> + cons_head))
>   odp_cpu_pause();
>  
>   /* Release our entries and the memory they refer to */
> - __atomic_thread_fence(__ATOMIC_RELEASE);
> - r->cons.tail = cons_next;
> + __atomic_store_n(&r->cons.tail, cons_next, __ATOMIC_RELEASE);
>  
>   return behavior == _RING_QUEUE_FIXED ? 0 : n;
>  }
> @@ -441,7 +440,7 @@ int ___ring_sc_do_dequeue(_ring_t *r, void **obj_table,
>   uint32_t mask = r->prod.mask;
>  
>   cons_head = r->cons.head;
> - prod_tail = r->prod.tail;
> + prod_tail = __atomic_load_n(&r->prod.tail, __ATOMIC_ACQUIRE);
>   /* The subtraction is done between two unsigned 32bits value
>* (the result is always modulo 32 bits even if we have
>* cons_head > prod_tail). So 'entries' is always between 0
> @@ -461,11 +460,10 @@ int ___ring_sc_do_dequeue(_ring_t *r, void **obj_table,
>   r->cons.head = cons_next;
>  
>   /* Acquire the pointers and the memory they refer to */
> - __atomic_thread_fence(__ATOMIC_ACQUIRE);
>   /* copy in table */
>   DEQUEUE_PTRS();
>  
> 

[lng-odp] [PATCH v5 3/3] validation: packet: use common define for test pool sizes

[Matias Elo]

Signed-off-by: Matias Elo 
---
V5:
- Added common define

 test/common_plat/validation/api/packet/packet.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/common_plat/validation/api/packet/packet.c 
b/test/common_plat/validation/api/packet/packet.c
index 8c2a7c7..38763c0 100644
--- a/test/common_plat/validation/api/packet/packet.c
+++ b/test/common_plat/validation/api/packet/packet.c
@@ -1386,7 +1386,7 @@ void packet_test_concat_small(void)
 
param.type= ODP_POOL_PACKET;
param.pkt.len = len;
-   param.pkt.num = 100;
+   param.pkt.num = PACKET_POOL_NUM;
 
pool = odp_pool_create("packet_pool_concat", ¶m);
CU_ASSERT(packet_pool != ODP_POOL_INVALID);
@@ -1451,7 +1451,7 @@ void packet_test_concat_extend_trunc(void)
 
param.type= ODP_POOL_PACKET;
param.pkt.len = len;
-   param.pkt.num = 100;
+   param.pkt.num = PACKET_POOL_NUM;
 
pool = odp_pool_create("packet_pool_concat", ¶m);
CU_ASSERT_FATAL(packet_pool != ODP_POOL_INVALID);
@@ -1544,7 +1544,7 @@ void packet_test_extend_small(void)
 
param.type= ODP_POOL_PACKET;
param.pkt.len = len;
-   param.pkt.num = 100;
+   param.pkt.num = PACKET_POOL_NUM;
 
pool = odp_pool_create("packet_pool_extend", ¶m);
CU_ASSERT_FATAL(packet_pool != ODP_POOL_INVALID);
@@ -1639,7 +1639,7 @@ void packet_test_extend_large(void)
 
param.type= ODP_POOL_PACKET;
param.pkt.len = len;
-   param.pkt.num = 100;
+   param.pkt.num = PACKET_POOL_NUM;
 
pool = odp_pool_create("packet_pool_extend", ¶m);
CU_ASSERT_FATAL(packet_pool != ODP_POOL_INVALID);
@@ -1758,7 +1758,7 @@ void packet_test_extend_mix(void)
 
param.type= ODP_POOL_PACKET;
param.pkt.len = len;
-   param.pkt.num = 100;
+   param.pkt.num = PACKET_POOL_NUM;
 
pool = odp_pool_create("packet_pool_extend", ¶m);
CU_ASSERT_FATAL(packet_pool != ODP_POOL_INVALID);
-- 
2.7.4

[lng-odp] [PATCH v5 1/3] validation: packet: increase test pool size

[Matias Elo]

Previously packet_test_concatsplit() could fail on some pool
implementations as the pool ran out of buffers. Increase default pools size
and use capability to make sure the value is valid.

Signed-off-by: Matias Elo 
---
 test/common_plat/validation/api/packet/packet.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/test/common_plat/validation/api/packet/packet.c 
b/test/common_plat/validation/api/packet/packet.c
index 669122a..1997139 100644
--- a/test/common_plat/validation/api/packet/packet.c
+++ b/test/common_plat/validation/api/packet/packet.c
@@ -13,6 +13,8 @@
 #define PACKET_BUF_LEN ODP_CONFIG_PACKET_SEG_LEN_MIN
 /* Reserve some tailroom for tests */
 #define PACKET_TAILROOM_RESERVE  4
+/* Number of packets in the test packet pool */
+#define PACKET_POOL_NUM 300
 
 static odp_pool_t packet_pool, packet_pool_no_uarea, packet_pool_double_uarea;
 static uint32_t packet_len;
@@ -109,6 +111,7 @@ int packet_suite_init(void)
uint32_t udat_size;
uint8_t data = 0;
uint32_t i;
+   uint32_t num = PACKET_POOL_NUM;
 
if (odp_pool_capability(&capa) < 0) {
printf("pool_capability failed\n");
@@ -130,13 +133,15 @@ int packet_suite_init(void)
segmented_packet_len = capa.pkt.min_seg_len *
   capa.pkt.max_segs_per_pkt;
}
+   if (capa.pkt.max_num != 0 && capa.pkt.max_num < num)
+   num = capa.pkt.max_num;
 
odp_pool_param_init(¶ms);
 
params.type   = ODP_POOL_PACKET;
params.pkt.seg_len= capa.pkt.min_seg_len;
params.pkt.len= capa.pkt.min_seg_len;
-   params.pkt.num= 100;
+   params.pkt.num= num;
params.pkt.uarea_size = sizeof(struct udata_struct);
 
packet_pool = odp_pool_create("packet_pool", ¶ms);
-- 
2.7.4

[lng-odp] [PATCH v5 2/3] validation: packet: remove invalid check from packet_test_alloc_segmented()

[Matias Elo]

One can't assume that the packet should be segmented as this test is using
a different pool with different parameters than the default test pool.

Signed-off-by: Matias Elo 
---
 test/common_plat/validation/api/packet/packet.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/test/common_plat/validation/api/packet/packet.c 
b/test/common_plat/validation/api/packet/packet.c
index 1997139..8c2a7c7 100644
--- a/test/common_plat/validation/api/packet/packet.c
+++ b/test/common_plat/validation/api/packet/packet.c
@@ -422,9 +422,6 @@ void packet_test_alloc_segmented(void)
CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
CU_ASSERT(odp_packet_len(pkt) == max_len);
 
-   if (segmentation_supported)
-   CU_ASSERT(odp_packet_is_segmented(pkt) == 1);
-
odp_packet_free(pkt);
 
num_alloc = 0;
-- 
2.7.4

Re: [lng-odp] [PATCHv4] test: generator: Updated global statistics calculation to provide useful/easy-to-parse information

[Bogdan Pricope]

Hi Maxim, Yi,

Since this part is fresh in our memory, can you please review this
patch as well?

BR,
Bogdan

On 15 March 2017 at 09:48, Bogdan Pricope  wrote:
> Signed-off-by: Bogdan Pricope 
> ---
>  example/generator/odp_generator.c | 57 
> ---
>  1 file changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 8062d87..adb94cc 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -568,7 +568,10 @@ static int gen_recv_thread(void *arg)
>  static void print_global_stats(int num_workers)
>  {
> odp_time_t cur, wait, next;
> -   uint64_t pkts, pkts_prev = 0, pps, maximum_pps = 0;
> +   uint64_t pkts_snd = 0, pkts_snd_prev = 0;
> +   uint64_t pps_snd = 0, maximum_pps_snd = 0;
> +   uint64_t pkts_rcv = 0, pkts_rcv_prev = 0;
> +   uint64_t pps_rcv = 0, maximum_pps_rcv = 0;
> int verbose_interval = 20;
> odp_thrmask_t thrd_mask;
>
> @@ -589,30 +592,40 @@ static void print_global_stats(int num_workers)
> continue;
>
> next = odp_time_sum(cur, wait);
> -
> -   if (args->appl.mode == APPL_MODE_RCV) {
> -   pkts = odp_atomic_load_u64(&counters.udp);
> -   printf(" total receive(UDP: %" PRIu64 ")\n", pkts);
> +   switch (args->appl.mode) {
> +   case APPL_MODE_RCV:
> +   pkts_rcv = odp_atomic_load_u64(&counters.ip);
> +   break;
> +   case APPL_MODE_PING:
> +   pkts_snd = odp_atomic_load_u64(&counters.seq);
> +   pkts_rcv = odp_atomic_load_u64(&counters.icmp);
> +   break;
> +   case APPL_MODE_UDP:
> +   pkts_snd = odp_atomic_load_u64(&counters.seq);
> +   break;
> +   default:
> continue;
> }
>
> -   if (args->appl.mode == APPL_MODE_PING) {
> -   pkts = odp_atomic_load_u64(&counters.icmp);
> -   printf(" total receive(ICMP: %" PRIu64 ")\n", pkts);
> -   }
> -
> -   pkts = odp_atomic_load_u64(&counters.seq);
> -   printf(" total sent: %" PRIu64 ", drops: %" PRIu64 "\n", pkts,
> -  odp_atomic_load_u64(&counters.tx_drops));
> -
> -   if (args->appl.mode == APPL_MODE_UDP) {
> -   pps = (pkts - pkts_prev) / verbose_interval;
> -   if (pps > maximum_pps)
> -   maximum_pps = pps;
> -   printf(" %" PRIu64 " pps, %" PRIu64 " max pps\n",
> -  pps, maximum_pps);
> -   pkts_prev = pkts;
> -   }
> +   pps_snd = (pkts_snd - pkts_snd_prev) / verbose_interval;
> +   pkts_snd_prev = pkts_snd;
> +   if (pps_snd > maximum_pps_snd)
> +   maximum_pps_snd = pps_snd;
> +
> +   pps_rcv = (pkts_rcv - pkts_rcv_prev) / verbose_interval;
> +   pkts_rcv_prev = pkts_rcv;
> +   if (pps_rcv > maximum_pps_rcv)
> +   maximum_pps_rcv = pps_rcv;
> +
> +   printf("sent: %" PRIu64 ", drops: %" PRIu64 ", "
> +   "send rate: %" PRIu64 " pps, "
> +   "max send rate: %" PRIu64 " pps, "
> +   "rcv: %" PRIu64 ", "
> +   "recv rate: %" PRIu64 " pps, "
> +   "max recv rate: %" PRIu64 " pps\n",
> +   pkts_snd, odp_atomic_load_u64(&counters.tx_drops),
> +   pps_snd, maximum_pps_snd,
> +   pkts_rcv, pps_rcv, maximum_pps_rcv);
> }
>  }
>
> --
> 1.9.1
>

Re: [lng-odp] [API-NEXT PATCH 1/2] api: queue: added queue size param

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

This has a small doxygen issue. Fixed that on v2.

[lng-odp] [API-NEXT PATCH v2 2/2] validation: queue: test queue max_num per type

[Petri Savolainen]

Updated implementation and test with type specific number of
queues.

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/odp_queue.c|  2 ++
 test/common_plat/validation/api/queue/queue.c | 43 ---
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/platform/linux-generic/odp_queue.c 
b/platform/linux-generic/odp_queue.c
index fcf4bf5..1114c95 100644
--- a/platform/linux-generic/odp_queue.c
+++ b/platform/linux-generic/odp_queue.c
@@ -175,6 +175,8 @@ int odp_queue_capability(odp_queue_capability_t *capa)
capa->max_ordered_locks = sched_fn->max_ordered_locks();
capa->max_sched_groups  = sched_fn->num_grps();
capa->sched_prios   = odp_schedule_num_prio();
+   capa->plain.max_num = capa->max_queues;
+   capa->sched.max_num = capa->max_queues;
 
return 0;
 }
diff --git a/test/common_plat/validation/api/queue/queue.c 
b/test/common_plat/validation/api/queue/queue.c
index 1f7913a..8a874a4 100644
--- a/test/common_plat/validation/api/queue/queue.c
+++ b/test/common_plat/validation/api/queue/queue.c
@@ -56,7 +56,7 @@ void queue_test_capa(void)
odp_queue_param_t qparams;
char name[ODP_QUEUE_NAME_LEN];
odp_queue_t queue[MAX_QUEUES];
-   uint32_t num_queues, i;
+   uint32_t num_queues, i, j;
 
memset(&capa, 0, sizeof(odp_queue_capability_t));
CU_ASSERT(odp_queue_capability(&capa) == 0);
@@ -65,34 +65,43 @@ void queue_test_capa(void)
CU_ASSERT(capa.max_ordered_locks != 0);
CU_ASSERT(capa.max_sched_groups != 0);
CU_ASSERT(capa.sched_prios != 0);
+   CU_ASSERT(capa.plain.max_num != 0);
+   CU_ASSERT(capa.sched.max_num != 0);
 
for (i = 0; i < ODP_QUEUE_NAME_LEN; i++)
name[i] = 'A' + (i % 26);
 
name[ODP_QUEUE_NAME_LEN - 1] = 0;
 
-   if (capa.max_queues > MAX_QUEUES)
-   num_queues = MAX_QUEUES;
-   else
-   num_queues = capa.max_queues;
-
odp_queue_param_init(&qparams);
 
-   for (i = 0; i < num_queues; i++) {
-   generate_name(name, i);
-   queue[i] = odp_queue_create(name, &qparams);
+   for (j = 0; j < 2; j++) {
+   if (j == 0) {
+   num_queues = capa.plain.max_num;
+   } else {
+   num_queues = capa.sched.max_num;
+   qparams.type = ODP_QUEUE_TYPE_SCHED;
+   }
+
+   if (num_queues > MAX_QUEUES)
+   num_queues = MAX_QUEUES;
+
+   for (i = 0; i < num_queues; i++) {
+   generate_name(name, i);
+   queue[i] = odp_queue_create(name, &qparams);
 
-   if (queue[i] == ODP_QUEUE_INVALID) {
-   CU_FAIL("Queue create failed");
-   num_queues = i;
-   break;
+   if (queue[i] == ODP_QUEUE_INVALID) {
+   CU_FAIL("Queue create failed");
+   num_queues = i;
+   break;
+   }
+
+   CU_ASSERT(odp_queue_lookup(name) != ODP_QUEUE_INVALID);
}
 
-   CU_ASSERT(odp_queue_lookup(name) != ODP_QUEUE_INVALID);
+   for (i = 0; i < num_queues; i++)
+   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
}
-
-   for (i = 0; i < num_queues; i++)
-   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
 }
 
 void queue_test_mode(void)
-- 
2.8.1

[lng-odp] [API-NEXT PATCH v2 1/2] api: queue: added queue size param

[Petri Savolainen]

Added capability information about maximum number of queues
and queue sizes. Both are defined per queue type, since
plain and scheduled queues may have different implementations
(e.g. one uses HW while the other is SW).

Added queue size parameter, which specifies how large
storage size application requires in minimum.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/queue.h | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
index 7972fea..55b7e44 100644
--- a/include/odp/api/spec/queue.h
+++ b/include/odp/api/spec/queue.h
@@ -100,7 +100,7 @@ typedef enum odp_queue_op_mode_t {
  * Queue capabilities
  */
 typedef struct odp_queue_capability_t {
-   /** Maximum number of event queues */
+   /** Maximum number of event queues of any type */
uint32_t max_queues;
 
/** Maximum number of ordered locks per queue */
@@ -112,6 +112,28 @@ typedef struct odp_queue_capability_t {
/** Number of scheduling priorities */
unsigned sched_prios;
 
+   /** Plain queue capabilities */
+   struct {
+   /** Maximum number of a plain queues. */
+   uint32_t max_num;
+
+   /** Maximum number of events a plain queue can store
+ * simultaneously. The value of zero means unlimited. */
+   uint32_t max_size;
+
+   } plain;
+
+   /** Scheduled queue capabilities */
+   struct {
+   /** Maximum number of a scheduled queues. */
+   uint32_t max_num;
+
+   /** Maximum number of events a scheduled queue can store
+ * simultaneously. The value of zero means unlimited. */
+   uint32_t max_size;
+
+   } sched;
+
 } odp_queue_capability_t;
 
 /**
@@ -165,6 +187,15 @@ typedef struct odp_queue_param_t {
  * The implementation may use this value as a hint for the number of
  * context data bytes to prefetch. Default value is zero (no hint). */
uint32_t context_len;
+
+   /** Queue size
+ *
+ * The queue must be able to store in minimum this many events
+ * simultaneously. The value must not exceed 'max_size' queue
+ * capability. The value of zero means implementation specific
+ * default size. */
+   uint32_t size;
+
 } odp_queue_param_t;
 
 /**
-- 
2.8.1

[lng-odp] [API-NEXT PATCH 2/2] validation: queue: test queue max_num per type

[Petri Savolainen]

Updated implementation and test with type specific number of
queues.

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/odp_queue.c|  2 ++
 test/common_plat/validation/api/queue/queue.c | 43 ---
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/platform/linux-generic/odp_queue.c 
b/platform/linux-generic/odp_queue.c
index fcf4bf5..1114c95 100644
--- a/platform/linux-generic/odp_queue.c
+++ b/platform/linux-generic/odp_queue.c
@@ -175,6 +175,8 @@ int odp_queue_capability(odp_queue_capability_t *capa)
capa->max_ordered_locks = sched_fn->max_ordered_locks();
capa->max_sched_groups  = sched_fn->num_grps();
capa->sched_prios   = odp_schedule_num_prio();
+   capa->plain.max_num = capa->max_queues;
+   capa->sched.max_num = capa->max_queues;
 
return 0;
 }
diff --git a/test/common_plat/validation/api/queue/queue.c 
b/test/common_plat/validation/api/queue/queue.c
index 1f7913a..8a874a4 100644
--- a/test/common_plat/validation/api/queue/queue.c
+++ b/test/common_plat/validation/api/queue/queue.c
@@ -56,7 +56,7 @@ void queue_test_capa(void)
odp_queue_param_t qparams;
char name[ODP_QUEUE_NAME_LEN];
odp_queue_t queue[MAX_QUEUES];
-   uint32_t num_queues, i;
+   uint32_t num_queues, i, j;
 
memset(&capa, 0, sizeof(odp_queue_capability_t));
CU_ASSERT(odp_queue_capability(&capa) == 0);
@@ -65,34 +65,43 @@ void queue_test_capa(void)
CU_ASSERT(capa.max_ordered_locks != 0);
CU_ASSERT(capa.max_sched_groups != 0);
CU_ASSERT(capa.sched_prios != 0);
+   CU_ASSERT(capa.plain.max_num != 0);
+   CU_ASSERT(capa.sched.max_num != 0);
 
for (i = 0; i < ODP_QUEUE_NAME_LEN; i++)
name[i] = 'A' + (i % 26);
 
name[ODP_QUEUE_NAME_LEN - 1] = 0;
 
-   if (capa.max_queues > MAX_QUEUES)
-   num_queues = MAX_QUEUES;
-   else
-   num_queues = capa.max_queues;
-
odp_queue_param_init(&qparams);
 
-   for (i = 0; i < num_queues; i++) {
-   generate_name(name, i);
-   queue[i] = odp_queue_create(name, &qparams);
+   for (j = 0; j < 2; j++) {
+   if (j == 0) {
+   num_queues = capa.plain.max_num;
+   } else {
+   num_queues = capa.sched.max_num;
+   qparams.type = ODP_QUEUE_TYPE_SCHED;
+   }
+
+   if (num_queues > MAX_QUEUES)
+   num_queues = MAX_QUEUES;
+
+   for (i = 0; i < num_queues; i++) {
+   generate_name(name, i);
+   queue[i] = odp_queue_create(name, &qparams);
 
-   if (queue[i] == ODP_QUEUE_INVALID) {
-   CU_FAIL("Queue create failed");
-   num_queues = i;
-   break;
+   if (queue[i] == ODP_QUEUE_INVALID) {
+   CU_FAIL("Queue create failed");
+   num_queues = i;
+   break;
+   }
+
+   CU_ASSERT(odp_queue_lookup(name) != ODP_QUEUE_INVALID);
}
 
-   CU_ASSERT(odp_queue_lookup(name) != ODP_QUEUE_INVALID);
+   for (i = 0; i < num_queues; i++)
+   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
}
-
-   for (i = 0; i < num_queues; i++)
-   CU_ASSERT(odp_queue_destroy(queue[i]) == 0);
 }
 
 void queue_test_mode(void)
-- 
2.8.1

[lng-odp] [API-NEXT PATCH 1/2] api: queue: added queue size param

[Petri Savolainen]

Added capability information about maximum number of queues
and queue sizes. Both are defined per queue type, since
plain and scheduled queues may have different implementations
(e.g. one uses HW while the other is SW).

Added queue size parameter, which specifies how large
storage size application requires in minimum.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/queue.h | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
index 7972fea..fea72ca 100644
--- a/include/odp/api/spec/queue.h
+++ b/include/odp/api/spec/queue.h
@@ -100,7 +100,7 @@ typedef enum odp_queue_op_mode_t {
  * Queue capabilities
  */
 typedef struct odp_queue_capability_t {
-   /** Maximum number of event queues */
+   /** Maximum number of event queues of any type */
uint32_t max_queues;
 
/** Maximum number of ordered locks per queue */
@@ -112,6 +112,26 @@ typedef struct odp_queue_capability_t {
/** Number of scheduling priorities */
unsigned sched_prios;
 
+   struct {
+   /** Maximum number of a plain queues. */
+   uint32_t max_num;
+
+   /** Maximum number of events a plain queue can store
+ * simultaneously. The value of zero means unlimited. */
+   uint32_t max_size;
+
+   } plain;
+
+   struct {
+   /** Maximum number of a scheduled queues. */
+   uint32_t max_num;
+
+   /** Maximum number of events a scheduled queue can store
+ * simultaneously. The value of zero means unlimited. */
+   uint32_t max_size;
+
+   } sched;
+
 } odp_queue_capability_t;
 
 /**
@@ -165,6 +185,15 @@ typedef struct odp_queue_param_t {
  * The implementation may use this value as a hint for the number of
  * context data bytes to prefetch. Default value is zero (no hint). */
uint32_t context_len;
+
+   /** Queue size
+ *
+ * The queue must be able to store in minimum this many events
+ * simultaneously. The value must not exceed 'max_size' queue
+ * capability. The value of zero means implementation specific
+ * default size. */
+   uint32_t size;
+
 } odp_queue_param_t;
 
 /**
-- 
2.8.1

Re: [lng-odp] My last day at linaro/LNG

[Mike Holmes]

Sad to see you go Christophe, it really was energizing to work with you.

Mike

On Mar 31, 2017 7:13 AM, "Maxim Uvarov"  wrote:

> Thanks Christophe for all that work which you did! It's really good impact
> to the project. And all the best wishes in future.
>
> Maxim.
>
> On 31 March 2017 at 11:32, Yi He  wrote:
>
>> Hi, Christophe,
>>
>> Wish you all the best and joy in your new endeavors.
>>
>> Best Regards, Yi
>>
>> On 31 March 2017 at 16:27, Francois Ozog 
>> wrote:
>>
>> > Hi Christophe,
>> >
>> > It is a big loss for LNG.
>> >
>> > On the technical side you have both conceptual talent and great
>> > implementation skills. This is not so common and DDF was a challenge at
>> > your "measure" (as a French you will know what I mean as I don't know
>> if it
>> > translates well in English).
>> >
>> > Despite all that you were still a cool guy to interact with ;-)
>> >
>> > I don't know if Ericsson know how lucky they are but Linaro know what
>> it is
>> > loosing.
>> >
>> > Have fun in your new endeavors.
>> >
>> > Cordially
>> >
>> > FF
>> >
>> > Le ven. 31 mars 2017 à 10:19, Christophe Milard <
>> > christophe.mil...@linaro.org> a écrit :
>> >
>> > > Hi all,
>> > > As most of you know, my assignment for linaro/LNG is ending today.
>> > > I was really willing to join connect in Budapest as this would have
>> > > given me an opportunity to see you a last time face to face but this
>> > > did not happen, sadly.
>> > > I wish to thank all of you that helped me growing in this open source
>> > > world. It has been a very interesting time.
>> > > I do regret that the DDF work did not fully land before my departure.
>> > > Hopefully my work helped on the way...
>> > >
>> > > I'd be happy to see ODP growing... I'll keep an eye on it
>> > >
>> > > I wish you all the best,
>> > >
>> > > Regards,
>> > >
>> > > Christophe.
>> > >
>> > --
>> > [image: Linaro] 
>> > François-Frédéric Ozog | *Director Linaro Networking Group*
>> > T: +33.67221.6485 
>> > francois.o...@linaro.org | Skype: ffozog
>> >
>>
>
>

Re: [lng-odp] My last day at linaro/LNG

[Maxim Uvarov]

Thanks Christophe for all that work which you did! It's really good impact
to the project. And all the best wishes in future.

Maxim.

On 31 March 2017 at 11:32, Yi He  wrote:

> Hi, Christophe,
>
> Wish you all the best and joy in your new endeavors.
>
> Best Regards, Yi
>
> On 31 March 2017 at 16:27, Francois Ozog  wrote:
>
> > Hi Christophe,
> >
> > It is a big loss for LNG.
> >
> > On the technical side you have both conceptual talent and great
> > implementation skills. This is not so common and DDF was a challenge at
> > your "measure" (as a French you will know what I mean as I don't know if
> it
> > translates well in English).
> >
> > Despite all that you were still a cool guy to interact with ;-)
> >
> > I don't know if Ericsson know how lucky they are but Linaro know what it
> is
> > loosing.
> >
> > Have fun in your new endeavors.
> >
> > Cordially
> >
> > FF
> >
> > Le ven. 31 mars 2017 à 10:19, Christophe Milard <
> > christophe.mil...@linaro.org> a écrit :
> >
> > > Hi all,
> > > As most of you know, my assignment for linaro/LNG is ending today.
> > > I was really willing to join connect in Budapest as this would have
> > > given me an opportunity to see you a last time face to face but this
> > > did not happen, sadly.
> > > I wish to thank all of you that helped me growing in this open source
> > > world. It has been a very interesting time.
> > > I do regret that the DDF work did not fully land before my departure.
> > > Hopefully my work helped on the way...
> > >
> > > I'd be happy to see ODP growing... I'll keep an eye on it
> > >
> > > I wish you all the best,
> > >
> > > Regards,
> > >
> > > Christophe.
> > >
> > --
> > [image: Linaro] 
> > François-Frédéric Ozog | *Director Linaro Networking Group*
> > T: +33.67221.6485 
> > francois.o...@linaro.org | Skype: ffozog
> >
>

[lng-odp] [Bug 2921] odp_init_global() and odp_pool_create() set errno = 12

[bugzilla-daemon]

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

--- Comment #4 from Oriol Arcas  ---
Sorry, I meant that ODP calls a library or system call that sets errno.

I dug a little into the problem and I found that errno is set in
odp_shm_reserve(), which is called both by odp_init_global() and
odp_pool_create().

In my usual testbed I don't have huge pages, so the first mmap() fails (sets
errno to -12, "cannot allocate memory"). Then, it is retried with regular pages
and the ODP function succeeds. But the first errno is left at -12.

It is really a minor thing, but before mmap() is retried errno should be
cleared.

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

Re: [lng-odp] My last day at linaro/LNG

[Yi He]

Hi, Christophe,

Wish you all the best and joy in your new endeavors.

Best Regards, Yi

On 31 March 2017 at 16:27, Francois Ozog  wrote:

> Hi Christophe,
>
> It is a big loss for LNG.
>
> On the technical side you have both conceptual talent and great
> implementation skills. This is not so common and DDF was a challenge at
> your "measure" (as a French you will know what I mean as I don't know if it
> translates well in English).
>
> Despite all that you were still a cool guy to interact with ;-)
>
> I don't know if Ericsson know how lucky they are but Linaro know what it is
> loosing.
>
> Have fun in your new endeavors.
>
> Cordially
>
> FF
>
> Le ven. 31 mars 2017 à 10:19, Christophe Milard <
> christophe.mil...@linaro.org> a écrit :
>
> > Hi all,
> > As most of you know, my assignment for linaro/LNG is ending today.
> > I was really willing to join connect in Budapest as this would have
> > given me an opportunity to see you a last time face to face but this
> > did not happen, sadly.
> > I wish to thank all of you that helped me growing in this open source
> > world. It has been a very interesting time.
> > I do regret that the DDF work did not fully land before my departure.
> > Hopefully my work helped on the way...
> >
> > I'd be happy to see ODP growing... I'll keep an eye on it
> >
> > I wish you all the best,
> >
> > Regards,
> >
> > Christophe.
> >
> --
> [image: Linaro] 
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485 
> francois.o...@linaro.org | Skype: ffozog
>

Re: [lng-odp] My last day at linaro/LNG

[Francois Ozog]

Hi Christophe,

It is a big loss for LNG.

On the technical side you have both conceptual talent and great
implementation skills. This is not so common and DDF was a challenge at
your "measure" (as a French you will know what I mean as I don't know if it
translates well in English).

Despite all that you were still a cool guy to interact with ;-)

I don't know if Ericsson know how lucky they are but Linaro know what it is
loosing.

Have fun in your new endeavors.

Cordially

FF

Le ven. 31 mars 2017 à 10:19, Christophe Milard <
christophe.mil...@linaro.org> a écrit :

> Hi all,
> As most of you know, my assignment for linaro/LNG is ending today.
> I was really willing to join connect in Budapest as this would have
> given me an opportunity to see you a last time face to face but this
> did not happen, sadly.
> I wish to thank all of you that helped me growing in this open source
> world. It has been a very interesting time.
> I do regret that the DDF work did not fully land before my departure.
> Hopefully my work helped on the way...
>
> I'd be happy to see ODP growing... I'll keep an eye on it
>
> I wish you all the best,
>
> Regards,
>
> Christophe.
>
-- 
[image: Linaro] 
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485 
francois.o...@linaro.org | Skype: ffozog

[lng-odp] My last day at linaro/LNG

[Christophe Milard]

Hi all,
As most of you know, my assignment for linaro/LNG is ending today.
I was really willing to join connect in Budapest as this would have
given me an opportunity to see you a last time face to face but this
did not happen, sadly.
I wish to thank all of you that helped me growing in this open source
world. It has been a very interesting time.
I do regret that the DDF work did not fully land before my departure.
Hopefully my work helped on the way...

I'd be happy to see ODP growing... I'll keep an eye on it

I wish you all the best,

Regards,

Christophe.

[lng-odp] [PATCH] helper: iplookuptable: fix prefix_entry_t member order

[Matias Elo]

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

Signed-off-by: Matias Elo 
---
 helper/iplookuptable.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/helper/iplookuptable.c b/helper/iplookuptable.c
index aae2199..37d31e3 100644
--- a/helper/iplookuptable.c
+++ b/helper/iplookuptable.c
@@ -42,6 +42,10 @@
  */
 typedef struct {
union {
+   odp_buffer_t nexthop;
+   void *ptr;
+   };
+   union {
uint8_t u8;
struct {
 #if ODP_BYTE_ORDER == ODP_BIG_ENDIAN
@@ -53,10 +57,6 @@ typedef struct {
 #endif
};
};
-   union {
-   odp_buffer_t nexthop;
-   void *ptr;
-   };
 } prefix_entry_t;
 
 #define ENTRY_SIZE (sizeof(prefix_entry_t) + sizeof(odp_buffer_t))
-- 
2.7.4

Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet checksum control

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

> -Original Message-
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Wednesday, March 29, 2017 6:01 PM
> To: Bogdan Pricope 
> Cc: Maxim Uvarov ; Savolainen, Petri (Nokia -
> FI/Espoo) ; lng-odp-forward  o...@lists.linaro.org>
> Subject: Re: [lng-odp] [API-NEXT PATCH] api: packet: add per packet
> checksum control
> 
> On Wed, Mar 29, 2017 at 8:38 AM, Bogdan Pricope
>  wrote:
> >
> > What about:
> >
> > void odp_packet_out_l3_csum_override(odp_packet_t pkt, odp_bool_t
> compute);
> 
> That's a bit of a mouthful. Since chksum insertion only makes sense on
> output that's implied here, so I think Petri's name choices seem clear
> and natural.

Also the same function will used to control IPSEC inner packet checksum 
insertion (and other potential tunnel offloads). So, it's not only for packet 
out, but generally control between "insert" vs "do not insert" checksum.

-Petri