[lng-odp] [PATCHv2] doc: users-guide: add packet drop and error CoS documentation

[Balasubramanian Manoharan]

Adds documentation for packet drop policy and Error Class of service

Signed-off-by: Balasubramanian Manoharan 
---
 doc/users-guide/users-guide-cls.adoc | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/doc/users-guide/users-guide-cls.adoc 
b/doc/users-guide/users-guide-cls.adoc
index d2ba743..a689826 100644
--- a/doc/users-guide/users-guide-cls.adoc
+++ b/doc/users-guide/users-guide-cls.adoc
@@ -109,7 +109,30 @@ pools. Multiple odp_pktio instances (i.e., multiple ports) 
may each have their
 own default odp_cos, or may share a odp_cos with other ports, based on
 application requirements.
 
-Packet Classification
+=== Error packet handling
+
+Error class of service is assigned to an ingress port using the function
+`odp_pktio_error_cos_set()`. All the packets received with error from this
+specific ingress port are assigned to this error class-of-service.
+At minimum this error class-of-service must have a queue and a buffer pool
+assigned to it. Multiple pktio instances (_i.e.,_ multiple ports) may each have
+their own error class of service, or may share an error CoS with other ports,
+based on application requirements.
+
+=== Packet dropping
+
+Each class of service has a `drop_policy` configured during creation. The
+valid value are ODP_COS_DROP_POOL and ODP_COS_DROP_NEVER. If the `drop_policy`
+is set to ODP_COS_DROP_POOL then the packets assigned to the CoS follows the
+drop policy of the associated pool _i.e.,_ depending on the Random Early 
Discard
+or any other configuration of the pool the packet might get dropped. If the
+`drop_policy` is set to ODP_COS_DROP_NEVER then the Random Early Discard of the
+pool is ignored.
+
+During creation of the class of service if the pool or queue is set as INVALID
+using ODP_POOL_INVALID or ODP_QUEUE_INVALID field then any packet assigned to 
the specific CoS are dropped.
+
+=== Packet Classification
 
 For each odp_pktio port, the API allows the assignment of a class-of-service to
 a packet using one of  three methods:
@@ -136,7 +159,7 @@ destination or source port numbers, and appropriately 
assign these packets a
 class-of-service that maps to a higher priority queue, assuring voice packets a
 lower and bound latency.
 
-Packet meta data Elements
+=== Packet meta data Elements
 
 Here are the specific information elements that are stored within the
 packet meta data structure:
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH v3] linux-generic: test: ring: convert to cunit and improve coverage

[Yi He]

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

Convert ring test program into cunit framework
Improve LCOV coverage for linux-generic/pktio/ring.c

Signed-off-by: Yi He 
---
 platform/linux-generic/test/Makefile.am|   2 +-
 platform/linux-generic/test/ring/Makefile.am   |  20 +-
 platform/linux-generic/test/ring/ring_basic.c  | 359 ++
 platform/linux-generic/test/ring/ring_main.c   |  12 +
 platform/linux-generic/test/ring/ring_stress.c | 237 
 platform/linux-generic/test/ring/ring_suites.c |  74 
 platform/linux-generic/test/ring/ring_suites.h |  33 ++
 platform/linux-generic/test/ring/ringtest.c| 495 -
 8 files changed, 725 insertions(+), 507 deletions(-)
 create mode 100644 platform/linux-generic/test/ring/ring_basic.c
 create mode 100644 platform/linux-generic/test/ring/ring_main.c
 create mode 100644 platform/linux-generic/test/ring/ring_stress.c
 create mode 100644 platform/linux-generic/test/ring/ring_suites.c
 create mode 100644 platform/linux-generic/test/ring/ring_suites.h
 delete mode 100644 platform/linux-generic/test/ring/ringtest.c

diff --git a/platform/linux-generic/test/Makefile.am 
b/platform/linux-generic/test/Makefile.am
index f74185d..2d58c57 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -8,7 +8,7 @@ ODP_MODULES = pktio \
 if test_vald
 TESTS = pktio/pktio_run.sh \
pktio/pktio_run_tap.sh \
-   ring/ringtest$(EXEEXT) \
+   ring/ring_main$(EXEEXT) \
shmem/shmem_linux \
${top_builddir}/test/validation/atomic/atomic_main$(EXEEXT) \
${top_builddir}/test/validation/barrier/barrier_main$(EXEEXT) \
diff --git a/platform/linux-generic/test/ring/Makefile.am 
b/platform/linux-generic/test/ring/Makefile.am
index 5a949d0..c086584 100644
--- a/platform/linux-generic/test/ring/Makefile.am
+++ b/platform/linux-generic/test/ring/Makefile.am
@@ -1,16 +1,14 @@
-include $(top_srcdir)/test/validation/Makefile.inc
+include ../Makefile.inc
 
-AM_CFLAGS += -I$(srcdir)/common
-AM_CFLAGS += -I$(top_srcdir)/test/validation/common
-AM_LDFLAGS += -static
+noinst_LTLIBRARIES = libtestring.la
+libtestring_la_SOURCES = ring_suites.c ring_basic.c ring_stress.c
+libtestring_la_CFLAGS = $(AM_CFLAGS) $(INCCUNIT_COMMON) $(INCODP)
 
-COMPILE_ONLY =
+test_PROGRAMS = ring_main$(EXEEXT)
+dist_ring_main_SOURCES = ring_main.c
 
-TESTSCRIPTS =
+ring_main_LDFLAGS = $(AM_LDFLAGS)
+ring_main_LDADD = libtestring.la $(LIBCUNIT_COMMON) $(LIBODP)
 
-EXECUTABLES = ringtest$(EXEEXT)
+noinst_HEADERS = ring_suites.h
 
-test_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
-
-ringtest_SOURCES = ringtest.c
-ringtest_LDADD = $(LIBCUNIT_COMMON) $(LIBODP)
diff --git a/platform/linux-generic/test/ring/ring_basic.c 
b/platform/linux-generic/test/ring/ring_basic.c
new file mode 100644
index 000..8daaa9f
--- /dev/null
+++ b/platform/linux-generic/test/ring/ring_basic.c
@@ -0,0 +1,359 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP ring basic test
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "ring_suites.h"
+
+/* labor functions declaration */
+static void __do_basic_burst(_ring_t *r);
+static void __do_basic_bulk(_ring_t *r);
+static void __do_basic_watermark(_ring_t *r);
+
+/* dummy object pointers for enqueue and dequeue testing */
+static void **test_enq_data;
+static void **test_deq_data;
+
+/* create two rings: one for single thread usage scenario
+ * and another for multiple thread usage scenario.
+ * st - single thread usage scenario
+ * mt - multiple thread usage scenario
+ */
+static const char *st_ring_name = "ST basic ring";
+static const char *mt_ring_name = "MT basic ring";
+static _ring_t *st_ring, *mt_ring;
+
+int ring_test_basic_start(void)
+{
+   int i = 0;
+
+   /* alloc dummy object pointers for enqueue testing */
+   test_enq_data = malloc(RING_SIZE * 2 * sizeof(void *));
+   if (NULL == test_enq_data) {
+   LOG_ERR("failed to allocate basic test enqeue data\n");
+   return -1;
+   }
+
+   for (i = 0; i < RING_SIZE * 2; i++)
+   test_enq_data[i] = (void *)(unsigned long)i;
+
+   /* alloc dummy object pointers for dequeue testing */
+   test_deq_data = malloc(RING_SIZE * 2 * sizeof(void *));
+   if (NULL == test_deq_data) {
+   LOG_ERR("failed to allocate basic test dequeue data\n");
+   free(test_enq_data); test_enq_data = NULL;
+   return -1;
+   }
+
+   memset(test_deq_data, 0, RING_SIZE * 2 * sizeof(void *));
+   return 0;
+}
+
+int ring_test_basic_end(void)
+{
+   free(test_enq_data);
+   free(test_deq_data);
+   return 0;
+}
+
+/* basic test cases */
+void ring_test_basic_create(void)
+{
+   /* prove illegal size shall fail */
+   st_ring = _ring_create(st_ring_name, ILLEGAL_SIZE,

Re: [lng-odp] [PATCH 2/2] doc: userguide: add notes on threads and addressing scope

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

> >>
> >>  === Addressing Scope
> >> -Unless specifically noted in the API, all ODP resources are global to
> >> the ODP
> >> -application, whether it runs as a single process or multiple
> processes.
> >> ODP
> >> -handles therefore have common meaning within an ODP application but
> have
> >> no
> >> -meaning outside the scope of the application.
> >> +ODP objects and their associated handles are intended to be global to
> an
> >> ODP
> >> +instance, _i.e.,_ to the thread that calls `odp_init_global()` and its
> >> +descendants.
> >
> >
> > This is saying that all ODP threads of a given ODP instance are
> descendant
> > of the ODP instantiation process. I already tried to define ODP threads
> > this way, but it was rejected, and the ODP instance number was added to
> the
> > API so that any thread/process could join any ODP instance.
> >
> 
> We should revisit that because without this assumption I don't think we
> can
> define a consistent set of semantics for ODP object visibility.  For
> example, if I create an ODP instance and then pass the instance ID
> privately to a completely separate program, do we expect it to be able to
> use that instance ID to join the (remote) ODP instance by calling
> odp_init_local()?  Clearly not.
> 

Yes, if the implementation supports that. E.g. there's no processes or pthreads 
in when an SDK runs in bare metal mode. Each cpu starts from C lib / SDK 
startup code and stops at some point to wait others. There's some shared memory 
set up at init phase. You could start up e.g. two separate ODP instances of 
ODP, so that half of the cpus joins the first instance and the other half joins 
the other instance.

odp-linux would not support (at least at first) non-related processes to form 
an instance. But API would not limit, if support for it would be added later.


> 
> > I still get the feeling that, despite this add-on, we are still saying
> > that a odpthread belongs to the ODP instance it is a descendand of,
> rather
> > than the one specified in the "instance" parameter passed at
> > odp_local_init() time...
> > The only possible usage of the odp_instance parameter passed at
> > odp_local_init() time would then be on OSes which do not support process
> > hierarchy... Is any such OS known to suport ODP?
> >
> 
> I concur. I think it's there more for potential future flexibility than
> anything else since it's effectively a dummy parameter with a single
> hard-coded value in odp-linux. I see no harm in it being there, but it's
> presence doesn't change the fact that ODP instances only cover the
> odp_global_init() caller and its descendants.


This is the point. Instance ID enables various thread setups (for linux, RTOS, 
bare metal, ...), odp-linux implements some of those.


> 
> 
> > If not, I thing the odp_instance number should either be suppressed, or
> > clearly stated as meaningless on OS which have process hierarchy, as the
> > process hierarchy seems to take precedence over this parameter in all
> our
> > discussions.


An implementation may use the instance ID any way it likes. It may carry a file 
name, file descriptor, index to shared memory, magic number, ... etc 
information to find the instance or just error check that global_init was 
indeed called before local_init was called. No need to state it meaningless for 
any implementation.


> >
> > Confused: are talking monarch or some later version? BTW is monarch the
> > name of the API version only or does the "monarch" name also include the
> > linux-generic  platform example?
> >
> 
> Both. Monarch is the current API level and odp-linux implements that level
> of the ODP API. These statements will still be true of Monarch even after
> we move on to Tiger Moth, which may or may not introduce additional
> capabilities.
> 

Monarch is API level and various implementations will be maintained for it for 
"a long time". E.g. during that time, odp-linux will be optimized further, new 
pktios may be added, process mode support will be added, new implementation 
specific configuration file / parameters may be introduced, ... API remains the 
same but implementations may evolve.




> 
> >
> >
> >> +
> >> +If a platform uses process that follow a Unix-style `fork()` model of
> >> process
> >> +creation, then for best portability ODP applications should be
> designed
> >> so
> >> +that any ODP resource creation (_e.g.,_ pools, shared memory objects,
> >> pktios)
> >>
> >
> > "any  ODP resource": That includes everything, e.g. atomics, barrier,
> > timers... as well...right...?
> >
> 
> The key word here is creation, not declaration or allocation.  Atomics,
> barriers, and locks are not created, they are declared and initialized, so
> the caller is controlling the space that they occupy.  Similarly packets
> and timers are allocated from pools that are created, so these objects
> inherit their visibility from the pools they are drawn from. The
> requirement is that the pools be created at a point of common
> addr

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Yi He]

Hi, Christophe

Here I met a difficulty, if I unified the API into
odph_odpthread_set_affinity(),
inside the function how can I determine whether the current context is a
pthread or process? So I cannot decide to call sched_setaffinity() or
pthread_setaffinity_np().

thanks and best regards, Yi



On 23 May 2016 at 14:53, Yi He  wrote:

> Hi, Christophe
>
> Yes, I'll apply your series and send a new one later.
>
> Best Regards, Yi
>
> On 23 May 2016 at 14:33, Christophe Milard 
> wrote:
>
>>
>>
>> On 20 May 2016 at 10:48, Yi He  wrote:
>>
>>> Set affinity to 1st available control cpu for all odp
>>> validation programs in odp_cunit_common library.
>>>
>>> Signed-off-by: Yi He 
>>> ---
>>>  helper/include/odp/helper/linux.h | 47 +++
>>>  helper/linux.c| 32 +
>>>  helper/test/thread.c  | 76
>>> +--
>>>  test/validation/common/odp_cunit_common.c | 15 --
>>>  4 files changed, 164 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/helper/include/odp/helper/linux.h
>>> b/helper/include/odp/helper/linux.h
>>> index e2dca35..fa815e1 100644
>>> --- a/helper/include/odp/helper/linux.h
>>> +++ b/helper/include/odp/helper/linux.h
>>> @@ -84,6 +84,29 @@ int odph_linux_pthread_create(odph_linux_pthread_t
>>> *pthread_tbl,
>>>   */
>>>  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int num);
>>>
>>> +/**
>>> + * Set CPU affinity of the current thread
>>> + *
>>> + * CPU affinity determines the set of CPUs on which the thread is
>>> + * eligible to run.
>>> + *
>>> + * @param cpusetA bitmask lists the affinity CPU cores
>>> + *
>>> + * @return 0 on success, -1 on failure
>>> + */
>>> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);
>>>
>>
>> odph_odpthread_set_affinity(), is I guess better, at least as long as we
>> try to keep thread and processes together. Dropping the linux prefix makes
>> also the code more portable (on some other OS, change provide new helpers
>> and the app does hopefully not need to change)
>>
>> I guess you can apply the "running things in  process mode" patch series
>> to see what I am after...
>>
>> This comment applies to all your function names, of course.
>>
>> Christophe
>>
>> +
>>> +/**
>>> + * Get CPU affinity of the current thread
>>> + *
>>> + * CPU affinity determines the set of CPUs on which the thread is
>>> + * eligible to run.
>>> + *
>>> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
>>> + *
>>> + * @return 0 on success, -1 on failure
>>> + */
>>> +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset);
>>>
>>>  /**
>>>   * Fork a process
>>> @@ -134,6 +157,30 @@ int odph_linux_process_fork_n(odph_linux_process_t
>>> *proc_tbl,
>>>  int odph_linux_process_wait_n(odph_linux_process_t *proc_tbl, int num);
>>>
>>>  /**
>>> + * Set CPU affinity of the current process
>>> + *
>>> + * CPU affinity determines the set of CPUs on which the process is
>>> + * eligible to run.
>>> + *
>>> + * @param cpusetA bitmask lists the affinity CPU cores
>>> + *
>>> + * @return 0 on success, -1 on failure
>>> + */
>>> +int odph_linux_process_setaffinity(const odp_cpumask_t *cpuset);
>>> +
>>> +/**
>>> + * Get CPU affinity of the current process
>>> + *
>>> + * CPU affinity determines the set of CPUs on which the process is
>>> + * eligible to run.
>>> + *
>>> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
>>> + *
>>> + * @return 0 on success, -1 on failure
>>> + */
>>> +int odph_linux_process_getaffinity(odp_cpumask_t *cpuset);
>>> +
>>> +/**
>>>   * @}
>>>   */
>>>
>>> diff --git a/helper/linux.c b/helper/linux.c
>>> index 24e243b..6ce7e7d 100644
>>> --- a/helper/linux.c
>>> +++ b/helper/linux.c
>>> @@ -114,6 +114,22 @@ void odph_linux_pthread_join(odph_linux_pthread_t
>>> *thread_tbl, int num)
>>> }
>>>  }
>>>
>>> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset)
>>> +{
>>> +   const cpu_set_t *_cpuset = &cpuset->set;
>>> +
>>> +   return (0 == pthread_setaffinity_np(pthread_self(),
>>> +   sizeof(cpu_set_t), _cpuset)) ? 0 : -1;
>>> +}
>>> +
>>> +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset)
>>> +{
>>> +   cpu_set_t *_cpuset = &cpuset->set;
>>> +
>>> +   return (0 == pthread_getaffinity_np(pthread_self(),
>>> +   sizeof(cpu_set_t), _cpuset)) ? 0 : -1;
>>> +}
>>> +
>>>  int odph_linux_process_fork_n(odph_linux_process_t *proc_tbl,
>>>   const odp_cpumask_t *mask,
>>>   const odph_linux_thr_params_t *thr_params)
>>> @@ -236,3 +252,19 @@ int odph_linux_process_wait_n(odph_linux_process_t
>>> *proc_tbl, int num)
>>>
>>> return 0;
>>>  }
>>> +
>>> +int odph_linux_process_setaffinity(const odp_cpumask_t *cpuset)
>>> +{
>>> +   const cpu_set_t *_cpuset = &cpuset->set;
>>> +
>>> +   return (0 == sched_setaffinity(0, /* pid zero means calling
>>> process */
>>> +

Re: [lng-odp] [PATCHv2] linux-generic: timer fix odp_timer_pool_create return code

[Ola Liljedahl]

On 18 May 2016 at 16:24, Maxim Uvarov  wrote:

> Accodring to API return code for fail case is ODP_TIMER_POOL_INVALID
> and errno set event if it's defined to NULL. Also add check on pool
> alloc that input parameter is not invalid.
> https://bugs.linaro.org/show_bug.cgi?id=2139

If  odp_timer_pool is a pointer in linux-generic, then it is OK for the
implementation to return NULL for an invalid timer pool handle. The
implementation should be allowed to use constants (e.g. NULL) for types
which are under its control (e.g. odp_timer_pool) and not have to use
abstract values (ODP_TIMER_POOL_INVALID). This is the implementation, it is
not directly portable and reusable with other definitions of the timer
types.



>
> Signed-off-by: Maxim Uvarov 
> ---
>  v2: added missed ) on if statement. (looks like forgot to git ---ammend
> it )
>
>  platform/linux-generic/odp_timer.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/platform/linux-generic/odp_timer.c
> b/platform/linux-generic/odp_timer.c
> index a6d3332..8696074 100644
> --- a/platform/linux-generic/odp_timer.c
> +++ b/platform/linux-generic/odp_timer.c
> @@ -227,16 +227,15 @@ static inline odp_timer_t tp_idx_to_handle(struct
> odp_timer_pool_s *tp,
>  static void itimer_init(odp_timer_pool *tp);
>  static void itimer_fini(odp_timer_pool *tp);
>
> -static odp_timer_pool *odp_timer_pool_new(
> -   const char *_name,
> -   const odp_timer_pool_param_t *param)
> +static odp_timer_pool_t odp_timer_pool_new(const char *_name,
> +  const odp_timer_pool_param_t
> *param)
>  {
> uint32_t tp_idx = odp_atomic_fetch_add_u32(&num_timer_pools, 1);
> if (odp_unlikely(tp_idx >= MAX_TIMER_POOLS)) {
> /* Restore the previous value */
> odp_atomic_sub_u32(&num_timer_pools, 1);
> __odp_errno = ENFILE; /* Table overflow */
> -   return NULL;
> +   return ODP_TIMER_POOL_INVALID;
> }
> size_t sz0 = ODP_ALIGN_ROUNDUP(sizeof(odp_timer_pool),
> ODP_CACHE_LINE_SIZE);
> @@ -804,10 +803,9 @@ odp_timer_pool_create(const char *name,
> /* Verify that we have a valid (non-zero) timer resolution */
> if (param->res_ns == 0) {
> __odp_errno = EINVAL;
> -   return NULL;
> +   return ODP_TIMER_POOL_INVALID;
> }
> -   odp_timer_pool_t tp = odp_timer_pool_new(name, param);
> -   return tp;
> +   return odp_timer_pool_new(name, param);
>  }
>
>  void odp_timer_pool_start(void)
> @@ -855,15 +853,17 @@ odp_timer_t odp_timer_alloc(odp_timer_pool_t tpid,
> odp_queue_t queue,
> void *user_ptr)
>  {
> +   odp_timer_t hdl;
> +
> +   if (odp_unlikely(tpid == ODP_TIMER_POOL_INVALID))
> +   ODP_ABORT("Invalid timer pool.\n");
>
Possibly it is helpful to check for invalid timer pool handle and die in a
clean way.
But we will not check a billion other invalid timer pool handles and those
will likely generate undefined behaviour or (if we are lucky) a memory
access violation (sigsegv). So there is not any guarantee that the use of
invalid timer pool handle well be detected in any clean way.


> if (odp_unlikely(queue == ODP_QUEUE_INVALID))
> ODP_ABORT("%s: Invalid queue handle\n", tpid->name);
>
The queue handle we want to verify now when it the context of the
application. Later when a timer expires, we don't want to get errors in the
timer background thread. That would likely be fatal and also difficult to
debug.


> /* We don't care about the validity of user_ptr because we will not
>  * attempt to dereference it */
> -   odp_timer_t hdl = timer_alloc(tpid, queue, user_ptr);
> -   if (odp_likely(hdl != ODP_TIMER_INVALID)) {
> -   /* Success */
> -   return hdl;
> -   }
> +   hdl = timer_alloc(tpid, queue, user_ptr);
> +   if (odp_likely(hdl != ODP_TIMER_INVALID))
> +   return hdl; /* Success */
>
As Bill wrote, this code can be simplified even more. Just call
timer_alloc() and return its value directly.


> /* errno set by timer_alloc() */
> return ODP_TIMER_INVALID;
>  }
> --
> 2.7.1.250.gff4ea60
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 2/2] doc: userguide: add notes on threads and addressing scope

[Christophe Milard]

Am I understanding correctly if I try to rephrase your suggestion, Petri,
as follows:

1) " For simplicity all memory should be reserved from the system at global
init time.":
When calling init_global(), the application provides the total amount of
memory it will ever need, including everything (Buffer pools, packet pools,
queues...). I guess this means  that this amount is either found by try and
error when the application is written, or by having some knowledge of the
internal ODP implemenation (how much memory different ODP objects actually
consume). This provided total amount is also very much ODP implementation
dependent as differents implementations may implement some of the ODP
objects in HW.

2) The total amount is allocated at global_init() time, hence before any
fork(), and any ODP memory allocation that follows (for pools, queues or
whatever) is drawn from this initially allocated memory, hence actually
 guaranteeing sharable pointers over the complete ODP instance

3)" Only restriction would be on if pointers to data can be shared.": The
fact that pointers are sharable through the complete ODP instance is hidden
from the API which still claims that OS rules apply

Is this understanding correct?

Christophe.

On 23 May 2016 at 09:37, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
> > >>
> > >>  === Addressing Scope
> > >> -Unless specifically noted in the API, all ODP resources are global to
> > >> the ODP
> > >> -application, whether it runs as a single process or multiple
> > processes.
> > >> ODP
> > >> -handles therefore have common meaning within an ODP application but
> > have
> > >> no
> > >> -meaning outside the scope of the application.
> > >> +ODP objects and their associated handles are intended to be global to
> > an
> > >> ODP
> > >> +instance, _i.e.,_ to the thread that calls `odp_init_global()` and
> its
> > >> +descendants.
> > >
> > >
> > > This is saying that all ODP threads of a given ODP instance are
> > descendant
> > > of the ODP instantiation process. I already tried to define ODP threads
> > > this way, but it was rejected, and the ODP instance number was added to
> > the
> > > API so that any thread/process could join any ODP instance.
> > >
> >
> > We should revisit that because without this assumption I don't think we
> > can
> > define a consistent set of semantics for ODP object visibility.  For
> > example, if I create an ODP instance and then pass the instance ID
> > privately to a completely separate program, do we expect it to be able to
> > use that instance ID to join the (remote) ODP instance by calling
> > odp_init_local()?  Clearly not.
> >
>
> Yes, if the implementation supports that. E.g. there's no processes or
> pthreads in when an SDK runs in bare metal mode. Each cpu starts from C lib
> / SDK startup code and stops at some point to wait others. There's some
> shared memory set up at init phase. You could start up e.g. two separate
> ODP instances of ODP, so that half of the cpus joins the first instance and
> the other half joins the other instance.
>
> odp-linux would not support (at least at first) non-related processes to
> form an instance. But API would not limit, if support for it would be added
> later.
>
>
> >
> > > I still get the feeling that, despite this add-on, we are still saying
> > > that a odpthread belongs to the ODP instance it is a descendand of,
> > rather
> > > than the one specified in the "instance" parameter passed at
> > > odp_local_init() time...
> > > The only possible usage of the odp_instance parameter passed at
> > > odp_local_init() time would then be on OSes which do not support
> process
> > > hierarchy... Is any such OS known to suport ODP?
> > >
> >
> > I concur. I think it's there more for potential future flexibility than
> > anything else since it's effectively a dummy parameter with a single
> > hard-coded value in odp-linux. I see no harm in it being there, but it's
> > presence doesn't change the fact that ODP instances only cover the
> > odp_global_init() caller and its descendants.
>
>
> This is the point. Instance ID enables various thread setups (for linux,
> RTOS, bare metal, ...), odp-linux implements some of those.
>
>
> >
> >
> > > If not, I thing the odp_instance number should either be suppressed, or
> > > clearly stated as meaningless on OS which have process hierarchy, as
> the
> > > process hierarchy seems to take precedence over this parameter in all
> > our
> > > discussions.
>
>
> An implementation may use the instance ID any way it likes. It may carry a
> file name, file descriptor, index to shared memory, magic number, ... etc
> information to find the instance or just error check that global_init was
> indeed called before local_init was called. No need to state it meaningless
> for any implementation.
>
>
> > >
> > > Confused: are talking monarch or some later version? BTW is monarch the
> > > name of the API version only or does the "monarch" name also include

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Christophe Milard]

Hi,

I guess (not 100% sure if that civer all cases) if gettid() == getpid() you
are on the main process thread.
Having said that I do not like this solution very much: It really looks to
me that we have a larger problem trying to keep these things out of ODP

Something for ARCH call, maybe?

Christophe.

On 23 May 2016 at 10:16, Yi He  wrote:

> Hi, Christophe
>
> Here I met a difficulty, if I unified the API into 
> odph_odpthread_set_affinity(),
> inside the function how can I determine whether the current context is a
> pthread or process? So I cannot decide to call sched_setaffinity() or
> pthread_setaffinity_np().
>
> thanks and best regards, Yi
>
>
>
> On 23 May 2016 at 14:53, Yi He  wrote:
>
>> Hi, Christophe
>>
>> Yes, I'll apply your series and send a new one later.
>>
>> Best Regards, Yi
>>
>> On 23 May 2016 at 14:33, Christophe Milard 
>> wrote:
>>
>>>
>>>
>>> On 20 May 2016 at 10:48, Yi He  wrote:
>>>
 Set affinity to 1st available control cpu for all odp
 validation programs in odp_cunit_common library.

 Signed-off-by: Yi He 
 ---
  helper/include/odp/helper/linux.h | 47 +++
  helper/linux.c| 32 +
  helper/test/thread.c  | 76
 +--
  test/validation/common/odp_cunit_common.c | 15 --
  4 files changed, 164 insertions(+), 6 deletions(-)

 diff --git a/helper/include/odp/helper/linux.h
 b/helper/include/odp/helper/linux.h
 index e2dca35..fa815e1 100644
 --- a/helper/include/odp/helper/linux.h
 +++ b/helper/include/odp/helper/linux.h
 @@ -84,6 +84,29 @@ int odph_linux_pthread_create(odph_linux_pthread_t
 *pthread_tbl,
   */
  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int
 num);

 +/**
 + * Set CPU affinity of the current thread
 + *
 + * CPU affinity determines the set of CPUs on which the thread is
 + * eligible to run.
 + *
 + * @param cpusetA bitmask lists the affinity CPU cores
 + *
 + * @return 0 on success, -1 on failure
 + */
 +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);

>>>
>>> odph_odpthread_set_affinity(), is I guess better, at least as long as we
>>> try to keep thread and processes together. Dropping the linux prefix makes
>>> also the code more portable (on some other OS, change provide new helpers
>>> and the app does hopefully not need to change)
>>>
>>> I guess you can apply the "running things in  process mode" patch series
>>> to see what I am after...
>>>
>>> This comment applies to all your function names, of course.
>>>
>>> Christophe
>>>
>>> +
 +/**
 + * Get CPU affinity of the current thread
 + *
 + * CPU affinity determines the set of CPUs on which the thread is
 + * eligible to run.
 + *
 + * @param cpuset[out]   A bitmask lists the affinity CPU cores
 + *
 + * @return 0 on success, -1 on failure
 + */
 +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset);

  /**
   * Fork a process
 @@ -134,6 +157,30 @@ int odph_linux_process_fork_n(odph_linux_process_t
 *proc_tbl,
  int odph_linux_process_wait_n(odph_linux_process_t *proc_tbl, int num);

  /**
 + * Set CPU affinity of the current process
 + *
 + * CPU affinity determines the set of CPUs on which the process is
 + * eligible to run.
 + *
 + * @param cpusetA bitmask lists the affinity CPU cores
 + *
 + * @return 0 on success, -1 on failure
 + */
 +int odph_linux_process_setaffinity(const odp_cpumask_t *cpuset);
 +
 +/**
 + * Get CPU affinity of the current process
 + *
 + * CPU affinity determines the set of CPUs on which the process is
 + * eligible to run.
 + *
 + * @param cpuset[out]   A bitmask lists the affinity CPU cores
 + *
 + * @return 0 on success, -1 on failure
 + */
 +int odph_linux_process_getaffinity(odp_cpumask_t *cpuset);
 +
 +/**
   * @}
   */

 diff --git a/helper/linux.c b/helper/linux.c
 index 24e243b..6ce7e7d 100644
 --- a/helper/linux.c
 +++ b/helper/linux.c
 @@ -114,6 +114,22 @@ void odph_linux_pthread_join(odph_linux_pthread_t
 *thread_tbl, int num)
 }
  }

 +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset)
 +{
 +   const cpu_set_t *_cpuset = &cpuset->set;
 +
 +   return (0 == pthread_setaffinity_np(pthread_self(),
 +   sizeof(cpu_set_t), _cpuset)) ? 0 : -1;
 +}
 +
 +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset)
 +{
 +   cpu_set_t *_cpuset = &cpuset->set;
 +
 +   return (0 == pthread_getaffinity_np(pthread_self(),
 +   sizeof(cpu_set_t), _cpuset)) ? 0 : -1;
 +}
 +
  int odph_linux_process_fork_n(odph_linux_process_t *proc_tbl,

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Yi He]

Thanks very much Christophe

This is great, I'll use this tech in
odph_odpthread_setaffinity()/getaffinity() APIs.

Do you mean you think keeping underlying Linux pthread/process concepts out
of ODP thread concept is not good?

From many discussions I got a Feeling that by ODP thread we are really
trying to provide a higher level execution abstraction above linux
pthread/process units, underlying linux pthread/process are like containers
or boxes for our componentized/re-usable code pieces?

I'm not sure if this feeling is right :), we can talk in ARCH if got time.

Best Regards, Yi

On 23 May 2016 at 16:48, Christophe Milard 
wrote:

> Hi,
>
> I guess (not 100% sure if that civer all cases) if gettid() == getpid()
> you are on the main process thread.
> Having said that I do not like this solution very much: It really looks to
> me that we have a larger problem trying to keep these things out of ODP
>
> Something for ARCH call, maybe?
>
> Christophe.
>
> On 23 May 2016 at 10:16, Yi He  wrote:
>
>> Hi, Christophe
>>
>> Here I met a difficulty, if I unified the API into 
>> odph_odpthread_set_affinity(),
>> inside the function how can I determine whether the current context is a
>> pthread or process? So I cannot decide to call sched_setaffinity() or
>> pthread_setaffinity_np().
>>
>> thanks and best regards, Yi
>>
>>
>>
>> On 23 May 2016 at 14:53, Yi He  wrote:
>>
>>> Hi, Christophe
>>>
>>> Yes, I'll apply your series and send a new one later.
>>>
>>> Best Regards, Yi
>>>
>>> On 23 May 2016 at 14:33, Christophe Milard >> > wrote:
>>>


 On 20 May 2016 at 10:48, Yi He  wrote:

> Set affinity to 1st available control cpu for all odp
> validation programs in odp_cunit_common library.
>
> Signed-off-by: Yi He 
> ---
>  helper/include/odp/helper/linux.h | 47 +++
>  helper/linux.c| 32 +
>  helper/test/thread.c  | 76
> +--
>  test/validation/common/odp_cunit_common.c | 15 --
>  4 files changed, 164 insertions(+), 6 deletions(-)
>
> diff --git a/helper/include/odp/helper/linux.h
> b/helper/include/odp/helper/linux.h
> index e2dca35..fa815e1 100644
> --- a/helper/include/odp/helper/linux.h
> +++ b/helper/include/odp/helper/linux.h
> @@ -84,6 +84,29 @@ int odph_linux_pthread_create(odph_linux_pthread_t
> *pthread_tbl,
>   */
>  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int
> num);
>
> +/**
> + * Set CPU affinity of the current thread
> + *
> + * CPU affinity determines the set of CPUs on which the thread is
> + * eligible to run.
> + *
> + * @param cpusetA bitmask lists the affinity CPU cores
> + *
> + * @return 0 on success, -1 on failure
> + */
> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);
>

 odph_odpthread_set_affinity(), is I guess better, at least as long as
 we try to keep thread and processes together. Dropping the linux prefix
 makes also the code more portable (on some other OS, change provide new
 helpers and the app does hopefully not need to change)

 I guess you can apply the "running things in  process mode" patch
 series to see what I am after...

 This comment applies to all your function names, of course.

 Christophe

 +
> +/**
> + * Get CPU affinity of the current thread
> + *
> + * CPU affinity determines the set of CPUs on which the thread is
> + * eligible to run.
> + *
> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
> + *
> + * @return 0 on success, -1 on failure
> + */
> +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset);
>
>  /**
>   * Fork a process
> @@ -134,6 +157,30 @@ int
> odph_linux_process_fork_n(odph_linux_process_t *proc_tbl,
>  int odph_linux_process_wait_n(odph_linux_process_t *proc_tbl, int
> num);
>
>  /**
> + * Set CPU affinity of the current process
> + *
> + * CPU affinity determines the set of CPUs on which the process is
> + * eligible to run.
> + *
> + * @param cpusetA bitmask lists the affinity CPU cores
> + *
> + * @return 0 on success, -1 on failure
> + */
> +int odph_linux_process_setaffinity(const odp_cpumask_t *cpuset);
> +
> +/**
> + * Get CPU affinity of the current process
> + *
> + * CPU affinity determines the set of CPUs on which the process is
> + * eligible to run.
> + *
> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
> + *
> + * @return 0 on success, -1 on failure
> + */
> +int odph_linux_process_getaffinity(odp_cpumask_t *cpuset);
> +
> +/**
>   * @}
>   */
>
> diff --git a/helper/linux.c b/helper/linux.c
> index 24e243b..6ce7e7d 100644
>>>

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Christophe Milard]

On 23 May 2016 at 11:13, Yi He  wrote:

> Thanks very much Christophe
>
> This is great, I'll use this tech in
> odph_odpthread_setaffinity()/getaffinity() APIs.
>

> Do you mean you think keeping underlying Linux pthread/process concepts
> out of ODP thread concept is not good?
>

Not sure. We are hiting this kind of problems a bit everywhere and that
worries me. But it seems quite accepted that these are not and should not
be part of ODP: Hopefully, we can keep going with this approach.


> From many discussions I got a Feeling that by ODP thread we are really
> trying to provide a higher level execution abstraction above linux
> pthread/process units, underlying linux pthread/process are like containers
> or boxes for our componentized/re-usable code pieces?
>

Yes. I am trying to get a clear view on this, which I have hard to achieve.
The behaviour of the differents ODP objects /  pointers when accessed from
different virtual address space (i.e. process) is not 100% clear to me.

Christophe.


> I'm not sure if this feeling is right :), we can talk in ARCH if got time.
>
> Best Regards, Yi
>
> On 23 May 2016 at 16:48, Christophe Milard 
> wrote:
>
>> Hi,
>>
>> I guess (not 100% sure if that civer all cases) if gettid() == getpid()
>> you are on the main process thread.
>> Having said that I do not like this solution very much: It really looks
>> to me that we have a larger problem trying to keep these things out of ODP
>>
>> Something for ARCH call, maybe?
>>
>> Christophe.
>>
>> On 23 May 2016 at 10:16, Yi He  wrote:
>>
>>> Hi, Christophe
>>>
>>> Here I met a difficulty, if I unified the API into 
>>> odph_odpthread_set_affinity(),
>>> inside the function how can I determine whether the current context is a
>>> pthread or process? So I cannot decide to call sched_setaffinity() or
>>> pthread_setaffinity_np().
>>>
>>> thanks and best regards, Yi
>>>
>>>
>>>
>>> On 23 May 2016 at 14:53, Yi He  wrote:
>>>
 Hi, Christophe

 Yes, I'll apply your series and send a new one later.

 Best Regards, Yi

 On 23 May 2016 at 14:33, Christophe Milard <
 christophe.mil...@linaro.org> wrote:

>
>
> On 20 May 2016 at 10:48, Yi He  wrote:
>
>> Set affinity to 1st available control cpu for all odp
>> validation programs in odp_cunit_common library.
>>
>> Signed-off-by: Yi He 
>> ---
>>  helper/include/odp/helper/linux.h | 47 +++
>>  helper/linux.c| 32 +
>>  helper/test/thread.c  | 76
>> +--
>>  test/validation/common/odp_cunit_common.c | 15 --
>>  4 files changed, 164 insertions(+), 6 deletions(-)
>>
>> diff --git a/helper/include/odp/helper/linux.h
>> b/helper/include/odp/helper/linux.h
>> index e2dca35..fa815e1 100644
>> --- a/helper/include/odp/helper/linux.h
>> +++ b/helper/include/odp/helper/linux.h
>> @@ -84,6 +84,29 @@ int odph_linux_pthread_create(odph_linux_pthread_t
>> *pthread_tbl,
>>   */
>>  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int
>> num);
>>
>> +/**
>> + * Set CPU affinity of the current thread
>> + *
>> + * CPU affinity determines the set of CPUs on which the thread is
>> + * eligible to run.
>> + *
>> + * @param cpusetA bitmask lists the affinity CPU cores
>> + *
>> + * @return 0 on success, -1 on failure
>> + */
>> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);
>>
>
> odph_odpthread_set_affinity(), is I guess better, at least as long as
> we try to keep thread and processes together. Dropping the linux prefix
> makes also the code more portable (on some other OS, change provide new
> helpers and the app does hopefully not need to change)
>
> I guess you can apply the "running things in  process mode" patch
> series to see what I am after...
>
> This comment applies to all your function names, of course.
>
> Christophe
>
> +
>> +/**
>> + * Get CPU affinity of the current thread
>> + *
>> + * CPU affinity determines the set of CPUs on which the thread is
>> + * eligible to run.
>> + *
>> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
>> + *
>> + * @return 0 on success, -1 on failure
>> + */
>> +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset);
>>
>>  /**
>>   * Fork a process
>> @@ -134,6 +157,30 @@ int
>> odph_linux_process_fork_n(odph_linux_process_t *proc_tbl,
>>  int odph_linux_process_wait_n(odph_linux_process_t *proc_tbl, int
>> num);
>>
>>  /**
>> + * Set CPU affinity of the current process
>> + *
>> + * CPU affinity determines the set of CPUs on which the process is
>> + * eligible to run.
>> + *
>> + * @param cpusetA bitmask lists the affinity CPU core

Re: [lng-odp] [PATCHv9 00/35] running things in process mode

[Maxim Uvarov]

Merged,
Maxim.

On 05/21/16 09:16, Christophe Milard wrote:

Yes! I get that easily on my home computer:
while (true); do ./platform/linux-generic/test/ring/ringtest ; done 
just hangs after a short while.

even on origin/master
For some reason that refuses to hang at work...

I don't think it should stop the series, but it is definitively 
something to fix!


Thanks Maxim!

On 20 May 2016 at 21:04, Maxim Uvarov > wrote:


ok, now odp-check passed 34 patches on on 35 I caught ring test bug :)

platform/linux-generic/test/ring/ringtest.c

It rolls forever in that loop:

 do {
i = _ring_mc_dequeue_bulk(r_stress, src, MAX_BULK);
if (i == 0) {
for (i = 0; i < MAX_BULK; i++) {
if (src[i] != (void *)(unsigned long)i) {
free(src);
printf("data mismatch.. lockless ops fail\n");
return -1;
}
}
free(src);
printf("\n Test OK !\n");
return 0;
}
} while (1);


which does not return due to _ring_mc_dequeue_bulk() always return
-ENOENT:

#0  ___ring_mc_do_dequeue (r=0x2b65fec0,
obj_table=obj_table@entry=0x2b66080008c0, n=n@entry=32,
behavior=behavior@entry=_RING_QUEUE_FIXED) at pktio/ring.c:363
363uint32_t mask = r->prod.mask;
(gdb) l
358uint32_t cons_head, prod_tail;
359uint32_t cons_next, entries;
360const unsigned max = n;
361int success;
362unsigned i;
363uint32_t mask = r->prod.mask;
364
365/* move cons.head atomically */
366do {
367/* Restore n as it may change every loop */
(gdb) p mask
$4 = 
(gdb) n
370cons_head = r->cons.head;
(gdb)
376entries = (prod_tail - cons_head);
(gdb)
370cons_head = r->cons.head;
(gdb) p entries
$5 = 
(gdb) n
379if (n > entries) {
(gdb)
380if (behavior == _RING_QUEUE_FIXED)
(gdb) p n
$6 = 32
(gdb) n
381return -ENOENT;
(gdb)


That should not be related to current patch series, but we need to
fix it.

Maxim.


On 05/20/16 19:30, Christophe Milard wrote:

Since v8
-Fixed error in patch 9 generation erroneous file (Maxim)

Since v7
-fixed rebase error between patch 7 and 8 (sorry Maxim)

Since v6
-rebased
-regrouping history, squashing patch 1 and 12; 4, 5 and 12 (Petri)
-mixed mode test removed (but still claimed to be supported in
ODP). (Petri)

Since v5
-rebased
-patch removing old unused helper code dropped. (Petri)
-Doc update to discourage usage of the old functions. (Petri,
Mike)

Since v4:
-updates following Brian's comments

Since v3:
-fixed rebase error (Christophe)
-rebased

Since v2:
-serious rebase following clash with dba05a28 (api: init: add
instance handle)
-squashing the validation changes.

Since v1:
-variable declaration gathered in function 's head (Petri)
-linux prefix removed from helper's types and function names
(Mike, Christophe)

Hi,

This patch series adds the ability to run tests/ exemples /
perf-test
in "process mode" (i.e letting OPD threads being linux processes)
It it hence tackling ODP-171.

This is achieved in 2 main steps:

A]
The 2 pairs of helper functions:
odph_linux_pthread_create(), odph_linux_pthread_join()
and
odph_linux_process_fork_n(), odph_linux_process_wait_n()
are complemented by:
odph_linux_odpthreads_create() and odph_linux_odpthreads_join()
The latter's callers are unaware of the actual implementation
of the ODP
thread (making test truly platform agnostic).
The helper functions decide at run time whether an odp thread
is to be
a linux process or pthread based on the command line argument.

B] each test/example now calls a new helper function,
odph_linux_parse_options(), so that the helper can get its own
arguments
out of the command line.
Currentely supported args is: --odph_proc.
Defaults assumes thread.

The changed are first done on the shmem tests, and thereafter
propagated
to other helper users.
Note that this patch series enable the option but does not affect
make check at this time: make check still calls the tests with
no options
which default to thread mode.



Christophe M

Re: [lng-odp] [PATCH v3] doc: process-guide: convert CONTRIBUTING to asciidoc

[Maxim Uvarov]

merged,
Maxim.

On 05/19/16 20:04, Mike Holmes wrote:

Ping to merge

On 16 May 2016 at 17:15, Bill Fischofer  wrote:



On Mon, May 16, 2016 at 11:29 AM, Mike Holmes 
wrote:


Converting to asciidoc allows a tidy page to be added to the online
documentation without cutting and pasting into wordpress.
Being Asccidoc a tiny amount of clutter is added to show code snippets
attractively when rendered that make it slightly hard to read as a raw
document.

Signed-off-by: Mike Holmes 


Reviewed-and-tested-by: Bill Fischofer 



---
  CONTRIBUTING  | 110
--
  doc/process-guide/.gitignore  |   1 +
  doc/process-guide/Makefile.am |  11 -
  3 files changed, 74 insertions(+), 48 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index f2f8947..a81fd8d 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,28 +1,32 @@
-Contributing to the OpenDataplane (ODP) API

-
-Table of content:
--
-1. New Development
-2. ODP patch expectations as an  open source project
-3. Common Errors in Patch and Commit Messages
-4. Documenting the code
-5. Documenting the user docs
-6. References
-
-1. New Development
---
-ODP code shall be written with the kernel coding style [1].
+:doctitle: OpenDataPlane (ODP) CONTRIBUTING
+:description: This document is intended to guide a new application
developer +
+in understanding the  contributing requirements for ODP
+:imagesdir: ../images
+:toc:
+:numbered!:
+[abstract]
+
+== Abstract
+
+This document is intended to guide a new application developer in
understanding
+the  contributing requirements for ODP
+
+== New Development
+
+ODP code shall be written with the kernel coding style
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle[Kernel
Coding Style]
+
  ODP code shall be documented using the doxygen style described in the
  "Documenting the code" section.
  Check patch script/checkpatch.pl shall be used before submitting a
patch.

-2. ODP patch expectations as an  open source project
-
+== ODP patch expectations as an  open source project
+
  While specific to the Linux kernel development, the following reference
could
-also be considered a general guide for any Open Source development [2]
and is
-relevant to ODP. Many of the guidelines in this ODP document are related
to the
-items in that information.
+also be considered a general guide for any Open Source development
+
http://ldn.linuxfoundation.org/book/how-participate-linux-community[Participating
in the Community]
+and is relevant to ODP. Many of the guidelines in this ODP document are
related
+to the items in that information.
+
  Pay particular attention to section 5.3 that talks about patch
preparation.
  The key thing to remember is to break up your changes into logical
sections.
  Otherwise you run the risk of not being able to even explain the purpose
of a
@@ -34,11 +38,12 @@ Signed-off-by: tag line a copy of the description
follows:
  Signed-off-by: this is a developer's certification that he or she has
  the right to submit the patch for inclusion into the [project].  It is
  an agreement to the Developer's Certificate of Origin, the full text of
-which can be found in [3] Documentation/SubmittingPatches.
+which can be found in
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches[Submitting
Patches]
+
  Code without a proper signoff cannot be merged into the mainline.

-3. Common Errors in Patch and Commit Messages
--
+== Common Errors in Patch and Commit Messages
+
  - Avoid starting the summary line with a capital letter, unless the
component
being referred to also begins with a capital letter.
  - Don't have one huge patch, split your change into logical subparts.
It's
@@ -83,8 +88,12 @@ Code without a proper signoff cannot be merged into
the mainline.
sources.
  - Avoid punctuation in the short log.

-4. Documenting the code

+== Documenting
+
+- References to wikipedia are not permitted.
+
+=== Documenting the code
+
  - Allow doxygen to use all its default behaviors to identify tagged
information but where a doxygen tag must be specified use @
  - The first line is by default the brief summary.
@@ -93,49 +102,58 @@ Code without a proper signoff cannot be merged into
the mainline.
  - Normal comment sections should be before the code block and start with
/** on its own line and finish with */ on its own line. The exception
to this rule is a case where the comment is very small, for example
-  /** macro description */
-  #define SOME_MACRO 0
+[source,doxygen]
+
+/** macro description */
+#define SOME_MACRO 0
+
  - Commenting on the end of a line for macros and struct members is
allowed
-  using:
-  /**<  */ for example
-  #define SOME_MACRO 0 /*

Re: [lng-odp] [PATCH 1/2] linux-generic: pktio: add pktio type specific print function

[Maxim Uvarov]

Merged,
Maxim.

On 05/20/16 03:03, Bill Fischofer wrote:

For this series:

Reviewed-by: Bill Fischofer 

On Thu, May 19, 2016 at 3:48 AM, Matias Elo  wrote:


Add new function pointer 'print' to pktio_if_ops_t. This can
be used to print pktio type specific debug information.

In case of netmap, it is used to print the current RSS
configuration. rss_conf_print() output format was modified
to be in line with odp_pktio_print().

Signed-off-by: Matias Elo 
---
  platform/linux-generic/include/odp_packet_io_internal.h |  1 +
  platform/linux-generic/odp_packet_io.c  |  7 ++-
  platform/linux-generic/pktio/ipc.c  |  1 +
  platform/linux-generic/pktio/loop.c |  1 +
  platform/linux-generic/pktio/netmap.c   | 10 ++
  platform/linux-generic/pktio/pcap.c |  1 +
  platform/linux-generic/pktio/socket.c   | 17
+
  platform/linux-generic/pktio/socket_mmap.c  |  1 +
  platform/linux-generic/pktio/tap.c  |  1 +
  9 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h
b/platform/linux-generic/include/odp_packet_io_internal.h
index 7dd578b..5adfc7e 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -175,6 +175,7 @@ int is_free(pktio_entry_t *entry);

  typedef struct pktio_if_ops {
 const char *name;
+   void (*print)(pktio_entry_t *pktio_entry);
 int (*init_global)(void);
 int (*init_local)(void);
 int (*term)(void);
diff --git a/platform/linux-generic/odp_packet_io.c
b/platform/linux-generic/odp_packet_io.c
index db5a3df..15763df 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -1028,7 +1028,12 @@ void odp_pktio_print(odp_pktio_t id)
 odp_pktio_promisc_mode(id) ? "yes" : "no");
 str[len] = '\0';

-   ODP_PRINT("\n%s\n", str);
+   ODP_PRINT("\n%s", str);
+
+   if (entry->s.ops->print)
+   entry->s.ops->print(entry);
+
+   ODP_PRINT("\n");
  }

  int odp_pktio_term_global(void)
diff --git a/platform/linux-generic/pktio/ipc.c
b/platform/linux-generic/pktio/ipc.c
index 12cc286..d499a19 100644
--- a/platform/linux-generic/pktio/ipc.c
+++ b/platform/linux-generic/pktio/ipc.c
@@ -726,6 +726,7 @@ static int ipc_close(pktio_entry_t *pktio_entry)

  const pktio_if_ops_t ipc_pktio_ops = {
 .name = "ipc",
+   .print = NULL,
 .init_global = NULL,
 .init_local = NULL,
 .term = NULL,
diff --git a/platform/linux-generic/pktio/loop.c
b/platform/linux-generic/pktio/loop.c
index 38acff1..cbb5ea9 100644
--- a/platform/linux-generic/pktio/loop.c
+++ b/platform/linux-generic/pktio/loop.c
@@ -206,6 +206,7 @@ static int loopback_stats_reset(pktio_entry_t
*pktio_entry ODP_UNUSED)

  const pktio_if_ops_t loopback_pktio_ops = {
 .name = "loop",
+   .print = NULL,
 .init_global = NULL,
 .init_local = NULL,
 .term = NULL,
diff --git a/platform/linux-generic/pktio/netmap.c
b/platform/linux-generic/pktio/netmap.c
index 3e6a4f0..1042fd1 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -879,8 +879,18 @@ static int netmap_stats_reset(pktio_entry_t
*pktio_entry)
pktio_entry->s.pkt_nm.sockfd);
  }

+static void netmap_print(pktio_entry_t *pktio_entry)
+{
+   odp_pktin_hash_proto_t hash_proto;
+
+   if (rss_conf_get_fd(pktio_entry->s.pkt_nm.sockfd,
+   pktio_entry->s.pkt_nm.if_name, &hash_proto))
+   rss_conf_print(&hash_proto);
+}
+
  const pktio_if_ops_t netmap_pktio_ops = {
 .name = "netmap",
+   .print = netmap_print,
 .init_global = NULL,
 .init_local = NULL,
 .term = NULL,
diff --git a/platform/linux-generic/pktio/pcap.c
b/platform/linux-generic/pktio/pcap.c
index aab6b42..aeb20ed 100644
--- a/platform/linux-generic/pktio/pcap.c
+++ b/platform/linux-generic/pktio/pcap.c
@@ -421,6 +421,7 @@ static int pcapif_stats(pktio_entry_t *pktio_entry,

  const pktio_if_ops_t pcap_pktio_ops = {
 .name = "pcap",
+   .print = NULL,
 .init_global = NULL,
 .init_local = NULL,
 .open = pcapif_init,
diff --git a/platform/linux-generic/pktio/socket.c
b/platform/linux-generic/pktio/socket.c
index a0aa9af..c0de59f 100644
--- a/platform/linux-generic/pktio/socket.c
+++ b/platform/linux-generic/pktio/socket.c
@@ -419,29 +419,29 @@ void rss_conf_print(const odp_pktin_hash_proto_t
*hash_proto)
 int len = 0;
 int n = max_len - 1;

-   len += snprintf(&str[len], n - len, "RSS conf\n");
+   len += snprintf(&str[len], n - len, " rss conf\n");

 if (hash_proto->proto.ipv4)
 len += snprintf(&str[len], n - len,
-

[lng-odp] opendataplane.org "Downloads" page changes

[Zoltan Kiss]

Hi,

The odp-dpdk part of http://www.opendataplane.org/downloads/ needs updating:
- The patchworks links should be deleted, as nobody uses it, given that 
I'm the only maintainer and the only regular commiter.
- The "latest stable release link" is also very old, and doesn't fit for 
odp-dpdk: I only tag the LAST commit which supports a particular ODP 
API/DPDK version pair. I would definitely not call that "stable". This 
mode of operation has problems, but since nobody is interested to figure 
out a better way [1], I kept it. So I want to remove this link as well
- somewhere around the top left corner box, where the odp-linux and 
odp-dpdk links are, we should add the following text for clarification:


"odp-linux can interface with DPDK poll mode drivers, but it retains 
everything else as generic, including the buffer management 
implementation. Therefore it has to copy everything during receive and 
transmit between its own buffers and DPDK ones.
odp-dpdk is derived from odp-linux, but it is entirely DPDK focused, and 
tries to connect as much DPDK API's to ODP as possible. It uses DPDK 
buffer management underneath, so it doesn't need the aforementioned copy"



[1] https://lists.linaro.org/pipermail/lng-odp-dpdk/2015-October/001158.html


Zoli
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH v3] linux-generic: test: ring: convert to cunit and improve coverage

[Maxim Uvarov]

Hello Yi,

some more clean up is needed here.

perl ./scripts/checkpatch.pl 
0001-linux-generic-test-ring-convert-to-cunit-and-improve.patch

CHECK: Alignment should match open parenthesis
#164: FILE: platform/linux-generic/test/ring/ring_basic.c:84:
+st_ring = _ring_create(st_ring_name, RING_SIZE,
+_RING_F_SP_ENQ | _RING_F_SC_DEQ);

CHECK: Alignment should match open parenthesis
#171: FILE: platform/linux-generic/test/ring/ring_basic.c:91:
+mt_ring = _ring_create(mt_ring_name, RING_SIZE,
+0 /* not used, alignement


and few comments bellow:

On 05/23/16 10:35, Yi He wrote:

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

Convert ring test program into cunit framework
Improve LCOV coverage for linux-generic/pktio/ring.c

Signed-off-by: Yi He 
---
  platform/linux-generic/test/Makefile.am|   2 +-
  platform/linux-generic/test/ring/Makefile.am   |  20 +-
  platform/linux-generic/test/ring/ring_basic.c  | 359 ++
  platform/linux-generic/test/ring/ring_main.c   |  12 +
  platform/linux-generic/test/ring/ring_stress.c | 237 
  platform/linux-generic/test/ring/ring_suites.c |  74 
  platform/linux-generic/test/ring/ring_suites.h |  33 ++
  platform/linux-generic/test/ring/ringtest.c| 495 -
  8 files changed, 725 insertions(+), 507 deletions(-)
  create mode 100644 platform/linux-generic/test/ring/ring_basic.c
  create mode 100644 platform/linux-generic/test/ring/ring_main.c
  create mode 100644 platform/linux-generic/test/ring/ring_stress.c
  create mode 100644 platform/linux-generic/test/ring/ring_suites.c
  create mode 100644 platform/linux-generic/test/ring/ring_suites.h
  delete mode 100644 platform/linux-generic/test/ring/ringtest.c

diff --git a/platform/linux-generic/test/Makefile.am 
b/platform/linux-generic/test/Makefile.am
index f74185d..2d58c57 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -8,7 +8,7 @@ ODP_MODULES = pktio \
  if test_vald
  TESTS = pktio/pktio_run.sh \
pktio/pktio_run_tap.sh \
-   ring/ringtest$(EXEEXT) \
+   ring/ring_main$(EXEEXT) \
shmem/shmem_linux \
${top_builddir}/test/validation/atomic/atomic_main$(EXEEXT) \
${top_builddir}/test/validation/barrier/barrier_main$(EXEEXT) \
diff --git a/platform/linux-generic/test/ring/Makefile.am 
b/platform/linux-generic/test/ring/Makefile.am
index 5a949d0..c086584 100644
--- a/platform/linux-generic/test/ring/Makefile.am
+++ b/platform/linux-generic/test/ring/Makefile.am
@@ -1,16 +1,14 @@
-include $(top_srcdir)/test/validation/Makefile.inc
+include ../Makefile.inc
  
-AM_CFLAGS += -I$(srcdir)/common

-AM_CFLAGS += -I$(top_srcdir)/test/validation/common
-AM_LDFLAGS += -static
+noinst_LTLIBRARIES = libtestring.la
+libtestring_la_SOURCES = ring_suites.c ring_basic.c ring_stress.c
+libtestring_la_CFLAGS = $(AM_CFLAGS) $(INCCUNIT_COMMON) $(INCODP)
  
-COMPILE_ONLY =

+test_PROGRAMS = ring_main$(EXEEXT)
+dist_ring_main_SOURCES = ring_main.c
  
-TESTSCRIPTS =

+ring_main_LDFLAGS = $(AM_LDFLAGS)
+ring_main_LDADD = libtestring.la $(LIBCUNIT_COMMON) $(LIBODP)
  
-EXECUTABLES = ringtest$(EXEEXT)

+noinst_HEADERS = ring_suites.h
  
-test_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)

-
-ringtest_SOURCES = ringtest.c
-ringtest_LDADD = $(LIBCUNIT_COMMON) $(LIBODP)
diff --git a/platform/linux-generic/test/ring/ring_basic.c 
b/platform/linux-generic/test/ring/ring_basic.c
new file mode 100644
index 000..8daaa9f
--- /dev/null
+++ b/platform/linux-generic/test/ring/ring_basic.c
@@ -0,0 +1,359 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP ring basic test
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "ring_suites.h"
+
+/* labor functions declaration */
+static void __do_basic_burst(_ring_t *r);
+static void __do_basic_bulk(_ring_t *r);
+static void __do_basic_watermark(_ring_t *r);
+
+/* dummy object pointers for enqueue and dequeue testing */
+static void **test_enq_data;
+static void **test_deq_data;
+
+/* create two rings: one for single thread usage scenario
+ * and another for multiple thread usage scenario.
+ * st - single thread usage scenario
+ * mt - multiple thread usage scenario
+ */
+static const char *st_ring_name = "ST basic ring";
+static const char *mt_ring_name = "MT basic ring";
+static _ring_t *st_ring, *mt_ring;
+
+int ring_test_basic_start(void)
+{
+   int i = 0;
+
+   /* alloc dummy object pointers for enqueue testing */
+   test_enq_data = malloc(RING_SIZE * 2 * sizeof(void *));
+   if (NULL == test_enq_data) {
+   LOG_ERR("failed to allocate basic test enqeue data\n");
+   return -1;
+   }
+
+   for (i = 0; i < RING_SIZE * 2; i++)
+   test_enq_data[i] = (void *)(unsigned long)i;
+
+   /* alloc dummy object pointers for dequeue testing */
+ 

Re: [lng-odp] [PATCH v2 1/2] example: fix pcap location assumption

[Maxim Uvarov]

thanks,

Merged.
Maxim.

On 05/20/16 22:48, Bill Fischofer wrote:

For this series:

Reviewed-and-tested-by: Bill Fischofer 

On Fri, May 20, 2016 at 12:31 PM, Mike Holmes 
wrote:


Signed-off-by: Mike Holmes 
---
v2
   fix broken assumption in existing scripts (Bill)

  example/l2fwd_simple/l2fwd_simple_run.sh | 2 +-
  example/switch/switch_run.sh | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/example/l2fwd_simple/l2fwd_simple_run.sh
b/example/l2fwd_simple/l2fwd_simple_run.sh
index 6050360..292d0e3 100755
--- a/example/l2fwd_simple/l2fwd_simple_run.sh
+++ b/example/l2fwd_simple/l2fwd_simple_run.sh
@@ -21,7 +21,7 @@ if [ "$STATUS" -ne 143 ]; then
exit 1
  fi

-if [ `stat -c %s pcapout.pcap` -ne `stat -c %s udp64.pcap` ]; then
+if [ `stat -c %s pcapout.pcap` -ne `stat -c %s  ${PCAP_IN}` ]; then
echo "File sizes disagree"
exit 1
  fi
diff --git a/example/switch/switch_run.sh b/example/switch/switch_run.sh
index 9b32973..3f8f9db 100755
--- a/example/switch/switch_run.sh
+++ b/example/switch/switch_run.sh
@@ -33,7 +33,7 @@ fi

  for i in `seq 1 $NUM_RX_PORT`;
  do
-   if [ `stat -c %s pcapout${i}.pcap` -ne `stat -c %s udp64.pcap` ];
then
+   if [ `stat -c %s pcapout${i}.pcap` -ne `stat -c %s ${PCAP_IN}` ];
then
 echo "Error: Output file $i size not matching"
 RETVAL=1
 fi
--
2.7.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] helper/test: add missing scripts to EXTRA_DIST

[Anders Roxell]

Signed-off-by: Anders Roxell 
---
 helper/test/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
index 8e65948..e9e8785 100644
--- a/helper/test/Makefile.am
+++ b/helper/test/Makefile.am
@@ -24,6 +24,7 @@ dist_bin_SCRIPTS =
 
 bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
 
+EXTRA_DIST = odpthreads_as_processes odpthreads_as_pthreads
 
 dist_chksum_SOURCES = chksum.c
 dist_odpthreads_SOURCES = odpthreads.c
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] linux-generic: include: drv: std_types.h: fix cyclic include

[Anders Roxell]

Reported-by: Mike Holmes 
Signed-off-by: Anders Roxell 
---
 platform/linux-generic/include/odp/drv/std_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/platform/linux-generic/include/odp/drv/std_types.h 
b/platform/linux-generic/include/odp/drv/std_types.h
index 5b0815b..4fe4aff 100644
--- a/platform/linux-generic/include/odp/drv/std_types.h
+++ b/platform/linux-generic/include/odp/drv/std_types.h
@@ -33,7 +33,7 @@ typedef int odpdrv_bool_t;
  * @}
  */
 
-#include 
+#include 
 
 #ifdef __cplusplus
 }
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

Signed-off-by: Christophe Milard 
---
 helper/include/odp/helper/linux.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/helper/include/odp/helper/linux.h 
b/helper/include/odp/helper/linux.h
index 01c348d..2e89833 100644
--- a/helper/include/odp/helper/linux.h
+++ b/helper/include/odp/helper/linux.h
@@ -73,13 +73,13 @@ typedef struct {
 
 /** The odpthread starting arguments, used both in process or thread mode */
 typedef struct {
-   odph_odpthread_linuxtype_t linuxtype;
-   odph_odpthread_params_t thr_params; /*copy of thread start parameter*/
+   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread */
+   odph_odpthread_params_t thr_params; /**< odpthread start parameters */
 } odph_odpthread_start_args_t;
 
 /** Linux odpthread state information, used both in process or thread mode */
 typedef struct {
-   odph_odpthread_start_args_t start_args;
+   odph_odpthread_start_args_t start_args; /**< start arguments */
int cpu;/**< CPU ID */
int last;   /**< true if last table entry */
union {
-- 
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Ola Liljedahl]

On 23 May 2016 at 10:16, Yi He  wrote:

> Hi, Christophe
>
> Here I met a difficulty, if I unified the API into
> odph_odpthread_set_affinity(),
> inside the function how can I determine whether the current context is a
> pthread or process? So I cannot decide to call sched_setaffinity() or
> pthread_setaffinity_np().
>
Perhaps the ODP implementation uses some other forms of threads. E.g. C11
and C++11 has built in support for threads.
Or you are running bare metal (which some vendors support) and the threads
are actually HW threads (logical CPU's). Possibly such an environment will
emulate some thread API (pthreads being the most common I believe).

It seems that although ODP is not an OS abstraction, it can't avoid
intersecting with some functionality that normally is provided by the OS or
language runtime. But where do you draw the line?


>
> thanks and best regards, Yi
>
>
>
> On 23 May 2016 at 14:53, Yi He  wrote:
>
> > Hi, Christophe
> >
> > Yes, I'll apply your series and send a new one later.
> >
> > Best Regards, Yi
> >
> > On 23 May 2016 at 14:33, Christophe Milard  >
> > wrote:
> >
> >>
> >>
> >> On 20 May 2016 at 10:48, Yi He  wrote:
> >>
> >>> Set affinity to 1st available control cpu for all odp
> >>> validation programs in odp_cunit_common library.
> >>>
> >>> Signed-off-by: Yi He 
> >>> ---
> >>>  helper/include/odp/helper/linux.h | 47 +++
> >>>  helper/linux.c| 32 +
> >>>  helper/test/thread.c  | 76
> >>> +--
> >>>  test/validation/common/odp_cunit_common.c | 15 --
> >>>  4 files changed, 164 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/helper/include/odp/helper/linux.h
> >>> b/helper/include/odp/helper/linux.h
> >>> index e2dca35..fa815e1 100644
> >>> --- a/helper/include/odp/helper/linux.h
> >>> +++ b/helper/include/odp/helper/linux.h
> >>> @@ -84,6 +84,29 @@ int odph_linux_pthread_create(odph_linux_pthread_t
> >>> *pthread_tbl,
> >>>   */
> >>>  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int
> num);
> >>>
> >>> +/**
> >>> + * Set CPU affinity of the current thread
> >>> + *
> >>> + * CPU affinity determines the set of CPUs on which the thread is
> >>> + * eligible to run.
> >>> + *
> >>> + * @param cpusetA bitmask lists the affinity CPU cores
> >>> + *
> >>> + * @return 0 on success, -1 on failure
> >>> + */
> >>> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);
> >>>
> >>
> >> odph_odpthread_set_affinity(), is I guess better, at least as long as we
> >> try to keep thread and processes together. Dropping the linux prefix
> makes
> >> also the code more portable (on some other OS, change provide new
> helpers
> >> and the app does hopefully not need to change)
> >>
> >> I guess you can apply the "running things in  process mode" patch series
> >> to see what I am after...
> >>
> >> This comment applies to all your function names, of course.
> >>
> >> Christophe
> >>
> >> +
> >>> +/**
> >>> + * Get CPU affinity of the current thread
> >>> + *
> >>> + * CPU affinity determines the set of CPUs on which the thread is
> >>> + * eligible to run.
> >>> + *
> >>> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
> >>> + *
> >>> + * @return 0 on success, -1 on failure
> >>> + */
> >>> +int odph_linux_pthread_getaffinity(odp_cpumask_t *cpuset);
> >>>
> >>>  /**
> >>>   * Fork a process
> >>> @@ -134,6 +157,30 @@ int odph_linux_process_fork_n(odph_linux_process_t
> >>> *proc_tbl,
> >>>  int odph_linux_process_wait_n(odph_linux_process_t *proc_tbl, int
> num);
> >>>
> >>>  /**
> >>> + * Set CPU affinity of the current process
> >>> + *
> >>> + * CPU affinity determines the set of CPUs on which the process is
> >>> + * eligible to run.
> >>> + *
> >>> + * @param cpusetA bitmask lists the affinity CPU cores
> >>> + *
> >>> + * @return 0 on success, -1 on failure
> >>> + */
> >>> +int odph_linux_process_setaffinity(const odp_cpumask_t *cpuset);
> >>> +
> >>> +/**
> >>> + * Get CPU affinity of the current process
> >>> + *
> >>> + * CPU affinity determines the set of CPUs on which the process is
> >>> + * eligible to run.
> >>> + *
> >>> + * @param cpuset[out]   A bitmask lists the affinity CPU cores
> >>> + *
> >>> + * @return 0 on success, -1 on failure
> >>> + */
> >>> +int odph_linux_process_getaffinity(odp_cpumask_t *cpuset);
> >>> +
> >>> +/**
> >>>   * @}
> >>>   */
> >>>
> >>> diff --git a/helper/linux.c b/helper/linux.c
> >>> index 24e243b..6ce7e7d 100644
> >>> --- a/helper/linux.c
> >>> +++ b/helper/linux.c
> >>> @@ -114,6 +114,22 @@ void odph_linux_pthread_join(odph_linux_pthread_t
> >>> *thread_tbl, int num)
> >>> }
> >>>  }
> >>>
> >>> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset)
> >>> +{
> >>> +   const cpu_set_t *_cpuset = &cpuset->set;
> >>> +
> >>> +   return (0 == pthread_setaffinity_np(pthread_self(),
> >>> +   sizeof(cpu_set_t), _cpuset)) ? 0 : 

Re: [lng-odp] [PATCH v2 2/2] doc: process: add FAQ document

[Maxim Uvarov]

Merged,
Maxim.

On 05/20/16 14:50, Mike Holmes wrote:

Converts the FAQ to asciidoc from WordPress so that there is a single
copy that is easily updated. This src reuses diagrams from the rest
of the documentation further reducing maintenance. New diagrams are
added from the old FAQ that can add value to existing documentation.

Signed-off-by: Mike Holmes 
---
  doc/process-guide/.gitignore  |   1 +
  doc/process-guide/Makefile.am |  20 +++-
  doc/process-guide/faq.adoc| 273 ++
  3 files changed, 291 insertions(+), 3 deletions(-)
  create mode 100644 doc/process-guide/faq.adoc

diff --git a/doc/process-guide/.gitignore b/doc/process-guide/.gitignore
index 7632500..78bd409 100644
--- a/doc/process-guide/.gitignore
+++ b/doc/process-guide/.gitignore
@@ -1,2 +1,3 @@
  bylaws-guide.html
  release-guide.html
+faq.html
diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am
index 196ed7f..7d5cd6a 100644
--- a/doc/process-guide/Makefile.am
+++ b/doc/process-guide/Makefile.am
@@ -1,14 +1,17 @@
  include ../Makefile.inc
  
  EXTRA_DIST = $(top_srcdir)/doc/process-guide/bylaws-guide.adoc \

-$(top_srcdir)/doc/process-guide/release-guide.adoc
+$(top_srcdir)/doc/process-guide/release-guide.adoc \
+$(top_srcdir)/doc/process-guide/faq.adoc
  
  all-local: bylaws-guide.html \

-  release-guide.html
+  release-guide.html \
+  faq.html
  
  clean-local:

rm -f $(builddir)/bylaws-guide.html
rm -f $(builddir)/release-guide.html
+   rm -f $(builddir)/faq.html
  
  release-guide.html: $(top_srcdir)/doc/process-guide/release-guide.adoc \

$(top_srcdir)/doc/images/simple_release_git.svg \
@@ -16,4 +19,15 @@ release-guide.html: 
$(top_srcdir)/doc/process-guide/release-guide.adoc \
  
  bylaws-guide.html:  $(top_srcdir)/doc/process-guide/bylaws-guide.adoc
  
-doc_DATA = bylaws-guide.html release-guide.html

+faq.html:  $(top_srcdir)/doc/process-guide/faq.adoc \
+  $(top_srcdir)/doc/images/aboutODP1.svg \
+  $(top_srcdir)/doc/images/aboutODP2.svg \
+  $(top_srcdir)/doc/images/aboutODP3.svg \
+  $(top_srcdir)/doc/images/packet_flow.svg \
+  $(top_srcdir)/doc/images/aboutODP5.svg \
+  $(top_srcdir)/doc/images/overview.svg
+
+
+#add deps on images
+
+doc_DATA = bylaws-guide.html release-guide.html faq.html
diff --git a/doc/process-guide/faq.adoc b/doc/process-guide/faq.adoc
new file mode 100644
index 000..8f0c263
--- /dev/null
+++ b/doc/process-guide/faq.adoc
@@ -0,0 +1,273 @@
+:doctitle: OpenDataPlane (ODP) Frequently Asked Questions (FAQ)
+:description: This document is intended to guide a new ODP user in answering +
+common questions
+:imagesdir: ../images
+:toc:
+:numbered!:
+[abstract]
+Abstract
+
+This document is intended to guide a new ODP user in answering
+common questions.
+
+Further details about ODP may be found at the http://opendataplane.org[ODP]
+home page.
+
+:numbered:
+
+== What is ODP?
+OpenDataPlane (ODP) is an open source API defined for networking data plane
+applications programming. The primary goal of ODP is to provide a common set of
+APIs for application portability across a diverse range of networking platforms
+(SoCs and servers) that offer various types of hardware acceleration. As an
+abstract API specification, ODP permits applications to run on and exploit the
+hardware offload capabilities of various platforms without requiring expertise
+in the nuances of any target platform.
+
+At the same time, ODP is also a set of implementations of these APIs that are
+optimized for each platform that supports ODP. Implementations of ODP currently
+exist for a wide range of platforms spanning diverse instruction set
+architectures including ARM, MIPS, Power, x86, as well as proprietary SoC
+architectures, and include both general-purpose servers as well as specialized
+networking SoCs.
+
+By decoupling the API definition from its implementation, ODP achieves two 
goals:
+
+* APIs can be defined to address data plane application needs rather than to
+expose specific platform capabilities. This leads to easy application
+portability across any platform that supports a conforming ODP implementation.
+The result is that applications written to the ODP APIs can run on any platform
+without developers needing expertise in the nuances of that platform
+
+.ODP Application view
+image::aboutODP1.svg[align="center"]
+
+* At the same time, by keeping APIs abstract, ODP allows vendors full freedom 
to
+implement these APIs in a manner optimized to the capabilities of each
+platform. This means that platforms can compete for any socket:
+
+.ODP Implementation view
+image::aboutODP2.svg[align="center"]
+
+This freedom is further enhanced by ODP’s use of 3-clause BSD licensing. ODP
+APIs are fully open source and open contribution, however individual
+implementors of these APIs may choose to make their code

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

[Ola Liljedahl]

On 23 May 2016 at 12:42, Christophe Milard 
wrote:

> On 23 May 2016 at 11:13, Yi He  wrote:
>
> > Thanks very much Christophe
> >
> > This is great, I'll use this tech in
> > odph_odpthread_setaffinity()/getaffinity() APIs.
> >
>
> > Do you mean you think keeping underlying Linux pthread/process concepts
> > out of ODP thread concept is not good?
> >
>
> Not sure. We are hiting this kind of problems a bit everywhere and that
> worries me. But it seems quite accepted that these are not and should not
> be part of ODP: Hopefully, we can keep going with this approach.
>
>
> > From many discussions I got a Feeling that by ODP thread we are really
> > trying to provide a higher level execution abstraction above linux
> > pthread/process units, underlying linux pthread/process are like
> containers
> > or boxes for our componentized/re-usable code pieces?
> >
>
> Yes. I am trying to get a clear view on this, which I have hard to achieve.
> The behaviour of the differents ODP objects /  pointers when accessed from
> different virtual address space (i.e. process) is not 100% clear to me.
>
I think this has to be implementation specific but strongly recommended
that ODP threads share all ODP resources, including mappings from ODP
objects to addresses (under some conditions as we have discussed). This is
what most application will expect and ODP will surely fail if this is not
supported by common ODP implementations. I don't see 100% application
portability between different ODP implementations and platforms as a strict
requirement and I don't think this possible anyway (different HW platforms
do have different features and SW will not be able to make up for all
limitations in HW).


> Christophe.
>
>
> > I'm not sure if this feeling is right :), we can talk in ARCH if got
> time.
> >
> > Best Regards, Yi
> >
> > On 23 May 2016 at 16:48, Christophe Milard  >
> > wrote:
> >
> >> Hi,
> >>
> >> I guess (not 100% sure if that civer all cases) if gettid() == getpid()
> >> you are on the main process thread.
> >> Having said that I do not like this solution very much: It really looks
> >> to me that we have a larger problem trying to keep these things out of
> ODP
> >>
> >> Something for ARCH call, maybe?
> >>
> >> Christophe.
> >>
> >> On 23 May 2016 at 10:16, Yi He  wrote:
> >>
> >>> Hi, Christophe
> >>>
> >>> Here I met a difficulty, if I unified the API into
> odph_odpthread_set_affinity(),
> >>> inside the function how can I determine whether the current context is
> a
> >>> pthread or process? So I cannot decide to call sched_setaffinity() or
> >>> pthread_setaffinity_np().
> >>>
> >>> thanks and best regards, Yi
> >>>
> >>>
> >>>
> >>> On 23 May 2016 at 14:53, Yi He  wrote:
> >>>
>  Hi, Christophe
> 
>  Yes, I'll apply your series and send a new one later.
> 
>  Best Regards, Yi
> 
>  On 23 May 2016 at 14:33, Christophe Milard <
>  christophe.mil...@linaro.org> wrote:
> 
> >
> >
> > On 20 May 2016 at 10:48, Yi He  wrote:
> >
> >> Set affinity to 1st available control cpu for all odp
> >> validation programs in odp_cunit_common library.
> >>
> >> Signed-off-by: Yi He 
> >> ---
> >>  helper/include/odp/helper/linux.h | 47 +++
> >>  helper/linux.c| 32 +
> >>  helper/test/thread.c  | 76
> >> +--
> >>  test/validation/common/odp_cunit_common.c | 15 --
> >>  4 files changed, 164 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/helper/include/odp/helper/linux.h
> >> b/helper/include/odp/helper/linux.h
> >> index e2dca35..fa815e1 100644
> >> --- a/helper/include/odp/helper/linux.h
> >> +++ b/helper/include/odp/helper/linux.h
> >> @@ -84,6 +84,29 @@ int
> odph_linux_pthread_create(odph_linux_pthread_t
> >> *pthread_tbl,
> >>   */
> >>  void odph_linux_pthread_join(odph_linux_pthread_t *thread_tbl, int
> >> num);
> >>
> >> +/**
> >> + * Set CPU affinity of the current thread
> >> + *
> >> + * CPU affinity determines the set of CPUs on which the thread is
> >> + * eligible to run.
> >> + *
> >> + * @param cpusetA bitmask lists the affinity CPU cores
> >> + *
> >> + * @return 0 on success, -1 on failure
> >> + */
> >> +int odph_linux_pthread_setaffinity(const odp_cpumask_t *cpuset);
> >>
> >
> > odph_odpthread_set_affinity(), is I guess better, at least as long as
> > we try to keep thread and processes together. Dropping the linux
> prefix
> > makes also the code more portable (on some other OS, change provide
> new
> > helpers and the app does hopefully not need to change)
> >
> > I guess you can apply the "running things in  process mode" patch
> > series to see what I am after...
> >
> > This comment applies to all your function names, of course.
> >
> > Christ

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Ola Liljedahl]

On 23 May 2016 at 17:04, Christophe Milard 
wrote:

> Signed-off-by: Christophe Milard 
> ---
>  helper/include/odp/helper/linux.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/helper/include/odp/helper/linux.h
> b/helper/include/odp/helper/linux.h
> index 01c348d..2e89833 100644
> --- a/helper/include/odp/helper/linux.h
> +++ b/helper/include/odp/helper/linux.h
> @@ -73,13 +73,13 @@ typedef struct {
>
>  /** The odpthread starting arguments, used both in process or thread mode
> */
>  typedef struct {
> -   odph_odpthread_linuxtype_t linuxtype;
> -   odph_odpthread_params_t thr_params; /*copy of thread start
> parameter*/
> +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread */
>
ODP threads might not be pthreads. There are many implementations of
threads.
Aren't we trying to tell the application if we are using a single-process
(memory space) or multi-process model?
Let's report this and only this.

+   odph_odpthread_params_t thr_params; /**< odpthread start parameters
> */
>  } odph_odpthread_start_args_t;
>
>  /** Linux odpthread state information, used both in process or thread
> mode */
>  typedef struct {
> -   odph_odpthread_start_args_t start_args;
> +   odph_odpthread_start_args_t start_args; /**< start arguments */
> int cpu;/**< CPU ID */
> int last;   /**< true if last table
> entry */
> union {
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

This is for linux helpers: in odp linux, just pthreads and processes are
supported as odpthreads.(well actually processes are not supported yet, but
we head to it).
If we support something else in some future, we'll update the comment then.

Christophe

On 23 May 2016 at 17:23, Ola Liljedahl  wrote:

>
>
> On 23 May 2016 at 17:04, Christophe Milard 
> wrote:
>
>> Signed-off-by: Christophe Milard 
>> ---
>>  helper/include/odp/helper/linux.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/helper/include/odp/helper/linux.h
>> b/helper/include/odp/helper/linux.h
>> index 01c348d..2e89833 100644
>> --- a/helper/include/odp/helper/linux.h
>> +++ b/helper/include/odp/helper/linux.h
>> @@ -73,13 +73,13 @@ typedef struct {
>>
>>  /** The odpthread starting arguments, used both in process or thread
>> mode */
>>  typedef struct {
>> -   odph_odpthread_linuxtype_t linuxtype;
>> -   odph_odpthread_params_t thr_params; /*copy of thread start
>> parameter*/
>> +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread */
>>
> ODP threads might not be pthreads. There are many implementations of
> threads.
> Aren't we trying to tell the application if we are using a single-process
> (memory space) or multi-process model?
> Let's report this and only this.
>
> +   odph_odpthread_params_t thr_params; /**< odpthread start
>> parameters */
>>  } odph_odpthread_start_args_t;
>>
>>  /** Linux odpthread state information, used both in process or thread
>> mode */
>>  typedef struct {
>> -   odph_odpthread_start_args_t start_args;
>> +   odph_odpthread_start_args_t start_args; /**< start arguments
>> */
>> int cpu;/**< CPU ID */
>> int last;   /**< true if last table
>> entry */
>> union {
>> --
>> 2.5.0
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Ola Liljedahl]

On 23 May 2016 at 17:28, Christophe Milard 
wrote:

> This is for linux helpers: in odp linux, just pthreads and processes are
> supported as odpthreads.(well actually processes are not supported yet, but
> we head to it).
>
You can use C and C++ threads in Linux as well. You just need a conforming
compiler.


> If we support something else in some future, we'll update the comment then.
>
> Christophe
>
> On 23 May 2016 at 17:23, Ola Liljedahl  wrote:
>
>>
>>
>> On 23 May 2016 at 17:04, Christophe Milard 
>> wrote:
>>
>>> Signed-off-by: Christophe Milard 
>>> ---
>>>  helper/include/odp/helper/linux.h | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/helper/include/odp/helper/linux.h
>>> b/helper/include/odp/helper/linux.h
>>> index 01c348d..2e89833 100644
>>> --- a/helper/include/odp/helper/linux.h
>>> +++ b/helper/include/odp/helper/linux.h
>>> @@ -73,13 +73,13 @@ typedef struct {
>>>
>>>  /** The odpthread starting arguments, used both in process or thread
>>> mode */
>>>  typedef struct {
>>> -   odph_odpthread_linuxtype_t linuxtype;
>>> -   odph_odpthread_params_t thr_params; /*copy of thread start
>>> parameter*/
>>> +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread */
>>>
>> ODP threads might not be pthreads. There are many implementations of
>> threads.
>> Aren't we trying to tell the application if we are using a single-process
>> (memory space) or multi-process model?
>> Let's report this and only this.
>>
>> +   odph_odpthread_params_t thr_params; /**< odpthread start
>>> parameters */
>>>  } odph_odpthread_start_args_t;
>>>
>>>  /** Linux odpthread state information, used both in process or thread
>>> mode */
>>>  typedef struct {
>>> -   odph_odpthread_start_args_t start_args;
>>> +   odph_odpthread_start_args_t start_args; /**< start arguments
>>> */
>>> int cpu;/**< CPU ID */
>>> int last;   /**< true if last table
>>> entry */
>>> union {
>>> --
>>> 2.5.0
>>>
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

On 23 May 2016 at 17:31, Ola Liljedahl  wrote:

>
>
> On 23 May 2016 at 17:28, Christophe Milard 
> wrote:
>
>> This is for linux helpers: in odp linux, just pthreads and processes are
>> supported as odpthreads.(well actually processes are not supported yet, but
>> we head to it).
>>
> You can use C and C++ threads in Linux as well. You just need a conforming
> compiler.
>

Not through the helper at this stage. When calling odph_odpthread_create(),
the odpthread is created as either pthread (default) or forked process
(--odph_proc option).
So at this stage C and C++ threads are not supported by the helpers.


>
>
>> If we support something else in some future, we'll update the comment
>> then.
>>
>> Christophe
>>
>> On 23 May 2016 at 17:23, Ola Liljedahl  wrote:
>>
>>>
>>>
>>> On 23 May 2016 at 17:04, Christophe Milard >> > wrote:
>>>
 Signed-off-by: Christophe Milard 
 ---
  helper/include/odp/helper/linux.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/helper/include/odp/helper/linux.h
 b/helper/include/odp/helper/linux.h
 index 01c348d..2e89833 100644
 --- a/helper/include/odp/helper/linux.h
 +++ b/helper/include/odp/helper/linux.h
 @@ -73,13 +73,13 @@ typedef struct {

  /** The odpthread starting arguments, used both in process or thread
 mode */
  typedef struct {
 -   odph_odpthread_linuxtype_t linuxtype;
 -   odph_odpthread_params_t thr_params; /*copy of thread start
 parameter*/
 +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread */

>>> ODP threads might not be pthreads. There are many implementations of
>>> threads.
>>> Aren't we trying to tell the application if we are using a
>>> single-process (memory space) or multi-process model?
>>> Let's report this and only this.
>>>
>>> +   odph_odpthread_params_t thr_params; /**< odpthread start
 parameters */
  } odph_odpthread_start_args_t;

  /** Linux odpthread state information, used both in process or thread
 mode */
  typedef struct {
 -   odph_odpthread_start_args_t start_args;
 +   odph_odpthread_start_args_t start_args; /**< start
 arguments */
 int cpu;/**< CPU ID */
 int last;   /**< true if last table
 entry */
 union {
 --
 2.5.0

 ___
 lng-odp mailing list
 lng-odp@lists.linaro.org
 https://lists.linaro.org/mailman/listinfo/lng-odp

>>>
>>>
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] linux-generic: timer: generalize arch-specific code path selection

[Maxim Uvarov]

Merged,
Maxim.

On 05/22/16 19:02, Bill Fischofer wrote:

On Fri, May 20, 2016 at 4:45 PM, Ola Liljedahl 
wrote:


Make architecture-specific code path selection generic, controlled
directly by compiler feature predefines.
Replace macro PREFETCH with intrinsic __builtin_prefetch.
Fixes https://bugs.linaro.org/show_bug.cgi?id=2235

Signed-off-by: Ola Liljedahl 


Reviewed-and-tested-by: Bill Fischofer 



---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)

  platform/linux-generic/odp_timer.c | 28 +---
  1 file changed, 9 insertions(+), 19 deletions(-)

diff --git a/platform/linux-generic/odp_timer.c
b/platform/linux-generic/odp_timer.c
index a6d3332..4e56fb0 100644
--- a/platform/linux-generic/odp_timer.c
+++ b/platform/linux-generic/odp_timer.c
@@ -58,12 +58,6 @@
   * for checking the freshness of received timeouts */
  #define TMO_INACTIVE ((uint64_t)0x8000)

-#ifdef __ARM_ARCH
-#define PREFETCH(ptr) __builtin_prefetch((ptr), 0, 0)
-#else
-#define PREFETCH(ptr) (void)(ptr)
-#endif
-

  
/**
   * Mutual exclusion in the absence of CAS16

*/
@@ -210,7 +204,7 @@ static inline uint32_t handle_to_idx(odp_timer_t hdl,
 struct odp_timer_pool_s *tp)
  {
 uint32_t idx = _odp_typeval(hdl) & ((1U << INDEX_BITS) - 1U);
-   PREFETCH(&tp->tick_buf[idx]);
+   __builtin_prefetch(&tp->tick_buf[idx], 0, 0);
 if (odp_likely(idx < odp_atomic_load_u32(&tp->high_wm)))
 return idx;
 ODP_ABORT("Invalid timer handle %#x\n", hdl);
@@ -395,7 +389,7 @@ static bool timer_reset(uint32_t idx,
 tick_buf_t *tb = &tp->tick_buf[idx];

 if (tmo_buf == NULL || *tmo_buf == ODP_BUFFER_INVALID) {
-#ifdef ODP_ATOMIC_U128
+#ifdef ODP_ATOMIC_U128 /* Target supports 128-bit atomic operations */
 tick_buf_t new, old;
 do {
 /* Relaxed and non-atomic read of current values */
@@ -422,9 +416,10 @@ static bool timer_reset(uint32_t idx,
 (_uint128_t *)&new,
 _ODP_MEMMODEL_RLS,
 _ODP_MEMMODEL_RLX));
-#else
-#ifdef __ARM_ARCH
-   /* Since barriers are not good for C-A15, we take an
+#elif __GCC_ATOMIC_LLONG_LOCK_FREE >= 2 && \
+   defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
+   /* Target supports lock-free 64-bit CAS (and probably exchange) */
+   /* Since locks/barriers are not good for C-A15, we take an
  * alternative approach using relaxed memory model */
 uint64_t old;
 /* Swap in new expiration tick, get back old tick which
@@ -450,7 +445,7 @@ static bool timer_reset(uint32_t idx,
 _ODP_MEMMODEL_RLX);
 success = false;
 }
-#else
+#else /* Target supports neither 128-bit nor 64-bit CAS => use lock */
 /* Take a related lock */
 while (_odp_atomic_flag_tas(IDX2LOCK(idx)))
 /* While lock is taken, spin using relaxed loads */
@@ -470,7 +465,6 @@ static bool timer_reset(uint32_t idx,
 /* Release the lock */
 _odp_atomic_flag_clear(IDX2LOCK(idx));
  #endif
-#endif
 } else {
 /* We have a new timeout buffer which replaces any old one
*/
 /* Fill in some (constant) header fields for timeout
events */
@@ -655,13 +649,11 @@ static unsigned
odp_timer_pool_expire(odp_timer_pool_t tpid, uint64_t tick)

 ODP_ASSERT(high_wm <= tpid->param.num_timers);
 for (i = 0; i < high_wm;) {
-#ifdef __ARM_ARCH
 /* As a rare occurrence, we can outsmart the HW prefetcher
  * and the compiler (GCC -fprefetch-loop-arrays) with some
  * tuned manual prefetching (32x16=512B ahead), seems to
  * give 30% better performance on ARM C-A15 */
-   PREFETCH(&array[i + 32]);
-#endif
+   __builtin_prefetch(&array[i + 32], 0, 0);
 /* Non-atomic read for speed */
 uint64_t exp_tck = array[i++].exp_tck.v;
 if (odp_unlikely(exp_tck <= tick)) {
@@ -691,13 +683,11 @@ static void timer_notify(odp_timer_pool *tp)
 }
 }

-#ifdef __ARM_ARCH
 odp_timer *array = &tp->timers[0];
 uint32_t i;
 /* Prefetch initial cache lines (match 32 above) */
 for (i = 0; i < 32; i += ODP_CACHE_LINE_SIZE / sizeof(array[0]))
-   PREFETCH(&array[i]);
-#endif
+   __builtin_prefetch(&array[i], 0, 0);
 prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick);

 /* Scan timer array, looking for timers to expire */
--

[lng-odp] number of CPU's actually used by linux-generic

[Ola Liljedahl]

Bill mentioned something in an email recently and I see the same.
On a four core x86-64 machine, I see only two ODP worker threads. Assuming
one CPU is allocated for the control thread, what is the fourth CPU doing
(not much I guess).

-- Ola
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Ola Liljedahl]

On 23 May 2016 at 17:34, Christophe Milard 
wrote:

>
>
> On 23 May 2016 at 17:31, Ola Liljedahl  wrote:
>
>>
>>
>> On 23 May 2016 at 17:28, Christophe Milard 
>> wrote:
>>
>>> This is for linux helpers: in odp linux, just pthreads and processes are
>>> supported as odpthreads.(well actually processes are not supported yet, but
>>> we head to it).
>>>
>> You can use C and C++ threads in Linux as well. You just need a
>> conforming compiler.
>>
>
> Not through the helper at this stage. When calling
> odph_odpthread_create(), the odpthread is created as either pthread
> (default) or forked process (--odph_proc option).
> So at this stage C and C++ threads are not supported by the helpers.
>
OK that's fine if this is all encapsulated in to ODP/Linux helpers. That
should be possible to change without interfering too much with the actual
ODP implementation in use.


>
>
>>
>>
>>> If we support something else in some future, we'll update the comment
>>> then.
>>>
>>> Christophe
>>>
>>> On 23 May 2016 at 17:23, Ola Liljedahl  wrote:
>>>


 On 23 May 2016 at 17:04, Christophe Milard <
 christophe.mil...@linaro.org> wrote:

> Signed-off-by: Christophe Milard 
> ---
>  helper/include/odp/helper/linux.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/helper/include/odp/helper/linux.h
> b/helper/include/odp/helper/linux.h
> index 01c348d..2e89833 100644
> --- a/helper/include/odp/helper/linux.h
> +++ b/helper/include/odp/helper/linux.h
> @@ -73,13 +73,13 @@ typedef struct {
>
>  /** The odpthread starting arguments, used both in process or thread
> mode */
>  typedef struct {
> -   odph_odpthread_linuxtype_t linuxtype;
> -   odph_odpthread_params_t thr_params; /*copy of thread start
> parameter*/
> +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread
> */
>
 ODP threads might not be pthreads. There are many implementations of
 threads.
 Aren't we trying to tell the application if we are using a
 single-process (memory space) or multi-process model?
 Let's report this and only this.

 +   odph_odpthread_params_t thr_params; /**< odpthread start
> parameters */
>  } odph_odpthread_start_args_t;
>
>  /** Linux odpthread state information, used both in process or thread
> mode */
>  typedef struct {
> -   odph_odpthread_start_args_t start_args;
> +   odph_odpthread_start_args_t start_args; /**< start
> arguments */
> int cpu;/**< CPU ID */
> int last;   /**< true if last
> table entry */
> union {
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>


>>>
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Mike Holmes]

Did a quick google on possibilities for how to implement an odp_thread, 99%
of which we dont support , but might make an interesting project.


https://software.intel.com/en-us/articles/choosing-the-right-threading-framework

On 23 May 2016 at 11:34, Christophe Milard 
wrote:

> On 23 May 2016 at 17:31, Ola Liljedahl  wrote:
>
> >
> >
> > On 23 May 2016 at 17:28, Christophe Milard  >
> > wrote:
> >
> >> This is for linux helpers: in odp linux, just pthreads and processes are
> >> supported as odpthreads.(well actually processes are not supported yet,
> but
> >> we head to it).
> >>
> > You can use C and C++ threads in Linux as well. You just need a
> conforming
> > compiler.
> >
>
> Not through the helper at this stage. When calling odph_odpthread_create(),
> the odpthread is created as either pthread (default) or forked process
> (--odph_proc option).
> So at this stage C and C++ threads are not supported by the helpers.
>
>
> >
> >
> >> If we support something else in some future, we'll update the comment
> >> then.
> >>
> >> Christophe
> >>
> >> On 23 May 2016 at 17:23, Ola Liljedahl 
> wrote:
> >>
> >>>
> >>>
> >>> On 23 May 2016 at 17:04, Christophe Milard <
> christophe.mil...@linaro.org
> >>> > wrote:
> >>>
>  Signed-off-by: Christophe Milard 
>  ---
>   helper/include/odp/helper/linux.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
>  diff --git a/helper/include/odp/helper/linux.h
>  b/helper/include/odp/helper/linux.h
>  index 01c348d..2e89833 100644
>  --- a/helper/include/odp/helper/linux.h
>  +++ b/helper/include/odp/helper/linux.h
>  @@ -73,13 +73,13 @@ typedef struct {
> 
>   /** The odpthread starting arguments, used both in process or thread
>  mode */
>   typedef struct {
>  -   odph_odpthread_linuxtype_t linuxtype;
>  -   odph_odpthread_params_t thr_params; /*copy of thread start
>  parameter*/
>  +   odph_odpthread_linuxtype_t linuxtype; /**< process or pthread
> */
> 
> >>> ODP threads might not be pthreads. There are many implementations of
> >>> threads.
> >>> Aren't we trying to tell the application if we are using a
> >>> single-process (memory space) or multi-process model?
> >>> Let's report this and only this.
> >>>
> >>> +   odph_odpthread_params_t thr_params; /**< odpthread start
>  parameters */
>   } odph_odpthread_start_args_t;
> 
>   /** Linux odpthread state information, used both in process or thread
>  mode */
>   typedef struct {
>  -   odph_odpthread_start_args_t start_args;
>  +   odph_odpthread_start_args_t start_args; /**< start
>  arguments */
>  int cpu;/**< CPU ID */
>  int last;   /**< true if last
> table
>  entry */
>  union {
>  --
>  2.5.0
> 
>  ___
>  lng-odp mailing list
>  lng-odp@lists.linaro.org
>  https://lists.linaro.org/mailman/listinfo/lng-odp
> 
> >>>
> >>>
> >>
> >
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

I don't think we should implement this by our own. If we do somthing about
it, it would just be awrapper for some functions, I guess...

On 23 May 2016 at 17:47, Mike Holmes  wrote:

> Did a quick google on possibilities for how to implement an odp_thread,
> 99% of which we dont support , but might make an interesting project.
>
>
>
> https://software.intel.com/en-us/articles/choosing-the-right-threading-framework
>
> On 23 May 2016 at 11:34, Christophe Milard 
> wrote:
>
>> On 23 May 2016 at 17:31, Ola Liljedahl  wrote:
>>
>> >
>> >
>> > On 23 May 2016 at 17:28, Christophe Milard <
>> christophe.mil...@linaro.org>
>> > wrote:
>> >
>> >> This is for linux helpers: in odp linux, just pthreads and processes
>> are
>> >> supported as odpthreads.(well actually processes are not supported
>> yet, but
>> >> we head to it).
>> >>
>> > You can use C and C++ threads in Linux as well. You just need a
>> conforming
>> > compiler.
>> >
>>
>> Not through the helper at this stage. When calling
>> odph_odpthread_create(),
>> the odpthread is created as either pthread (default) or forked process
>> (--odph_proc option).
>> So at this stage C and C++ threads are not supported by the helpers.
>>
>>
>> >
>> >
>> >> If we support something else in some future, we'll update the comment
>> >> then.
>> >>
>> >> Christophe
>> >>
>> >> On 23 May 2016 at 17:23, Ola Liljedahl 
>> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 23 May 2016 at 17:04, Christophe Milard <
>> christophe.mil...@linaro.org
>> >>> > wrote:
>> >>>
>>  Signed-off-by: Christophe Milard 
>>  ---
>>   helper/include/odp/helper/linux.h | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>>  diff --git a/helper/include/odp/helper/linux.h
>>  b/helper/include/odp/helper/linux.h
>>  index 01c348d..2e89833 100644
>>  --- a/helper/include/odp/helper/linux.h
>>  +++ b/helper/include/odp/helper/linux.h
>>  @@ -73,13 +73,13 @@ typedef struct {
>> 
>>   /** The odpthread starting arguments, used both in process or thread
>>  mode */
>>   typedef struct {
>>  -   odph_odpthread_linuxtype_t linuxtype;
>>  -   odph_odpthread_params_t thr_params; /*copy of thread start
>>  parameter*/
>>  +   odph_odpthread_linuxtype_t linuxtype; /**< process or
>> pthread */
>> 
>> >>> ODP threads might not be pthreads. There are many implementations of
>> >>> threads.
>> >>> Aren't we trying to tell the application if we are using a
>> >>> single-process (memory space) or multi-process model?
>> >>> Let's report this and only this.
>> >>>
>> >>> +   odph_odpthread_params_t thr_params; /**< odpthread start
>>  parameters */
>>   } odph_odpthread_start_args_t;
>> 
>>   /** Linux odpthread state information, used both in process or
>> thread
>>  mode */
>>   typedef struct {
>>  -   odph_odpthread_start_args_t start_args;
>>  +   odph_odpthread_start_args_t start_args; /**< start
>>  arguments */
>>  int cpu;/**< CPU ID */
>>  int last;   /**< true if last
>> table
>>  entry */
>>  union {
>>  --
>>  2.5.0
>> 
>>  ___
>>  lng-odp mailing list
>>  lng-odp@lists.linaro.org
>>  https://lists.linaro.org/mailman/listinfo/lng-odp
>> 
>> >>>
>> >>>
>> >>
>> >
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Mike Holmes]

I was looking for some definitions that would save us having to
perpetuate this topic into its 5/6th week. I hoped to find a model.

I agree, we dont want to work on helper support for anything new
unless it brought a robust proven model.

On 23 May 2016 at 11:58, Christophe Milard  wrote:
> I don't think we should implement this by our own. If we do somthing about
> it, it would just be awrapper for some functions, I guess...
>
> On 23 May 2016 at 17:47, Mike Holmes  wrote:
>>
>> Did a quick google on possibilities for how to implement an odp_thread,
>> 99% of which we dont support , but might make an interesting project.
>>
>>
>>
>> https://software.intel.com/en-us/articles/choosing-the-right-threading-framework
>>
>> On 23 May 2016 at 11:34, Christophe Milard 
>> wrote:
>>>
>>> On 23 May 2016 at 17:31, Ola Liljedahl  wrote:
>>>
>>> >
>>> >
>>> > On 23 May 2016 at 17:28, Christophe Milard
>>> > 
>>> > wrote:
>>> >
>>> >> This is for linux helpers: in odp linux, just pthreads and processes
>>> >> are
>>> >> supported as odpthreads.(well actually processes are not supported
>>> >> yet, but
>>> >> we head to it).
>>> >>
>>> > You can use C and C++ threads in Linux as well. You just need a
>>> > conforming
>>> > compiler.
>>> >
>>>
>>> Not through the helper at this stage. When calling
>>> odph_odpthread_create(),
>>> the odpthread is created as either pthread (default) or forked process
>>> (--odph_proc option).
>>> So at this stage C and C++ threads are not supported by the helpers.
>>>
>>>
>>> >
>>> >
>>> >> If we support something else in some future, we'll update the comment
>>> >> then.
>>> >>
>>> >> Christophe
>>> >>
>>> >> On 23 May 2016 at 17:23, Ola Liljedahl 
>>> >> wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>> On 23 May 2016 at 17:04, Christophe Milard
>>> >>> >> >>> > wrote:
>>> >>>
>>>  Signed-off-by: Christophe Milard 
>>>  ---
>>>   helper/include/odp/helper/linux.h | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>> 
>>>  diff --git a/helper/include/odp/helper/linux.h
>>>  b/helper/include/odp/helper/linux.h
>>>  index 01c348d..2e89833 100644
>>>  --- a/helper/include/odp/helper/linux.h
>>>  +++ b/helper/include/odp/helper/linux.h
>>>  @@ -73,13 +73,13 @@ typedef struct {
>>> 
>>>   /** The odpthread starting arguments, used both in process or
>>>  thread
>>>  mode */
>>>   typedef struct {
>>>  -   odph_odpthread_linuxtype_t linuxtype;
>>>  -   odph_odpthread_params_t thr_params; /*copy of thread start
>>>  parameter*/
>>>  +   odph_odpthread_linuxtype_t linuxtype; /**< process or
>>>  pthread */
>>> 
>>> >>> ODP threads might not be pthreads. There are many implementations of
>>> >>> threads.
>>> >>> Aren't we trying to tell the application if we are using a
>>> >>> single-process (memory space) or multi-process model?
>>> >>> Let's report this and only this.
>>> >>>
>>> >>> +   odph_odpthread_params_t thr_params; /**< odpthread start
>>>  parameters */
>>>   } odph_odpthread_start_args_t;
>>> 
>>>   /** Linux odpthread state information, used both in process or
>>>  thread
>>>  mode */
>>>   typedef struct {
>>>  -   odph_odpthread_start_args_t start_args;
>>>  +   odph_odpthread_start_args_t start_args; /**< start
>>>  arguments */
>>>  int cpu;/**< CPU ID */
>>>  int last;   /**< true if last
>>>  table
>>>  entry */
>>>  union {
>>>  --
>>>  2.5.0
>>> 
>>>  ___
>>>  lng-odp mailing list
>>>  lng-odp@lists.linaro.org
>>>  https://lists.linaro.org/mailman/listinfo/lng-odp
>>> 
>>> >>>
>>> >>>
>>> >>
>>> >
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org │ Open source software for ARM SoCs
>> "Work should be fun and collaborative, the rest follows"
>>
>>
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

OK. if everyone now agrees, maybe this can be marked as reviewed :-). 3
extra comments should not generate a storm, should it? It fixes a doxygen
warning on the helper...

Christophe.

On 23 May 2016 at 18:00, Mike Holmes  wrote:

> I was looking for some definitions that would save us having to
> perpetuate this topic into its 5/6th week. I hoped to find a model.
>
> I agree, we dont want to work on helper support for anything new
> unless it brought a robust proven model.
>
> On 23 May 2016 at 11:58, Christophe Milard 
> wrote:
> > I don't think we should implement this by our own. If we do somthing
> about
> > it, it would just be awrapper for some functions, I guess...
> >
> > On 23 May 2016 at 17:47, Mike Holmes  wrote:
> >>
> >> Did a quick google on possibilities for how to implement an odp_thread,
> >> 99% of which we dont support , but might make an interesting project.
> >>
> >>
> >>
> >>
> https://software.intel.com/en-us/articles/choosing-the-right-threading-framework
> >>
> >> On 23 May 2016 at 11:34, Christophe Milard <
> christophe.mil...@linaro.org>
> >> wrote:
> >>>
> >>> On 23 May 2016 at 17:31, Ola Liljedahl 
> wrote:
> >>>
> >>> >
> >>> >
> >>> > On 23 May 2016 at 17:28, Christophe Milard
> >>> > 
> >>> > wrote:
> >>> >
> >>> >> This is for linux helpers: in odp linux, just pthreads and processes
> >>> >> are
> >>> >> supported as odpthreads.(well actually processes are not supported
> >>> >> yet, but
> >>> >> we head to it).
> >>> >>
> >>> > You can use C and C++ threads in Linux as well. You just need a
> >>> > conforming
> >>> > compiler.
> >>> >
> >>>
> >>> Not through the helper at this stage. When calling
> >>> odph_odpthread_create(),
> >>> the odpthread is created as either pthread (default) or forked process
> >>> (--odph_proc option).
> >>> So at this stage C and C++ threads are not supported by the helpers.
> >>>
> >>>
> >>> >
> >>> >
> >>> >> If we support something else in some future, we'll update the
> comment
> >>> >> then.
> >>> >>
> >>> >> Christophe
> >>> >>
> >>> >> On 23 May 2016 at 17:23, Ola Liljedahl 
> >>> >> wrote:
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>> On 23 May 2016 at 17:04, Christophe Milard
> >>> >>>  >>> >>> > wrote:
> >>> >>>
> >>>  Signed-off-by: Christophe Milard 
> >>>  ---
> >>>   helper/include/odp/helper/linux.h | 6 +++---
> >>>   1 file changed, 3 insertions(+), 3 deletions(-)
> >>> 
> >>>  diff --git a/helper/include/odp/helper/linux.h
> >>>  b/helper/include/odp/helper/linux.h
> >>>  index 01c348d..2e89833 100644
> >>>  --- a/helper/include/odp/helper/linux.h
> >>>  +++ b/helper/include/odp/helper/linux.h
> >>>  @@ -73,13 +73,13 @@ typedef struct {
> >>> 
> >>>   /** The odpthread starting arguments, used both in process or
> >>>  thread
> >>>  mode */
> >>>   typedef struct {
> >>>  -   odph_odpthread_linuxtype_t linuxtype;
> >>>  -   odph_odpthread_params_t thr_params; /*copy of thread start
> >>>  parameter*/
> >>>  +   odph_odpthread_linuxtype_t linuxtype; /**< process or
> >>>  pthread */
> >>> 
> >>> >>> ODP threads might not be pthreads. There are many implementations
> of
> >>> >>> threads.
> >>> >>> Aren't we trying to tell the application if we are using a
> >>> >>> single-process (memory space) or multi-process model?
> >>> >>> Let's report this and only this.
> >>> >>>
> >>> >>> +   odph_odpthread_params_t thr_params; /**< odpthread start
> >>>  parameters */
> >>>   } odph_odpthread_start_args_t;
> >>> 
> >>>   /** Linux odpthread state information, used both in process or
> >>>  thread
> >>>  mode */
> >>>   typedef struct {
> >>>  -   odph_odpthread_start_args_t start_args;
> >>>  +   odph_odpthread_start_args_t start_args; /**< start
> >>>  arguments */
> >>>  int cpu;/**< CPU ID */
> >>>  int last;   /**< true if last
> >>>  table
> >>>  entry */
> >>>  union {
> >>>  --
> >>>  2.5.0
> >>> 
> >>>  ___
> >>>  lng-odp mailing list
> >>>  lng-odp@lists.linaro.org
> >>>  https://lists.linaro.org/mailman/listinfo/lng-odp
> >>> 
> >>> >>>
> >>> >>>
> >>> >>
> >>> >
> >>> ___
> >>> lng-odp mailing list
> >>> lng-odp@lists.linaro.org
> >>> https://lists.linaro.org/mailman/listinfo/lng-odp
> >>
> >>
> >>
> >>
> >> --
> >> Mike Holmes
> >> Technical Manager - Linaro Networking Group
> >> Linaro.org │ Open source software for ARM SoCs
> >> "Work should be fun and collaborative, the rest follows"
> >>
> >>
> >
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org │ Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"
>
___
lng-odp mailing list
lng-odp@

Re: [lng-odp] [PATCH] helper: fixing doxygen comments for odpthread creation parameters

[Christophe Milard]

And on the top of this , I intend to write a patch to simplify this
interface, so hopefully this will become obsolete soon :-)

On 23 May 2016 at 18:31, Christophe Milard 
wrote:

> OK. if everyone now agrees, maybe this can be marked as reviewed :-). 3
> extra comments should not generate a storm, should it? It fixes a doxygen
> warning on the helper...
>
> Christophe.
>
> On 23 May 2016 at 18:00, Mike Holmes  wrote:
>
>> I was looking for some definitions that would save us having to
>> perpetuate this topic into its 5/6th week. I hoped to find a model.
>>
>> I agree, we dont want to work on helper support for anything new
>> unless it brought a robust proven model.
>>
>> On 23 May 2016 at 11:58, Christophe Milard 
>> wrote:
>> > I don't think we should implement this by our own. If we do somthing
>> about
>> > it, it would just be awrapper for some functions, I guess...
>> >
>> > On 23 May 2016 at 17:47, Mike Holmes  wrote:
>> >>
>> >> Did a quick google on possibilities for how to implement an odp_thread,
>> >> 99% of which we dont support , but might make an interesting project.
>> >>
>> >>
>> >>
>> >>
>> https://software.intel.com/en-us/articles/choosing-the-right-threading-framework
>> >>
>> >> On 23 May 2016 at 11:34, Christophe Milard <
>> christophe.mil...@linaro.org>
>> >> wrote:
>> >>>
>> >>> On 23 May 2016 at 17:31, Ola Liljedahl 
>> wrote:
>> >>>
>> >>> >
>> >>> >
>> >>> > On 23 May 2016 at 17:28, Christophe Milard
>> >>> > 
>> >>> > wrote:
>> >>> >
>> >>> >> This is for linux helpers: in odp linux, just pthreads and
>> processes
>> >>> >> are
>> >>> >> supported as odpthreads.(well actually processes are not supported
>> >>> >> yet, but
>> >>> >> we head to it).
>> >>> >>
>> >>> > You can use C and C++ threads in Linux as well. You just need a
>> >>> > conforming
>> >>> > compiler.
>> >>> >
>> >>>
>> >>> Not through the helper at this stage. When calling
>> >>> odph_odpthread_create(),
>> >>> the odpthread is created as either pthread (default) or forked process
>> >>> (--odph_proc option).
>> >>> So at this stage C and C++ threads are not supported by the helpers.
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> >> If we support something else in some future, we'll update the
>> comment
>> >>> >> then.
>> >>> >>
>> >>> >> Christophe
>> >>> >>
>> >>> >> On 23 May 2016 at 17:23, Ola Liljedahl 
>> >>> >> wrote:
>> >>> >>
>> >>> >>>
>> >>> >>>
>> >>> >>> On 23 May 2016 at 17:04, Christophe Milard
>> >>> >>> > >>> >>> > wrote:
>> >>> >>>
>> >>>  Signed-off-by: Christophe Milard 
>> >>>  ---
>> >>>   helper/include/odp/helper/linux.h | 6 +++---
>> >>>   1 file changed, 3 insertions(+), 3 deletions(-)
>> >>> 
>> >>>  diff --git a/helper/include/odp/helper/linux.h
>> >>>  b/helper/include/odp/helper/linux.h
>> >>>  index 01c348d..2e89833 100644
>> >>>  --- a/helper/include/odp/helper/linux.h
>> >>>  +++ b/helper/include/odp/helper/linux.h
>> >>>  @@ -73,13 +73,13 @@ typedef struct {
>> >>> 
>> >>>   /** The odpthread starting arguments, used both in process or
>> >>>  thread
>> >>>  mode */
>> >>>   typedef struct {
>> >>>  -   odph_odpthread_linuxtype_t linuxtype;
>> >>>  -   odph_odpthread_params_t thr_params; /*copy of thread
>> start
>> >>>  parameter*/
>> >>>  +   odph_odpthread_linuxtype_t linuxtype; /**< process or
>> >>>  pthread */
>> >>> 
>> >>> >>> ODP threads might not be pthreads. There are many implementations
>> of
>> >>> >>> threads.
>> >>> >>> Aren't we trying to tell the application if we are using a
>> >>> >>> single-process (memory space) or multi-process model?
>> >>> >>> Let's report this and only this.
>> >>> >>>
>> >>> >>> +   odph_odpthread_params_t thr_params; /**< odpthread start
>> >>>  parameters */
>> >>>   } odph_odpthread_start_args_t;
>> >>> 
>> >>>   /** Linux odpthread state information, used both in process or
>> >>>  thread
>> >>>  mode */
>> >>>   typedef struct {
>> >>>  -   odph_odpthread_start_args_t start_args;
>> >>>  +   odph_odpthread_start_args_t start_args; /**< start
>> >>>  arguments */
>> >>>  int cpu;/**< CPU ID */
>> >>>  int last;   /**< true if last
>> >>>  table
>> >>>  entry */
>> >>>  union {
>> >>>  --
>> >>>  2.5.0
>> >>> 
>> >>>  ___
>> >>>  lng-odp mailing list
>> >>>  lng-odp@lists.linaro.org
>> >>>  https://lists.linaro.org/mailman/listinfo/lng-odp
>> >>> 
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> ___
>> >>> lng-odp mailing list
>> >>> lng-odp@lists.linaro.org
>> >>> https://lists.linaro.org/mailman/listinfo/lng-odp
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Mike Holmes
>> >> Technical Manager - Linaro Networking Group
>> >> Linaro.org │ Open source software for ARM S

Re: [lng-odp] [PATCH] helper/test: add missing scripts to EXTRA_DIST

[Mike Holmes]

This must be in RC3, it breaks packaging

On 23 May 2016 at 10:44, Anders Roxell  wrote:
> Signed-off-by: Anders Roxell 
> ---
>  helper/test/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
> index 8e65948..e9e8785 100644
> --- a/helper/test/Makefile.am
> +++ b/helper/test/Makefile.am
> @@ -24,6 +24,7 @@ dist_bin_SCRIPTS =
>
>  bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
>
> +EXTRA_DIST = odpthreads_as_processes odpthreads_as_pthreads
>
>  dist_chksum_SOURCES = chksum.c
>  dist_odpthreads_SOURCES = odpthreads.c
> --
> 2.1.4
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] helper/test: add missing scripts to EXTRA_DIST

[Maxim Uvarov]

Merged as trivial patch.

Maxim.

On 05/23/16 19:55, Mike Holmes wrote:

This must be in RC3, it breaks packaging

On 23 May 2016 at 10:44, Anders Roxell  wrote:

Signed-off-by: Anders Roxell 
---
  helper/test/Makefile.am | 1 +
  1 file changed, 1 insertion(+)

diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
index 8e65948..e9e8785 100644
--- a/helper/test/Makefile.am
+++ b/helper/test/Makefile.am
@@ -24,6 +24,7 @@ dist_bin_SCRIPTS =

  bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)

+EXTRA_DIST = odpthreads_as_processes odpthreads_as_pthreads

  dist_chksum_SOURCES = chksum.c
  dist_odpthreads_SOURCES = odpthreads.c
--
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp





___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] number of CPU's actually used by linux-generic

[Yi He]

Hi,

This is a policy coded in: *platform/linux-generic/odp_cpumask.c*


*init_default_worker_cpumask()*
*init_default_control_cpumask():*

*...default mask initialization if not specified by odp_init_global()*
*/**

* * If three or more CPUs, reserve CPU 0 for kernel, * reserve CPU 1 for
control, and * reserve remaining CPUs for workers */Best Regards, Yi*

On 23 May 2016 at 23:40, Ola Liljedahl  wrote:

> Bill mentioned something in an email recently and I see the same.
> On a four core x86-64 machine, I see only two ODP worker threads. Assuming
> one CPU is allocated for the control thread, what is the fourth CPU doing
> (not much I guess).
>
> -- Ola
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH v2] example: introducing l3fwd

[Xuelin Shi]

multi-thread and bi-directional forwarding.
support at most cpu-1 forward threads.
each thread handles traffic of one port,
and each port is handled by only one thread.

Signed-off-by: Xuelin Shi 
---
change history:
 v2: merge v1 patch set into one patch 

 example/Makefile.am  |   2 +-
 example/l3fwd/Makefile.am|  11 +
 example/l3fwd/odp_l3fwd.c| 473 +++
 example/l3fwd/odp_l3fwd_db.c | 414 +
 example/l3fwd/odp_l3fwd_db.h | 137 +
 example/m4/configure.m4  |   1 +
 6 files changed, 1037 insertions(+), 1 deletion(-)
 create mode 100644 example/l3fwd/Makefile.am
 create mode 100644 example/l3fwd/odp_l3fwd.c
 create mode 100644 example/l3fwd/odp_l3fwd_db.c
 create mode 100644 example/l3fwd/odp_l3fwd_db.h

diff --git a/example/Makefile.am b/example/Makefile.am
index 7f82c4d..67e4389 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = classifier generator ipsec packet time timer traffic_mgmt 
l2fwd_simple switch
+SUBDIRS = classifier generator ipsec packet time timer traffic_mgmt 
l2fwd_simple l3fwd switch
diff --git a/example/l3fwd/Makefile.am b/example/l3fwd/Makefile.am
new file mode 100644
index 000..0ba4527
--- /dev/null
+++ b/example/l3fwd/Makefile.am
@@ -0,0 +1,11 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_l3fwd$(EXEEXT)
+odp_l3fwd_LDFLAGS = $(AM_LDFLAGS) -static
+odp_l3fwd_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/l3fwd/odp_l3fwd_db.h \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_l3fwd_SOURCES = odp_l3fwd.c odp_l3fwd_db.c
diff --git a/example/l3fwd/odp_l3fwd.c b/example/l3fwd/odp_l3fwd.c
new file mode 100644
index 000..838f3e5
--- /dev/null
+++ b/example/l3fwd/odp_l3fwd.c
@@ -0,0 +1,473 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "odp_l3fwd_db.h"
+
+#define POOL_NUM_PKT 8192
+#define POOL_SEG_LEN 1856
+#define MAX_PKT_BURST 32
+
+#define MAX_NB_WORKER  8
+#define MAX_NB_PKTIO   4
+#define MAX_NB_ROUTE32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   char *if_names[MAX_NB_PKTIO];
+   int if_count;
+   char *route_str[MAX_NB_ROUTE];
+   int worker_count;
+} app_args_t;
+
+struct l3fwd_pktio_s {
+   odp_pktio_t pktio;
+   odp_pktin_queue_t ifin;
+   odp_pktout_queue_t ifout;
+};
+
+struct thread_arg_s {
+   uint32_t if_idx;
+};
+
+struct {
+   app_args_t  cmd_args;
+   struct l3fwd_pktio_sl3fwd_pktios[MAX_NB_PKTIO];
+   odph_linux_pthread_tl3fwd_workers[MAX_NB_WORKER];
+   struct thread_arg_s worker_args[MAX_NB_WORKER];
+   uint32_tnb_pktio;  /* effective pktios */
+   uint32_tnb_worker; /* effective workers */
+} global;
+
+static void print_usage(char *progname);
+static void print_info(char *progname, app_args_t *args);
+static void parse_cmdline_args(int argc, char *argv[], app_args_t *args);
+
+static odp_pktio_t create_pktio(const char *name, odp_pool_t pool,
+   odp_pktin_queue_t *pktin,
+   odp_pktout_queue_t *pktout)
+{
+   odp_pktio_param_t pktio_param;
+   odp_pktin_queue_param_t in_queue_param;
+   odp_pktout_queue_param_t out_queue_param;
+   odp_pktio_t pktio;
+
+   odp_pktio_param_init(&pktio_param);
+
+   pktio = odp_pktio_open(name, pool, &pktio_param);
+   if (pktio == ODP_PKTIO_INVALID) {
+   printf("Failed to open %s\n", name);
+   exit(1);
+   }
+
+   odp_pktin_queue_param_init(&in_queue_param);
+   odp_pktout_queue_param_init(&out_queue_param);
+
+   in_queue_param.op_mode = ODP_PKTIO_OP_MT_UNSAFE;
+
+   if (odp_pktin_queue_config(pktio, &in_queue_param)) {
+   printf("Failed to config input queue for %s\n", name);
+   exit(1);
+   }
+
+   out_queue_param.op_mode = ODP_PKTIO_OP_MT_UNSAFE;
+
+   if (odp_pktout_queue_config(pktio, &out_queue_param)) {
+   printf("Failed to config output queue for %s\n", name);
+   exit(1);
+   }
+
+   if (odp_pktin_queue(pktio, pktin, 1) != 1) {
+   printf("pktin queue query failed for %s\n", name);
+   exit(1);
+   }
+   if (odp_pktout_queue(pktio, pktout, 1) != 1) {
+   printf("pktout queue query failed for %s\n", name);
+   exit(1);
+   }
+   return pktio;
+}
+
+static void *run_worker(void *arg)
+{
+   odp_packet_t pkt_tbl[MAX_PKT_BURST];