[lng-odp] [API-NEXT PATCH v2 0/4] Init API and thread type

[Petri Savolainen]

Introduce thread types: worker and control. Implementations may be HW limited
how many worker threads can be supported. Number of control threads may be only 
SW limited.

Note: This series depends on "example: classifier: remove extra local init" 
patch.

v2:
 * Rebased
 * Clean up doxygen documentation in init.h
 * Changed odp_init_global params to const pointer types


Petri Savolainen (4):
  style: init api: documentation clean up
  api: init: use const pointer types
  api: thread: added thread type
  api: init: added thread type to local init

 example/classifier/odp_classifier.c   |  2 +-
 example/generator/odp_generator.c |  2 +-
 example/ipsec/odp_ipsec.c |  2 +-
 example/packet/odp_pktio.c|  2 +-
 example/timer/odp_timer_test.c|  2 +-
 helper/linux.c|  4 +-
 include/odp/api/init.h| 98 ---
 include/odp/api/thread.h  | 38 
 platform/linux-generic/odp_init.c |  6 +-
 test/performance/odp_l2fwd.c  |  2 +-
 test/performance/odp_pktio_perf.c |  2 +-
 test/performance/odp_scheduling.c |  2 +-
 test/validation/common/odp_cunit_common.c |  2 +-
 13 files changed, 104 insertions(+), 60 deletions(-)

-- 
2.4.0

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

[lng-odp] [API-NEXT PATCH v2 1/4] style: init api: documentation clean up

[Petri Savolainen]

Organized doxygen tags and line feeds for better source code
and doxygen doc readabilibty.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/init.h | 92 ++
 1 file changed, 47 insertions(+), 45 deletions(-)

diff --git a/include/odp/api/init.h b/include/odp/api/init.h
index 01faedc..0773567 100644
--- a/include/odp/api/init.h
+++ b/include/odp/api/init.h
@@ -64,8 +64,8 @@ typedef enum odp_log_level {
  * (utilizes function attribute "weak"). If both are defined, the odp_init_t
  * function pointer has priority over the override function.
  *
- * @param[in] level   Log level
- * @param[in] fmt printf-style message format
+ * @param level   Log level
+ * @param fmt printf-style message format
  *
  * @return The number of characters logged on success
  * @retval <0 on failure
@@ -99,107 +99,109 @@ typedef int (*odp_log_func_t)(odp_log_level_e level, 
const char *fmt, ...);
 /** Replaceable abort function */
 typedef void (*odp_abort_func_t)(void) ODP_NORETURN;
 
-/** ODP initialization data.
+/**
+ * ODP initialization data
+ *
  * Data that is required to initialize the ODP API with the
  * application specific data such as specifying a logging callback, the log
  * level etc.
  *
- * @note it is expected that all unassigned members are zero
+ * @note It is expected that all unassigned members are zero
  */
 typedef struct odp_init_t {
odp_log_func_t log_fn; /**< Replacement for the default log fn */
odp_abort_func_t abort_fn; /**< Replacement for the default abort fn */
 } odp_init_t;
 
-/** ODP platform initialization data.
+/**
+ * ODP platform initialization data
+ *
  * @note ODP API does nothing with this data. It is the underlying
  * implementation that requires it and any data passed here is not portable.
  * It is required that the application takes care of identifying and
  * passing any required platform specific data.
  */
-
 typedef struct odp_platform_init_t {
 } odp_platform_init_t;
 
 
 /**
- * Perform global ODP initialization.
+ * Global ODP initialization
  *
  * This function must be called once before calling any other ODP API
  * functions.
  *
- * @sa odp_term_global()
- * @sa odp_init_local() which is required per thread before use.
- *
- * @param[in] params Those parameters that are interpreted by the ODP API
- * @param[in] platform_params Those parameters that are passed without
- * interpretation by the ODP API to the implementation.
+ * @param params  Those parameters that are interpreted by the ODP API.
+ * @param platform_params Those parameters that are passed without
+ *interpretation by the ODP API to the implementation.
  *
  * @retval 0 on success
  * @retval <0 on failure
+ *
+ * @see odp_term_global()
+ * @see odp_init_local() which is required per thread before use.
  */
 int odp_init_global(odp_init_t *params, odp_platform_init_t *platform_params);
 
 /**
- * Terminate ODP session.
+ * Global ODP termination
  *
  * This function is the final ODP call made when terminating
  * an ODP application in a controlled way. It cannot handle exceptional
- * circumstances.
- * In general it calls the API modules terminate functions in the reverse order
- * to that which the module init functions were called during odp_init_global()
+ * circumstances. In general it calls the API modules terminate functions in
+ * the reverse order to that which the module init functions were called
+ * during odp_init_global().
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
  *
  * @note This function should be called by the last ODP thread. To simplify
  * synchronization between threads odp_term_local() indicates by its return
  * value if it was the last thread.
  *
- * @warning The unwinding of HW resources to allow them to be re used without 
reseting
- * the device is a complex task that the application is expected to coordinate.
- * This api may have  platform dependant implications.
+ * @warning The unwinding of HW resources to allow them to be reused without
+ * reseting the device is a complex task that the application is expected to
+ * coordinate. This api may have platform dependant implications.
  *
- * @sa odp_init_global()
- * @sa odp_term_local() which must have been called prior to this.
- *
- * @retval 0 on success
- * @retval <0 on failure
+ * @see odp_init_global()
+ * @see odp_term_local() which must have been called prior to this.
  */
 int odp_term_global(void);
 
 /**
- * Perform thread local ODP initialization.
+ * Thread local ODP initialization
  *
- * All threads must call this function before calling
- * any other ODP API functions.
- *
- * @sa odp_term_local()
- * @sa odp_init_global() which must have been called prior to this.
+ * All threads must call this function before calling any other ODP API
+ * functions.
  *
  * @retval 0 on success
  * @retval <0 on failure
+ *
+ * @see odp_term_local()
+ * @see odp_init_global() which must have been calle

[lng-odp] [API-NEXT PATCH v2 2/4] api: init: use const pointer types

[Petri Savolainen]

odp_init_global() parameters are only for input, function
won't modify param content.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/init.h| 3 ++-
 platform/linux-generic/odp_init.c | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/odp/api/init.h b/include/odp/api/init.h
index 0773567..c3101d9 100644
--- a/include/odp/api/init.h
+++ b/include/odp/api/init.h
@@ -141,7 +141,8 @@ typedef struct odp_platform_init_t {
  * @see odp_term_global()
  * @see odp_init_local() which is required per thread before use.
  */
-int odp_init_global(odp_init_t *params, odp_platform_init_t *platform_params);
+int odp_init_global(const odp_init_t *params,
+   const odp_platform_init_t *platform_params);
 
 /**
  * Global ODP termination
diff --git a/platform/linux-generic/odp_init.c 
b/platform/linux-generic/odp_init.c
index bf36e68..ab63c3c 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -11,8 +11,8 @@
 
 struct odp_global_data_s odp_global_data;
 
-int odp_init_global(odp_init_t *params,
-   odp_platform_init_t *platform_params ODP_UNUSED)
+int odp_init_global(const odp_init_t *params,
+   const odp_platform_init_t *platform_params ODP_UNUSED)
 {
odp_global_data.log_fn = odp_override_log;
odp_global_data.abort_fn = odp_override_abort;
-- 
2.4.0

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

[lng-odp] [API-NEXT PATCH v2 3/4] api: thread: added thread type

[Petri Savolainen]

Two thread types are defined: worker and control threads. API calls from
a worker thread should be throughput and latency optimized, while the
second one is not so sensitive to call overheads and latency.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/thread.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/odp/api/thread.h b/include/odp/api/thread.h
index a509ef9..89eae2b 100644
--- a/include/odp/api/thread.h
+++ b/include/odp/api/thread.h
@@ -23,6 +23,34 @@ extern "C" {
  */
 
 /**
+ * Thread type
+ */
+typedef enum odp_thread_type_e {
+   /**
+* Worker thread
+*
+* Worker threads do most part of ODP application packet processing.
+* These threads provide high packet and data rates, with low and
+* predictable latency. Typically, worker threads are pinned to isolated
+* CPUs and packets are processed in a run-to-completion loop with very
+* low interference from the operating system.
+*/
+   ODP_THREAD_WORKER = 0,
+
+   /**
+* Control thread
+*
+* Control threads do not participate the main packet flow through the
+* system, but e.g. control or monitor the worker threads, or handle
+* exceptions. These threads may perform general purpose processing,
+* use system calls, share the CPU with other threads and be interrupt
+* driven.
+*/
+   ODP_THREAD_CONTROL
+} odp_thread_type_t;
+
+
+/**
  * Get thread identifier
  *
  * Returns the thread identifier of the current thread. Thread ids range from 0
@@ -47,6 +75,16 @@ int odp_thread_id(void);
 int odp_thread_count(void);
 
 /**
+ * Thread type
+ *
+ * Returns the thread type of the current thread.
+ *
+ * @return Thread type
+ */
+odp_thread_type_t odp_thread_type(void);
+
+
+/**
  * @}
  */
 
-- 
2.4.0

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

[lng-odp] [API-NEXT PATCH v2 4/4] api: init: added thread type to local init

[Petri Savolainen]

User needs to select the thread type (worker or control) of
the initialized thread. Implementation may reserve HW direct access
only to worker threads, while control threads share HW access, etc.

Signed-off-by: Petri Savolainen 
---
 example/classifier/odp_classifier.c   | 2 +-
 example/generator/odp_generator.c | 2 +-
 example/ipsec/odp_ipsec.c | 2 +-
 example/packet/odp_pktio.c| 2 +-
 example/timer/odp_timer_test.c| 2 +-
 helper/linux.c| 4 ++--
 include/odp/api/init.h| 5 -
 platform/linux-generic/odp_init.c | 2 +-
 test/performance/odp_l2fwd.c  | 2 +-
 test/performance/odp_pktio_perf.c | 2 +-
 test/performance/odp_scheduling.c | 2 +-
 test/validation/common/odp_cunit_common.c | 2 +-
 12 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 35d9684..b2f451c 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -382,7 +382,7 @@ int main(int argc, char *argv[])
}
 
/* Init this thread */
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_CONTROL)) {
EXAMPLE_ERR("Error: ODP local init failed.\n");
exit(EXIT_FAILURE);
}
diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 8ae5b29..66b9472 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -599,7 +599,7 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
 
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_CONTROL)) {
EXAMPLE_ERR("Error: ODP local init failed.\n");
exit(EXIT_FAILURE);
}
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index cb8f535..b51f633 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -1160,7 +1160,7 @@ main(int argc, char *argv[])
}
 
/* Init this thread */
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_CONTROL)) {
EXAMPLE_ERR("Error: ODP local init failed.\n");
exit(EXIT_FAILURE);
}
diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
index f08d9f4..17b54b2 100644
--- a/example/packet/odp_pktio.c
+++ b/example/packet/odp_pktio.c
@@ -337,7 +337,7 @@ int main(int argc, char *argv[])
}
 
/* Init this thread */
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_CONTROL)) {
EXAMPLE_ERR("Error: ODP local init failed.\n");
exit(EXIT_FAILURE);
}
diff --git a/example/timer/odp_timer_test.c b/example/timer/odp_timer_test.c
index 526342b..3bca125 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -364,7 +364,7 @@ int main(int argc, char *argv[])
}
 
/* Init this thread. */
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_CONTROL)) {
printf("ODP local init failed.\n");
return -1;
}
diff --git a/helper/linux.c b/helper/linux.c
index be1ea13..7352c76 100644
--- a/helper/linux.c
+++ b/helper/linux.c
@@ -60,7 +60,7 @@ static void *odp_run_start_routine(void *arg)
odp_start_args_t *start_args = arg;
 
/* ODP thread local init */
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_WORKER)) {
ODP_ERR("Local init failed\n");
return NULL;
}
@@ -200,7 +200,7 @@ int odph_linux_process_fork_n(odph_linux_process_t 
*proc_tbl,
return -2;
}
 
-   if (odp_init_local()) {
+   if (odp_init_local(ODP_THREAD_WORKER)) {
ODP_ERR("Local init failed\n");
return -2;
}
diff --git a/include/odp/api/init.h b/include/odp/api/init.h
index c3101d9..ab12a80 100644
--- a/include/odp/api/init.h
+++ b/include/odp/api/init.h
@@ -30,6 +30,7 @@ extern "C" {
 
 #include 
 #include 
+#include 
 
 /** @defgroup odp_initialization ODP INITIALIZATION
  *  Initialisation operations.
@@ -175,13 +176,15 @@ int odp_term_global(void);
  * All threads must call this function before calling any other ODP API
  * functions.
  *
+ * @param thr_type  Thread type
+ *
  * @retval 0 on success
  * @retval <0 on failure
  *
  * @see odp_term_local()
  * @see odp_init_global() which must have been called prior to this.
  */
-int odp_init_local(void);
+int odp_init_local(odp_thread_type_t thr_type);
 
 /**
  * Thread local ODP termination
diff --git a/platform/linux-generic/odp_init.c 
b/platform/linux-generic/odp_init.c
index ab63c3c..48c9bba 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -121,7 +121,7 @@ int odp_term_global(void)
retur

Re: [lng-odp] NUMA aware memory allocation?

[Jerin Jacob]

On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:

> Hi,
> 
> I'm not aware of any such interface, but others with more knowledge can
> comment about it. The ODP-DPDK implementation creates buffer pools on the
> NUMA node where the pool create function were actually called.

current ODP spec is not NUMA aware. We need to have API to support nodes 
enumeration and
explicit node parameter to alloc/free resource from specific node like 
odp_shm_reserve_onnode(node, ...)
and while keeping existing API odp_shm_reserve() allocated on node where the 
current code runs


> 
> Regards,
> 
> Zoli
> 
> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
> >Hi!
> >
> >I just started to test ODP, trying to write my first application, but
> >found a problem: if I want to write NUMA aware code, how should I
> >allocate memory close to a given thread? I mean, I know there is
> >libnuma, but should I use it? I guess not, but I cannot find memory
> >allocation functions in ODP. Is there a function similar to
> >numa_alloc_onnode()?
> >Thanks,
> >
> >Gabor
> >___
> >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

Re: [lng-odp] NUMA aware memory allocation?

[Gábor Sándor Enyedi]

Hi,

Thanks. So, is the workaround for now to start the threads, and do all 
the memory reservation on the thread? And to call odp_shm_reserve() 
instead of simple malloc() calls? Can I use multiple buffer pools, one 
for each thread or interface?

BR,

Gabor

P.s.: Do you know when will this issue in the API be fixed (e.g. in next 
release or whatever)?


On 05/08/2015 09:06 AM, Jerin Jacob wrote:

On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:


Hi,

I'm not aware of any such interface, but others with more knowledge can
comment about it. The ODP-DPDK implementation creates buffer pools on the
NUMA node where the pool create function were actually called.

current ODP spec is not NUMA aware. We need to have API to support nodes 
enumeration and
explicit node parameter to alloc/free resource from specific node like 
odp_shm_reserve_onnode(node, ...)
and while keeping existing API odp_shm_reserve() allocated on node where the 
current code runs



Regards,

Zoli

On 07/05/15 16:32, Gábor Sándor Enyedi wrote:

Hi!

I just started to test ODP, trying to write my first application, but
found a problem: if I want to write NUMA aware code, how should I
allocate memory close to a given thread? I mean, I know there is
libnuma, but should I use it? I guess not, but I cannot find memory
allocation functions in ODP. Is there a function similar to
numa_alloc_onnode()?
Thanks,

Gabor
___
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] [PATCHv5 0/4] IPC

[Maxim Uvarov]

v5: - accounted all comments for previous v4 review.
- do not modify any api function, everything is done inside linux-generic.

Please review that version.

Thank you,
Maxim.


Maxim Uvarov (4):
  linux-generic: zero params for pool create
  api ipc: update ring with shm proc argument
  linux-generic: add ipc pktio support
  ipc: example app

 configure.ac   |   1 +
 example/Makefile.am|   2 +-
 example/ipc/.gitignore |   1 +
 example/ipc/Makefile.am|   7 +
 example/ipc/odp_ipc.c  | 427 +++
 helper/include/odp/helper/ring.h   |   7 +-
 helper/ring.c  |  12 +-
 platform/linux-generic/Makefile.am |   3 +
 .../linux-generic/include/odp_buffer_internal.h|   3 +
 .../linux-generic/include/odp_packet_io_internal.h |  16 +
 .../include/odp_packet_io_ipc_internal.h   |  48 ++
 platform/linux-generic/include/odp_shm_internal.h  |  22 +
 platform/linux-generic/odp_packet_io.c |  19 +-
 platform/linux-generic/odp_packet_io_ipc.c | 603 +
 platform/linux-generic/odp_pool.c  |  23 +-
 platform/linux-generic/odp_schedule.c  |   1 +
 platform/linux-generic/odp_shared_memory.c |  10 +-
 test/validation/odp_queue.c|   1 +
 18 files changed, 1193 insertions(+), 13 deletions(-)
 create mode 100644 example/ipc/.gitignore
 create mode 100644 example/ipc/Makefile.am
 create mode 100644 example/ipc/odp_ipc.c
 create mode 100644 platform/linux-generic/include/odp_packet_io_ipc_internal.h
 create mode 100644 platform/linux-generic/include/odp_shm_internal.h
 create mode 100644 platform/linux-generic/odp_packet_io_ipc.c

-- 
1.9.1

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

[lng-odp] [PATCH 1/4] linux-generic: zero params for pool create

[Maxim Uvarov]

Adding more params to pool create breaks original work.
Make sure that not set params are zero.

Signed-off-by: Maxim Uvarov 
---
 platform/linux-generic/odp_schedule.c | 1 +
 test/validation/odp_queue.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/platform/linux-generic/odp_schedule.c 
b/platform/linux-generic/odp_schedule.c
index 7fe42d7..a63f97a 100644
--- a/platform/linux-generic/odp_schedule.c
+++ b/platform/linux-generic/odp_schedule.c
@@ -123,6 +123,7 @@ int odp_schedule_init_global(void)
 
memset(sched, 0, sizeof(sched_t));
 
+   memset(¶ms, 0, sizeof(params));
params.buf.size  = sizeof(sched_cmd_t);
params.buf.align = 0;
params.buf.num   = NUM_SCHED_CMD;
diff --git a/test/validation/odp_queue.c b/test/validation/odp_queue.c
index 5d47399..4354ce1 100644
--- a/test/validation/odp_queue.c
+++ b/test/validation/odp_queue.c
@@ -18,6 +18,7 @@ static int init_queue_suite(void)
 {
odp_pool_param_t params;
 
+   memset(¶ms, 0, sizeof(params));
params.buf.size  = 0;
params.buf.align = ODP_CACHE_LINE_SIZE;
params.buf.num   = 1024 * 10;
-- 
1.9.1

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

[lng-odp] [PATCH 2/4] api ipc: update ring with shm proc argument

[Maxim Uvarov]

Signed-off-by: Maxim Uvarov 
---
 helper/include/odp/helper/ring.h | 2 ++
 helper/ring.c| 9 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/helper/include/odp/helper/ring.h b/helper/include/odp/helper/ring.h
index 65c32ad..5e640a7 100644
--- a/helper/include/odp/helper/ring.h
+++ b/helper/include/odp/helper/ring.h
@@ -158,6 +158,8 @@ typedef struct odph_ring {
 
 #define ODPH_RING_F_SP_ENQ 0x0001 /* The default enqueue is 
"single-producer".*/
 #define ODPH_RING_F_SC_DEQ 0x0002 /* The default dequeue is 
"single-consumer".*/
+#define ODPH_RING_SHM_PROC 0x0004 /* If set - ring is visible from different
+   processes. Default is thread visible. */
 #define ODPH_RING_QUOT_EXCEED (1 << 31)  /* Quota exceed for burst ops */
 #define ODPH_RING_SZ_MASK  (unsigned)(0x0fff) /* Ring size mask */
 
diff --git a/helper/ring.c b/helper/ring.c
index a24a020..0927a6c 100644
--- a/helper/ring.c
+++ b/helper/ring.c
@@ -159,8 +159,14 @@ odph_ring_create(const char *name, unsigned count, 
unsigned flags)
char ring_name[ODPH_RING_NAMESIZE];
odph_ring_t *r;
size_t ring_size;
+   uint32_t shm_flag;
odp_shm_t shm;
 
+   if (flags & ODPH_RING_SHM_PROC)
+   shm_flag = ODP_SHM_PROC;
+   else
+   shm_flag = 0;
+
/* count must be a power of 2 */
if (!ODP_VAL_IS_POWER_2(count) || (count > ODPH_RING_SZ_MASK)) {
ODP_ERR("Requested size is invalid, must be power of 2, and  do 
not exceed the size limit %u\n",
@@ -173,7 +179,8 @@ odph_ring_create(const char *name, unsigned count, unsigned 
flags)
 
odp_rwlock_write_lock(&qlock);
/* reserve a memory zone for this ring.*/
-   shm = odp_shm_reserve(ring_name, ring_size, ODP_CACHE_LINE_SIZE, 0);
+   shm = odp_shm_reserve(ring_name, ring_size, ODP_CACHE_LINE_SIZE,
+ shm_flag);
 
r = odp_shm_addr(shm);
 
-- 
1.9.1

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

[lng-odp] [PATCH 3/4] linux-generic: add ipc pktio support

[Maxim Uvarov]

Signed-off-by: Maxim Uvarov 
---
 helper/include/odp/helper/ring.h   |   7 +-
 helper/ring.c  |   3 +-
 platform/linux-generic/Makefile.am |   3 +
 .../linux-generic/include/odp_buffer_internal.h|   3 +
 .../linux-generic/include/odp_packet_io_internal.h |  16 +
 .../include/odp_packet_io_ipc_internal.h   |  48 ++
 platform/linux-generic/include/odp_shm_internal.h  |  22 +
 platform/linux-generic/odp_packet_io.c |  19 +-
 platform/linux-generic/odp_packet_io_ipc.c | 603 +
 platform/linux-generic/odp_pool.c  |  23 +-
 platform/linux-generic/odp_shared_memory.c |  10 +-
 11 files changed, 745 insertions(+), 12 deletions(-)
 create mode 100644 platform/linux-generic/include/odp_packet_io_ipc_internal.h
 create mode 100644 platform/linux-generic/include/odp_shm_internal.h
 create mode 100644 platform/linux-generic/odp_packet_io_ipc.c

diff --git a/helper/include/odp/helper/ring.h b/helper/include/odp/helper/ring.h
index 5e640a7..c3c2f6a 100644
--- a/helper/include/odp/helper/ring.h
+++ b/helper/include/odp/helper/ring.h
@@ -156,10 +156,11 @@ typedef struct odph_ring {
 } odph_ring_t;
 
 
-#define ODPH_RING_F_SP_ENQ 0x0001 /* The default enqueue is 
"single-producer".*/
-#define ODPH_RING_F_SC_DEQ 0x0002 /* The default dequeue is 
"single-consumer".*/
-#define ODPH_RING_SHM_PROC 0x0004 /* If set - ring is visible from different
+#define ODPH_RING_F_SP_ENQ (1 << 0) /* The default enqueue is 
"single-producer".*/
+#define ODPH_RING_F_SC_DEQ (1 << 1) /* The default dequeue is 
"single-consumer".*/
+#define ODPH_RING_SHM_PROC (1 << 2) /* If set - ring is visible from different
processes. Default is thread visible. */
+#define ODPH_RING_NO_LIST  (1 << 3) /* Do not link ring to linked list. */
 #define ODPH_RING_QUOT_EXCEED (1 << 31)  /* Quota exceed for burst ops */
 #define ODPH_RING_SZ_MASK  (unsigned)(0x0fff) /* Ring size mask */
 
diff --git a/helper/ring.c b/helper/ring.c
index 0927a6c..54c40cf 100644
--- a/helper/ring.c
+++ b/helper/ring.c
@@ -200,7 +200,8 @@ odph_ring_create(const char *name, unsigned count, unsigned 
flags)
r->prod.tail = 0;
r->cons.tail = 0;
 
-   TAILQ_INSERT_TAIL(&odp_ring_list, r, next);
+   if (!(flags & ODPH_RING_NO_LIST))
+   TAILQ_INSERT_TAIL(&odp_ring_list, r, next);
} else {
ODP_ERR("Cannot reserve memory\n");
}
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 66f0474..4843386 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -120,11 +120,13 @@ noinst_HEADERS = \
  ${top_srcdir}/platform/linux-generic/include/odp_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_io_internal.h \
+ 
${top_srcdir}/platform/linux-generic/include/odp_packet_io_ipc_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_io_queue.h \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_socket.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pool_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_queue_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_schedule_internal.h \
+ 
${top_srcdir}/platform/linux-generic/include/odp_shm_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_spin_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_timer_internal.h \
  ${top_srcdir}/platform/linux-generic/Makefile.inc
@@ -155,6 +157,7 @@ __LIB__libodp_la_SOURCES = \
   odp_packet.c \
   odp_packet_flags.c \
   odp_packet_io.c \
+  odp_packet_io_ipc.c \
   odp_packet_socket.c \
   odp_pool.c \
   odp_queue.c \
diff --git a/platform/linux-generic/include/odp_buffer_internal.h 
b/platform/linux-generic/include/odp_buffer_internal.h
index 3a3d2a2..4ea7c62 100644
--- a/platform/linux-generic/include/odp_buffer_internal.h
+++ b/platform/linux-generic/include/odp_buffer_internal.h
@@ -129,6 +129,9 @@ typedef struct odp_buffer_hdr_t {
size_t   udata_size; /* size of user metadata */
uint32_t segcount;   /* segment count */
uint32_t segsize;/* segment size */
+   /* ipc mapped process can not walk over pointers,
+* offset has to be used */
+   uint64_t ipc_addr_offset[ODP_BUFFER_MAX_SEG];
void 

[lng-odp] [PATCH 4/4] ipc: example app

[Maxim Uvarov]

Simple example app creates one packet i/o to external interface
and one ipc pktio to other process. Then transfer packet from
external interface to other process and back thought ipc queue.

Signed-off-by: Maxim Uvarov 
---
 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/ipc/.gitignore  |   1 +
 example/ipc/Makefile.am |   7 +
 example/ipc/odp_ipc.c   | 427 
 5 files changed, 437 insertions(+), 1 deletion(-)
 create mode 100644 example/ipc/.gitignore
 create mode 100644 example/ipc/Makefile.am
 create mode 100644 example/ipc/odp_ipc.c

diff --git a/configure.ac b/configure.ac
index d20bad2..1ceb922 100644
--- a/configure.ac
+++ b/configure.ac
@@ -274,6 +274,7 @@ AC_CONFIG_FILES([Makefile
 example/Makefile
 example/classifier/Makefile
 example/generator/Makefile
+example/ipc/Makefile
 example/ipsec/Makefile
 example/packet/Makefile
 example/timer/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 353f397..506963f 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = classifier generator ipsec packet timer
+SUBDIRS = classifier generator ipc ipsec packet timer
diff --git a/example/ipc/.gitignore b/example/ipc/.gitignore
new file mode 100644
index 000..963d99d
--- /dev/null
+++ b/example/ipc/.gitignore
@@ -0,0 +1 @@
+odp_ipc
diff --git a/example/ipc/Makefile.am b/example/ipc/Makefile.am
new file mode 100644
index 000..3da9549
--- /dev/null
+++ b/example/ipc/Makefile.am
@@ -0,0 +1,7 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_ipc
+odp_ipc_LDFLAGS = $(AM_LDFLAGS) -static
+odp_ipc_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+dist_odp_ipc_SOURCES = odp_ipc.c
diff --git a/example/ipc/odp_ipc.c b/example/ipc/odp_ipc.c
new file mode 100644
index 000..0ed5442
--- /dev/null
+++ b/example/ipc/odp_ipc.c
@@ -0,0 +1,427 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example odp_ipc.c  ODP IPC test application.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+/** @def SHM_PKT_POOL_SIZE
+ * @brief Size of the shared memory block
+ */
+#define SHM_PKT_POOL_SIZE  (512*2048)
+
+/** @def SHM_PKT_POOL_BUF_SIZE
+ * @brief Buffer size of the packet pool buffer
+ */
+#define SHM_PKT_POOL_BUF_SIZE  1856
+
+/** @def MAX_PKT_BURST
+ * @brief Maximum number of packet bursts
+ */
+#define MAX_PKT_BURST  16
+
+/** 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))
+
+/** Application argument */
+static char *pktio_name;
+
+/* helper funcs */
+static void parse_args(int argc, char *argv[]);
+static void print_info(char *progname);
+static void usage(char *progname);
+
+/**
+ * Create a pktio handle.
+ *
+ * @param dev Name of device to open
+ * @param pool Pool to associate with device for packet RX/TX
+ *
+ * @return The handle of the created pktio object.
+ * @retval ODP_PKTIO_INVALID if the create fails.
+ */
+static odp_pktio_t create_pktio(const char *dev, odp_pool_t pool)
+{
+   odp_pktio_t pktio;
+   odp_pktio_t ipc_pktio;
+
+   /* Open a packet IO instance */
+   pktio = odp_pktio_open(dev, pool);
+   if (pktio == ODP_PKTIO_INVALID)
+   EXAMPLE_ABORT("Error: pktio create failed for %s\n", dev);
+
+   printf("pid: %d, create IPC pktio\n", getpid());
+   ipc_pktio = odp_pktio_open("ipc_pktio", pool);
+   if (ipc_pktio == ODP_PKTIO_INVALID)
+   EXAMPLE_ABORT("Error: ipc pktio create failed.\n");
+
+   return pktio;
+}
+
+/**
+ * Packet IO loopback worker thread using bursts from/to IO resources
+ *
+ * @param arg  thread arguments of type 'thread_args_t *'
+ */
+static void *pktio_run_loop(odp_pool_t pool)
+{
+   int thr;
+   odp_pktio_t pktio;
+   int pkts;
+   odp_packet_t pkt_tbl[MAX_PKT_BURST];
+   odp_pktio_t ipc_pktio;
+   thr = odp_thread_id();
+
+   pktio = odp_pktio_lookup(pktio_name);
+   if (pktio == ODP_PKTIO_INVALID) {
+   EXAMPLE_ERR("  [%02i] Error: lookup of pktio %s failed\n",
+   thr, pktio_name);
+   return NULL;
+   }
+
+   printf("  [%02i] looked up pktio:%02" PRIu64 ", burst mode\n",
+  thr, odp_pktio_to_u64(pktio));
+
+   ipc_pktio = odp_pktio_lookup("ipc_pktio");
+   if (pktio == ODP_PKTIO_INVALID) {
+   EXAMPLE_ERR("  [%02i] Error: lookup of pktio %s failed\n",
+   thr, "ipc_pktio");
+   return NULL;
+   }
+   printf("  [%02i] looked up ipc_pktio:%02" PRIu64 ", burst mode\n",
+  thr, odp_pktio_to_u64(ipc_pkti

Re: [lng-odp] squash or not to squash....

[Maxim Uvarov]

On 05/08/2015 01:15, Anders Roxell wrote:

On 2015-05-07 16:26, Bill Fischofer wrote:

On Thu, May 7, 2015 at 11:50 AM, Maxim Uvarov 
wrote:


Here I have patches from api-next needed to be merged to master:


https://git.linaro.org/people/maxim.uvarov/odp.git/shortlog/refs/heads/api-next

There are 4 commits:
5f9b8df example: classifier: remove odp_pmr_create_range() support
dab82ac validation: remove test case for odp_pmr_create_range() function
3bd420c api: classification: remove odp_pmr_create_range() function
definition.
088cea5 linux-generic: classification: remove odp_pmr_create_range()
function implementation.


The only thing wrong I see with this sequence is the removal of the API
should be last, so reverse the order of patches 3 and 4.

That wont work, because the patches don't do what it stats its doing in
the commit log...

For instance: api: classification: remove odp_pmr_create_range() function 
definition

Don't lie there, however, it does a lot more e.g., remove
odp_pmr_create_match() and add odp_pmr_create() function


What we should have done would be to add a first api patch that adds the
new api + implementation for that and then build the 4 patches on that.

For this specific case we can either look the other way and hope we will
never need to do git bisect below this point, squash the patchset or
revert it and redo the patchset.


Cheers,
Anders

Ok, I'm going to squash them if nobody needs that separate commit.

Maxim.






Which breaks git bisect.  So I'm thinking what is better to do here merge
them to one commit or
leave as is.

pros for not squash to 1 patch:
+ logic split patches from api, validation and example easy for post merge
review.

cons for not squash to 1 patch:
- not git bisect command friendly, but commits grouped and followed one by
one.
So that git bisect --skip can avoid this block;


pros to squash to 1 patch:
+ git bisect friendly;

cons to squash to 1 patch:
-  one monster patch.

For now I think it's better to not squash that commits to single commit.
Any ideas what is better to do in that case?
I think we should define somewhere that such separation for api patches &
tests are acceptable.

Thanks,
Maxim.




___
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

Re: [lng-odp] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Maxim Uvarov]

v2 patch is ok, going to apply it if no more objections.

Maxim.


On 05/07/2015 15:38, Mike Holmes wrote:

Signed-off-by: Mike Holmes 
---

V2
Reduce the number fo files touched.

  platform/Makefile.inc |  4 
  platform/linux-generic/odp_impl.c | 14 --
  scripts/git_hash.sh   |  9 +
  3 files changed, 25 insertions(+), 2 deletions(-)
  create mode 100755 scripts/git_hash.sh

diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 9e73fc4..4000d64 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -11,3 +11,7 @@ VPATH = $(srcdir) $(builddir)
  lib_LTLIBRARIES = $(LIB)/libodp.la
  
  AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'

+
+GIT_DESC !=$(top_builddir)/scripts/git_hash.sh
+AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
+AM_CFLAGS += -DPLATFORM=${with_platform}
diff --git a/platform/linux-generic/odp_impl.c 
b/platform/linux-generic/odp_impl.c
index ca3224d..46d0e40 100644
--- a/platform/linux-generic/odp_impl.c
+++ b/platform/linux-generic/odp_impl.c
@@ -20,8 +20,18 @@ extern "C" {
  
  #include 
  
-#define  ODP_VERSION_IMPL 0

-#define  ODP_VERSION_IMPL_STR ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
+#define ODP_VERSION_IMPL 0
+#define ODP_VERSION_IMPL_STR \
+   ODP_VERSION_TO_STR(PLATFORM) " " \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
+   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
+   __DATE__ " " __TIME__ " " \
+   ODP_VERSION_TO_STR(GIT_HASH)
  
  const char *odp_version_impl_str(void)

  {
diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
new file mode 100755
index 000..c9f1faf
--- /dev/null
+++ b/scripts/git_hash.sh
@@ -0,0 +1,9 @@
+#!/bin/bash
+
+repo=https://git.linaro.org/lng/odp.git
+hash=$(git describe | tr -d "\n")
+if git diff-index --name-only HEAD &>/dev/null ; then
+   dirty=-dirty
+fi
+
+echo -n "'${repo}' (${hash}${dirty})"


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

Re: [lng-odp] [PATCH v2] example: timer: remove global variables to share the data between workers

[Maxim Uvarov]

Took this patch, will be merged now.

Maxim.

On 05/08/2015 09:50, Jerin Jacob wrote:

On Wed, Apr 29, 2015 at 03:49:06PM -0400, Mike Holmes wrote:

On 27 April 2015 at 12:19, Jerin Jacob 
wrote:


use the odp_shared_memory allocater instead of global variables to enable
the timer example to run on baremetal/linux process execution environments

Signed-off-by: Jerin Jacob 


Reviewed-and-tested-by: Mike Holmes 

Ping..




---

Changes in v2
- rebased
- added an error check for odp_shm_reserve()

  example/timer/odp_timer_test.c | 128
++---
  1 file changed, 69 insertions(+), 59 deletions(-)

diff --git a/example/timer/odp_timer_test.c
b/example/timer/odp_timer_test.c
index 526342b..5e4306e 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -33,18 +33,21 @@ typedef struct {
 int tmo_count; /**< Timeout count*/
  } test_args_t;

-
-/** @private Barrier for test synchronisation */
-static odp_barrier_t test_barrier;
-
-/** @private Pool handle */
-static odp_pool_t pool;
-
-/** @private Timer pool handle */
-static odp_timer_pool_t tp;
-
-/** @private Number of timeouts to receive */
-static odp_atomic_u32_t remain;
+/** @private Helper struct for timers */
+struct test_timer {
+   odp_timer_t tim;
+   odp_event_t ev;
+};
+
+/** Test global variables */
+typedef struct {
+   test_args_t args;   /**< Test argunments*/
+   odp_barrier_t test_barrier; /**< Barrier for test
synchronisation*/
+   odp_pool_t pool;/**< pool handle*/
+   odp_timer_pool_t tp;/**< Timer pool handle*/
+   odp_atomic_u32_t remain;/**< Number of timeouts to
receive*/
+   struct test_timer tt[256];  /**< Array of all timer helper
structs*/
+} test_globals_t;

  /** @private Timer set status ASCII strings */
  static const char *timerset2str(odp_timer_set_t val)
@@ -63,14 +66,6 @@ static const char *timerset2str(odp_timer_set_t val)
 }
  };

-/** @private Helper struct for timers */
-struct test_timer {
-   odp_timer_t tim;
-   odp_event_t ev;
-};
-
-/** @private Array of all timer helper structs */
-static struct test_timer tt[256];

  /** @private test timeout */
  static void free_event(odp_event_t ev)
@@ -108,7 +103,7 @@ static void remove_prescheduled_events(void)
  }

  /** @private test timeout */
-static void test_abs_timeouts(int thr, test_args_t *args)
+static void test_abs_timeouts(int thr, test_globals_t *gbls)
  {
 uint64_t period;
 uint64_t period_ns;
@@ -121,30 +116,30 @@ static void test_abs_timeouts(int thr, test_args_t
*args)

 queue = odp_queue_lookup("timer_queue");

-   period_ns = args->period_us*ODP_TIME_USEC;
-   period= odp_timer_ns_to_tick(tp, period_ns);
+   period_ns = gbls->args.period_us*ODP_TIME_USEC;
+   period= odp_timer_ns_to_tick(gbls->tp, period_ns);

 EXAMPLE_DBG("  [%i] period %"PRIu64" ticks,  %"PRIu64" ns\n", thr,
 period, period_ns);

 EXAMPLE_DBG("  [%i] current tick %"PRIu64"\n", thr,
-   odp_timer_current_tick(tp));
+   odp_timer_current_tick(gbls->tp));

-   ttp = &tt[thr - 1]; /* Thread starts at 1 */
-   ttp->tim = odp_timer_alloc(tp, queue, ttp);
+   ttp = &gbls->tt[thr];
+   ttp->tim = odp_timer_alloc(gbls->tp, queue, ttp);
 if (ttp->tim == ODP_TIMER_INVALID) {
 EXAMPLE_ERR("Failed to allocate timer\n");
 return;
 }
-   tmo = odp_timeout_alloc(pool);
+   tmo = odp_timeout_alloc(gbls->pool);
 if (tmo == ODP_TIMEOUT_INVALID) {
 EXAMPLE_ERR("Failed to allocate timeout\n");
 return;
 }
 ttp->ev = odp_timeout_to_event(tmo);
-   tick = odp_timer_current_tick(tp);
+   tick = odp_timer_current_tick(gbls->tp);

-   while ((int)odp_atomic_load_u32(&remain) > 0) {
+   while ((int)odp_atomic_load_u32(&gbls->remain) > 0) {
 odp_event_t ev;
 odp_timer_set_t rc;

@@ -169,7 +164,7 @@ static void test_abs_timeouts(int thr, test_args_t
*args)
 /* Check if odp_schedule() timed out, possibly
there
  * are no remaining timeouts to receive */
 } while (ev == ODP_EVENT_INVALID &&
-(int)odp_atomic_load_u32(&remain) > 0);
+(int)odp_atomic_load_u32(&gbls->remain) > 0);

 if (ev == ODP_EVENT_INVALID)
 break; /* No more timeouts */
@@ -190,7 +185,7 @@ static void test_abs_timeouts(int thr, test_args_t
*args)
 }
 EXAMPLE_DBG("  [%i] timeout, tick %"PRIu64"\n", thr, tick);

-   odp_atomic_dec_u32(&remain);
+   odp_atomic_dec_u32(&gbls->remain);
 }

 /* Cancel and free last timer used */
@@ -219,9 +214,9 @@ static void *run_thread(vo

[lng-odp] [PATCH] update version number from v1.0.4 to v1.1.0

[Maxim Uvarov]

Signed-off-by: Maxim Uvarov 
---
 debian/changelog  | 30 ++
 include/odp/api/version.h |  4 ++--
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c6c0ec8..ee4dd3d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+opendataplane (1.1.0-1) unstable; urgency=low
+   * API:
+   - style: moved pool type first in pool_param
+   - style: pool_param doxygen comments
+   - api: packet: removed odp_packet_user_u64
+   - api: packet: rename user_data to user_area
+   - api: pktio: Clarify doc on default pool usage on odp_pktio_open
+   - timer: Add missing platform handles to u64 conversion functions
+   - api/linux-generic/example/validation: remove odp_pmr_create_range() 
function definition
+   - api: packet: relax return code to use non-zero for true
+   - api: packet/pool: proposed APIs for packet user metadata
+
+   * test:
+   * validation:
+   - validation: packet: add user metadata tests
+   - test: pktio: add missing atomic init
+   - test: use CU_ASSERT_FATAL in case odp_buffer_alloc failed to 
avoid segfaults
+   - validation: pktio: fix polling tests
+   - validation: tests for module odp_ver_abt_log_dbg
+   - validation: rename executable to match modules
+   * general:
+   - linux-generic/odp_impl: add implementation version details
+   - linux-generic: support running with restricted cpu set
+   - linux-generic: packet: add user metadata support
+   - linux-generic: pool: add user metadata support
+   - linux-generic: buffer: restructure user mdatadata fields
+   - linux-generic: use inttypes defines to print (u)int32_t values
+
+ -- Maxim Uvarov   Fri, 08 May 2015 13:35:16 +0300
+
 opendataplane (1.0.4-1) unstable; urgency=low
 
* test:
diff --git a/include/odp/api/version.h b/include/odp/api/version.h
index 027095d..5d1abfa 100644
--- a/include/odp/api/version.h
+++ b/include/odp/api/version.h
@@ -37,7 +37,7 @@ extern "C" {
  * Introduction of major new features or changes. APIs with different major
  * versions are likely not backward compatible.
  */
-#define ODP_VERSION_API_MAJOR 0
+#define ODP_VERSION_API_MAJOR 1
 
 /**
  * ODP API minor version
@@ -46,7 +46,7 @@ extern "C" {
  * to the API. For an API with common generation and major version, but with
  * different minor numbers the two versions are backward compatible.
  */
-#define ODP_VERSION_API_MINOR 4
+#define ODP_VERSION_API_MINOR 0
 
 /**
  * Returns ODP API version string
-- 
1.9.1

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

Re: [lng-odp] [API-NEXT PATCH v3 0/5] Packet IO API additions

[Maxim Uvarov]

Merged to api-next,
Maxim.


On 05/07/2015 12:55, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Ping.

"api: packet_io: added parse mode" can be left out for now, others should be OK 
to merge.


-Petri



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
Petri Savolainen
Sent: Tuesday, May 05, 2015 4:12 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 0/5] Packet IO API additions


Reviewed-by: Robbie King 


v3:
  * rebased
  * removed two empty lines

v2:
  * removed "selected" parse option


Petri Savolainen (5):
   api: packet_io: change word instance to interface
   api: packet_io: remove excess references to ODP
   api: packet_io: added odp_pktio_param_t
   api: packet_io: added parse mode
   api: packet_io: added start and stop

  example/classifier/odp_classifier.c|   6 +-
  example/generator/odp_generator.c  |   6 +-
  example/ipsec/odp_ipsec.c  |  11 ++-
  example/packet/odp_pktio.c |  19 +++-
  include/odp/api/packet_io.h| 100
-
  .../linux-generic/include/odp_packet_io_internal.h |   1 +
  platform/linux-generic/odp_packet_io.c |  10 ++-
  test/performance/odp_l2fwd.c   |  10 ++-
  test/performance/odp_pktio_perf.c  |  27 --
  .../classification/odp_classification_tests.c  |   6 +-
  test/validation/odp_pktio.c|  41 ++---
  11 files changed, 189 insertions(+), 48 deletions(-)

--
2.4.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


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

Re: [lng-odp] Query regarding sequence number update in IPSEC application

[Bill Fischofer]

Jerrin,

Can you propose such a set of APIs for further discussion?  This would be
good to discuss at the Tuesday call.

Thanks.

Bill

On Fri, May 8, 2015 at 12:07 AM, Jacob, Jerin <
jerin.ja...@caviumnetworks.com> wrote:

>
> I agree with Ola here on preserving the ingress order.
> However, I have experienced same performance issue as Nikhil pointed out
> (atomic queues have too much overhead for short critical section)
>
> I am not sure about any other HW but Cavium has support for
> introducing the critical section while maintain the ingress order as a HW
> scheduler feature.
>
> IMO, if such support is available in other HW then
> odp_schedule_ordered_lock()/unlock()
> kind of API will solve the performance issue for the need for short
> critical section in ordered flow.
>
> /Jerin.
>
>
> From: lng-odp  on behalf of Ola
> Liljedahl 
> Sent: Thursday, May 7, 2015 9:06 PM
> To: nikhil.agar...@freescale.com
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Query regarding sequence number update in IPSEC
> application
>
>
> Using atomic queues will preserve the ingress order when allocating and
> assigning the sequence number. Also you don't need to use an expensive
> atomic operation for updating the sequence number as the atomic queue and
> scheduling will provide mutual  exclusion.
>
>
> If the packets that require a sequence number came from parallel or
> ordered queues, there would be no guarantee that the sequence numbers would
> be allocated in packet (ingress) order. Just using an atomic operation
> (e.g. fetch_and_add or similar) only  guarantees proper update of the
> sequence number variable, not any specific ordering.
>
>
> If you are ready to trade absolute "correctness" for performance, you
> could use ordered or may even parallel (questionable for other reasons)
> queues and then allocate the sequence number using an atomic fetch_and_add.
> Sometimes packets  egress order will then not match the sequence number
> order (for a flow/SA). For IPSec, this might affect the replay window check
> & update at the receiving end but as the replay protection uses a sliding
> window of sequence numbers (to handle misordered packets),  there might not
> be any adverse effects in practice. The most important aspect is probably
> to preserve original packet order.
>
>
> -- Ola
>
>
> On 6 May 2015 at 11:29,  nikhil.agar...@freescale.com <
> nikhil.agar...@freescale.com> wrote:
>
>
> Hi,
>
> In IPSEC example application, queues are used to update the sequence
> number. I was wondering why we have used queues to update sequence number
> which will add to scheduling delays and adversely hit the performance
> throughput. Is there any  specific advantage of using queues over atomic
> variables.
>
> Thanks in advance
>  Nikhil
>
>
> ___
> 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

Re: [lng-odp] NUMA aware memory allocation?

[Mike Holmes]

Gabor

If you have a proposal for the API, 1.2 is scheduled for the end of this
quarter. It may be sooner if there is sufficient content so that is the
soonest it could change.

Please propose a header file change in api-next to start the discussion to
solve your need.

Mike

On 8 May 2015 at 03:48, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

> Hi,
>
> Thanks. So, is the workaround for now to start the threads, and do all the
> memory reservation on the thread? And to call odp_shm_reserve() instead of
> simple malloc() calls? Can I use multiple buffer pools, one for each thread
> or interface?
> BR,
>
> Gabor
>
> P.s.: Do you know when will this issue in the API be fixed (e.g. in next
> release or whatever)?
>
>
> On 05/08/2015 09:06 AM, Jerin Jacob wrote:
>
>> On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
>>
>>  Hi,
>>>
>>> I'm not aware of any such interface, but others with more knowledge can
>>> comment about it. The ODP-DPDK implementation creates buffer pools on the
>>> NUMA node where the pool create function were actually called.
>>>
>> current ODP spec is not NUMA aware. We need to have API to support nodes
>> enumeration and
>> explicit node parameter to alloc/free resource from specific node like
>> odp_shm_reserve_onnode(node, ...)
>> and while keeping existing API odp_shm_reserve() allocated on node where
>> the current code runs
>>
>>
>>  Regards,
>>>
>>> Zoli
>>>
>>> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
>>>
 Hi!

 I just started to test ODP, trying to write my first application, but
 found a problem: if I want to write NUMA aware code, how should I
 allocate memory close to a given thread? I mean, I know there is
 libnuma, but should I use it? I guess not, but I cannot find memory
 allocation functions in ODP. Is there a function similar to
 numa_alloc_onnode()?
 Thanks,

 Gabor
 ___
 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
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] NUMA aware memory allocation?

[Bill Fischofer]

We should discuss how to approach NUMA considerations in the context of ODP
APIs as a general design question rather than adding them ad hoc to each
API as questions arise.  Perhaps we should add this to our architecture
calls as a topic for the next few weeks to see how we can flesh this out?
We may also have time to expand on this as part of the June Sprint.

Bill

On Fri, May 8, 2015 at 6:58 AM, Mike Holmes  wrote:

> Gabor
>
> If you have a proposal for the API, 1.2 is scheduled for the end of this
> quarter. It may be sooner if there is sufficient content so that is the
> soonest it could change.
>
> Please propose a header file change in api-next to start the discussion to
> solve your need.
>
> Mike
>
> On 8 May 2015 at 03:48, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
>> Hi,
>>
>> Thanks. So, is the workaround for now to start the threads, and do all
>> the memory reservation on the thread? And to call odp_shm_reserve() instead
>> of simple malloc() calls? Can I use multiple buffer pools, one for each
>> thread or interface?
>> BR,
>>
>> Gabor
>>
>> P.s.: Do you know when will this issue in the API be fixed (e.g. in next
>> release or whatever)?
>>
>>
>> On 05/08/2015 09:06 AM, Jerin Jacob wrote:
>>
>>> On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
>>>
>>>  Hi,

 I'm not aware of any such interface, but others with more knowledge can
 comment about it. The ODP-DPDK implementation creates buffer pools on
 the
 NUMA node where the pool create function were actually called.

>>> current ODP spec is not NUMA aware. We need to have API to support nodes
>>> enumeration and
>>> explicit node parameter to alloc/free resource from specific node like
>>> odp_shm_reserve_onnode(node, ...)
>>> and while keeping existing API odp_shm_reserve() allocated on node where
>>> the current code runs
>>>
>>>
>>>  Regards,

 Zoli

 On 07/05/15 16:32, Gábor Sándor Enyedi wrote:

> Hi!
>
> I just started to test ODP, trying to write my first application, but
> found a problem: if I want to write NUMA aware code, how should I
> allocate memory close to a given thread? I mean, I know there is
> libnuma, but should I use it? I guess not, but I cannot find memory
> allocation functions in ODP. Is there a function similar to
> numa_alloc_onnode()?
> Thanks,
>
> Gabor
> ___
> 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
>>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
>
>
>
> ___
> 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] [API-NEXT PATCH v2 0/4] Init API and thread type

[Bill Fischofer]

This patch series doesn't seem to do anything besides lay the groundwork
for some future patch series.  Without seeing that other series it's
difficult to review this one.

On Fri, May 8, 2015 at 2:07 AM, Petri Savolainen  wrote:

> Introduce thread types: worker and control. Implementations may be HW
> limited
> how many worker threads can be supported. Number of control threads may be
> only
> SW limited.
>
> Note: This series depends on "example: classifier: remove extra local init"
> patch.
>
> v2:
>  * Rebased
>  * Clean up doxygen documentation in init.h
>  * Changed odp_init_global params to const pointer types
>
>
> Petri Savolainen (4):
>   style: init api: documentation clean up
>   api: init: use const pointer types
>   api: thread: added thread type
>   api: init: added thread type to local init
>
>  example/classifier/odp_classifier.c   |  2 +-
>  example/generator/odp_generator.c |  2 +-
>  example/ipsec/odp_ipsec.c |  2 +-
>  example/packet/odp_pktio.c|  2 +-
>  example/timer/odp_timer_test.c|  2 +-
>  helper/linux.c|  4 +-
>  include/odp/api/init.h| 98
> ---
>  include/odp/api/thread.h  | 38 
>  platform/linux-generic/odp_init.c |  6 +-
>  test/performance/odp_l2fwd.c  |  2 +-
>  test/performance/odp_pktio_perf.c |  2 +-
>  test/performance/odp_scheduling.c |  2 +-
>  test/validation/common/odp_cunit_common.c |  2 +-
>  13 files changed, 104 insertions(+), 60 deletions(-)
>
> --
> 2.4.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 v2] linux-generic/odp_impl: add implementation version details

[Mike Holmes]

I think we may have made a mistake.

We need a way to indicate linux-generic changes that do not in any way
touch the API given that linux-generic and the API are released together.
We have that information already it is the version digit that was returned
by odp_version_api_str()

and
was set to 0

We should be releasing 1.1.0-0 right now, and when we make a point release
that in no way touches the API will will release maybe 1.1.0-1.  However we
just re-purposed odp_version_api_str()

from
returning that "1" to a string that is good for debug logs.

I think we need a new API for the verbose string.

odp_version_api_str

= 1.1.0
odp_version_api_str()

= 0  << revert this to its old purpose

odp_version_description_str()

<< add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)




On 8 May 2015 at 06:20, Maxim Uvarov  wrote:

> v2 patch is ok, going to apply it if no more objections.
>
> Maxim.
>
>
>
> On 05/07/2015 15:38, Mike Holmes wrote:
>
>> Signed-off-by: Mike Holmes 
>> ---
>>
>> V2
>> Reduce the number fo files touched.
>>
>>   platform/Makefile.inc |  4 
>>   platform/linux-generic/odp_impl.c | 14 --
>>   scripts/git_hash.sh   |  9 +
>>   3 files changed, 25 insertions(+), 2 deletions(-)
>>   create mode 100755 scripts/git_hash.sh
>>
>> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
>> index 9e73fc4..4000d64 100644
>> --- a/platform/Makefile.inc
>> +++ b/platform/Makefile.inc
>> @@ -11,3 +11,7 @@ VPATH = $(srcdir) $(builddir)
>>   lib_LTLIBRARIES = $(LIB)/libodp.la
>> AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
>> +
>> +GIT_DESC !=$(top_builddir)/scripts/git_hash.sh
>> +AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
>> +AM_CFLAGS += -DPLATFORM=${with_platform}
>> diff --git a/platform/linux-generic/odp_impl.c
>> b/platform/linux-generic/odp_impl.c
>> index ca3224d..46d0e40 100644
>> --- a/platform/linux-generic/odp_impl.c
>> +++ b/platform/linux-generic/odp_impl.c
>> @@ -20,8 +20,18 @@ extern "C" {
>> #include 
>>   -#define  ODP_VERSION_IMPL 0
>> -#define  ODP_VERSION_IMPL_STR ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
>> +#define ODP_VERSION_IMPL 0
>> +#define ODP_VERSION_IMPL_STR \
>> +   ODP_VERSION_TO_STR(PLATFORM) " " \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
>> +   __DATE__ " " __TIME__ " " \
>> +   ODP_VERSION_TO_STR(GIT_HASH)
>> const char *odp_version_impl_str(void)
>>   {
>> diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
>> new file mode 100755
>> index 000..c9f1faf
>> --- /dev/null
>> +++ b/scripts/git_hash.sh
>> @@ -0,0 +1,9 @@
>> +#!/bin/bash
>> +
>> +repo=https://git.linaro.org/lng/odp.git
>> +hash=$(git describe | tr -d "\n")
>> +if git diff-index --name-only HEAD &>/dev/null ; then
>> +   dirty=-dirty
>> +fi
>> +
>> +echo -n "'${repo}' (${hash}${dirty})"
>>
>
> ___
> 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
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Mike Holmes]

sorry paste failed me insert odp_version_impl_str

However we just re-purposed odp_version_impl_str  from returning that "1"
to a string that is good for debug logs.

odp_version_impl_str  = 0  << revert this to its old purpose

On 8 May 2015 at 08:38, Mike Holmes  wrote:

> I think we may have made a mistake.
>
> We need a way to indicate linux-generic changes that do not in any way
> touch the API given that linux-generic and the API are released together.
> We have that information already it is the version digit that was returned
> by odp_version_api_str()
> 
>  and
> was set to 0
>
> We should be releasing 1.1.0-0 right now, and when we make a point release
> that in no way touches the API will will release maybe 1.1.0-1.  However we
> just re-purposed odp_version_api_str()
> 
>  from
> returning that "1" to a string that is good for debug logs.
>
> I think we need a new API for the verbose string.
>
> odp_version_api_str
> 
> = 1.1.0
> odp_version_api_str()
> 
> = 0  << revert this to its old purpose
>
> odp_version_description_str()
> 
> << add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
> https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)
>
>
>
>
> On 8 May 2015 at 06:20, Maxim Uvarov  wrote:
>
>> v2 patch is ok, going to apply it if no more objections.
>>
>> Maxim.
>>
>>
>>
>> On 05/07/2015 15:38, Mike Holmes wrote:
>>
>>> Signed-off-by: Mike Holmes 
>>> ---
>>>
>>> V2
>>> Reduce the number fo files touched.
>>>
>>>   platform/Makefile.inc |  4 
>>>   platform/linux-generic/odp_impl.c | 14 --
>>>   scripts/git_hash.sh   |  9 +
>>>   3 files changed, 25 insertions(+), 2 deletions(-)
>>>   create mode 100755 scripts/git_hash.sh
>>>
>>> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
>>> index 9e73fc4..4000d64 100644
>>> --- a/platform/Makefile.inc
>>> +++ b/platform/Makefile.inc
>>> @@ -11,3 +11,7 @@ VPATH = $(srcdir) $(builddir)
>>>   lib_LTLIBRARIES = $(LIB)/libodp.la
>>> AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
>>> +
>>> +GIT_DESC !=$(top_builddir)/scripts/git_hash.sh
>>> +AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
>>> +AM_CFLAGS += -DPLATFORM=${with_platform}
>>> diff --git a/platform/linux-generic/odp_impl.c
>>> b/platform/linux-generic/odp_impl.c
>>> index ca3224d..46d0e40 100644
>>> --- a/platform/linux-generic/odp_impl.c
>>> +++ b/platform/linux-generic/odp_impl.c
>>> @@ -20,8 +20,18 @@ extern "C" {
>>> #include 
>>>   -#define  ODP_VERSION_IMPL 0
>>> -#define  ODP_VERSION_IMPL_STR ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
>>> +#define ODP_VERSION_IMPL 0
>>> +#define ODP_VERSION_IMPL_STR \
>>> +   ODP_VERSION_TO_STR(PLATFORM) " " \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
>>> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
>>> +   __DATE__ " " __TIME__ " " \
>>> +   ODP_VERSION_TO_STR(GIT_HASH)
>>> const char *odp_version_impl_str(void)
>>>   {
>>> diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
>>> new file mode 100755
>>> index 000..c9f1faf
>>> --- /dev/null
>>> +++ b/scripts/git_hash.sh
>>> @@ -0,0 +1,9 @@
>>> +#!/bin/bash
>>> +
>>> +repo=https://git.linaro.org/lng/odp.git
>>> +hash=$(git describe | tr -d "\n")
>>> +if git diff-index --name-only HEAD &>/dev/null ; then
>>> +   dirty=-dirty
>>> +fi
>>> +
>>> +echo -n "'${repo}' (${hash}${dirty})"
>>>
>>
>> ___
>> 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
>
>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Bill Fischofer]

I guess the question is:

1. Who was using these?
2. How do we intend for them to be used going forward?

If we can answer those questions then any needed "course correction" should
be clearer.

On Fri, May 8, 2015 at 7:40 AM, Mike Holmes  wrote:

> sorry paste failed me insert odp_version_impl_str
>
> However we just re-purposed odp_version_impl_str  from returning that "1"
> to a string that is good for debug logs.
>
> odp_version_impl_str  = 0  << revert this to its old purpose
>
> On 8 May 2015 at 08:38, Mike Holmes  wrote:
>
>> I think we may have made a mistake.
>>
>> We need a way to indicate linux-generic changes that do not in any way
>> touch the API given that linux-generic and the API are released together.
>> We have that information already it is the version digit that was
>> returned by odp_version_api_str()
>> 
>>  and
>> was set to 0
>>
>> We should be releasing 1.1.0-0 right now, and when we make a point
>> release that in no way touches the API will will release maybe 1.1.0-1.
>> However we just re-purposed odp_version_api_str()
>> 
>>  from
>> returning that "1" to a string that is good for debug logs.
>>
>> I think we need a new API for the verbose string.
>>
>> odp_version_api_str
>> 
>> = 1.1.0
>> odp_version_api_str()
>> 
>> = 0  << revert this to its old purpose
>>
>> odp_version_description_str()
>> 
>> << add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
>> https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)
>>
>>
>>
>>
>> On 8 May 2015 at 06:20, Maxim Uvarov  wrote:
>>
>>> v2 patch is ok, going to apply it if no more objections.
>>>
>>> Maxim.
>>>
>>>
>>>
>>> On 05/07/2015 15:38, Mike Holmes wrote:
>>>
 Signed-off-by: Mike Holmes 
 ---

 V2
 Reduce the number fo files touched.

   platform/Makefile.inc |  4 
   platform/linux-generic/odp_impl.c | 14 --
   scripts/git_hash.sh   |  9 +
   3 files changed, 25 insertions(+), 2 deletions(-)
   create mode 100755 scripts/git_hash.sh

 diff --git a/platform/Makefile.inc b/platform/Makefile.inc
 index 9e73fc4..4000d64 100644
 --- a/platform/Makefile.inc
 +++ b/platform/Makefile.inc
 @@ -11,3 +11,7 @@ VPATH = $(srcdir) $(builddir)
   lib_LTLIBRARIES = $(LIB)/libodp.la
 AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
 +
 +GIT_DESC !=$(top_builddir)/scripts/git_hash.sh
 +AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
 +AM_CFLAGS += -DPLATFORM=${with_platform}
 diff --git a/platform/linux-generic/odp_impl.c
 b/platform/linux-generic/odp_impl.c
 index ca3224d..46d0e40 100644
 --- a/platform/linux-generic/odp_impl.c
 +++ b/platform/linux-generic/odp_impl.c
 @@ -20,8 +20,18 @@ extern "C" {
 #include 
   -#define  ODP_VERSION_IMPL 0
 -#define  ODP_VERSION_IMPL_STR ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
 +#define ODP_VERSION_IMPL 0
 +#define ODP_VERSION_IMPL_STR \
 +   ODP_VERSION_TO_STR(PLATFORM) " " \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
 +   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
 +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
 +   __DATE__ " " __TIME__ " " \
 +   ODP_VERSION_TO_STR(GIT_HASH)
 const char *odp_version_impl_str(void)
   {
 diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
 new file mode 100755
 index 000..c9f1faf
 --- /dev/null
 +++ b/scripts/git_hash.sh
 @@ -0,0 +1,9 @@
 +#!/bin/bash
 +
 +repo=https://git.linaro.org/lng/odp.git
 +hash=$(git describe | tr -d "\n")
 +if git diff-index --name-only HEAD &>/dev/null ; then
 +   dirty=-dirty
 +fi
 +
 +echo -n "'${repo}' (${hash}${dirty})"

>>>
>>> ___
>>> 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 so

Re: [lng-odp] NUMA aware memory allocation?

[Mike Holmes]

On 8 May 2015 at 08:14, Bill Fischofer  wrote:

> We should discuss how to approach NUMA considerations in the context of
> ODP APIs as a general design question rather than adding them ad hoc to
> each API as questions arise.
>

Absolutely.

Perhaps we should add this to our architecture calls as a topic for the
> next few weeks to see how we can flesh this out?
>

I agree, if we have some one driving the need, but there is no point
talking theoretically and solving it in the abstract.
I think we have learned that without the drive of someone solving a problem
they have, we never close on the issue. The successful API work has
involved a real problem and a header file proposal to focus the discussion.


> We may also have time to expand on this as part of the June Sprint.
>

Agree, but again we need some thing to anchor the discussion. A sprints
purpose is to focus on solving specif problems, we can discuss generally in
HOs and on the list I think.
With a proposal that outlines the issues to be solved (not starting a
general discussion) I am in favor of adding it to the agenda.


>
> Bill
>
> On Fri, May 8, 2015 at 6:58 AM, Mike Holmes 
> wrote:
>
>> Gabor
>>
>> If you have a proposal for the API, 1.2 is scheduled for the end of this
>> quarter. It may be sooner if there is sufficient content so that is the
>> soonest it could change.
>>
>> Please propose a header file change in api-next to start the discussion
>> to solve your need.
>>
>> Mike
>>
>> On 8 May 2015 at 03:48, Gábor Sándor Enyedi <
>> gabor.sandor.eny...@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>> Thanks. So, is the workaround for now to start the threads, and do all
>>> the memory reservation on the thread? And to call odp_shm_reserve() instead
>>> of simple malloc() calls? Can I use multiple buffer pools, one for each
>>> thread or interface?
>>> BR,
>>>
>>> Gabor
>>>
>>> P.s.: Do you know when will this issue in the API be fixed (e.g. in next
>>> release or whatever)?
>>>
>>>
>>> On 05/08/2015 09:06 AM, Jerin Jacob wrote:
>>>
 On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:

  Hi,
>
> I'm not aware of any such interface, but others with more knowledge can
> comment about it. The ODP-DPDK implementation creates buffer pools on
> the
> NUMA node where the pool create function were actually called.
>
 current ODP spec is not NUMA aware. We need to have API to support
 nodes enumeration and
 explicit node parameter to alloc/free resource from specific node like
 odp_shm_reserve_onnode(node, ...)
 and while keeping existing API odp_shm_reserve() allocated on node
 where the current code runs


  Regards,
>
> Zoli
>
> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
>
>> Hi!
>>
>> I just started to test ODP, trying to write my first application, but
>> found a problem: if I want to write NUMA aware code, how should I
>> allocate memory close to a given thread? I mean, I know there is
>> libnuma, but should I use it? I guess not, but I cannot find memory
>> allocation functions in ODP. Is there a function similar to
>> numa_alloc_onnode()?
>> Thanks,
>>
>> Gabor
>> ___
>> 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
>>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org  *│ *Open source software for ARM SoCs
>>
>>
>>
>> ___
>> 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
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] NUMA aware memory allocation?

[Bill Fischofer]

I think a good place to start would be to define what, if any, additional
odp_pool attributes need to be added to the odp_pool_params_t struct to
capture NUMA considerations.  I should also point out that the reason we
had map/unmap calls on the buffer/packet API discussions last year was in
consideration of NUMA.  We may or may not wish to revisit these.

It would also seem that this needs to tie into the thread restructure work
that Petri is doing for defining control and worker threads.  So lots of
angles to explore.

On Fri, May 8, 2015 at 7:53 AM, Mike Holmes  wrote:

>
>
> On 8 May 2015 at 08:14, Bill Fischofer  wrote:
>
>> We should discuss how to approach NUMA considerations in the context of
>> ODP APIs as a general design question rather than adding them ad hoc to
>> each API as questions arise.
>>
>
> Absolutely.
>
> Perhaps we should add this to our architecture calls as a topic for the
>> next few weeks to see how we can flesh this out?
>>
>
> I agree, if we have some one driving the need, but there is no point
> talking theoretically and solving it in the abstract.
> I think we have learned that without the drive of someone solving a
> problem they have, we never close on the issue. The successful API work has
> involved a real problem and a header file proposal to focus the discussion.
>
>
>> We may also have time to expand on this as part of the June Sprint.
>>
>
> Agree, but again we need some thing to anchor the discussion. A sprints
> purpose is to focus on solving specif problems, we can discuss generally in
> HOs and on the list I think.
> With a proposal that outlines the issues to be solved (not starting a
> general discussion) I am in favor of adding it to the agenda.
>
>
>>
>> Bill
>>
>> On Fri, May 8, 2015 at 6:58 AM, Mike Holmes 
>> wrote:
>>
>>> Gabor
>>>
>>> If you have a proposal for the API, 1.2 is scheduled for the end of this
>>> quarter. It may be sooner if there is sufficient content so that is the
>>> soonest it could change.
>>>
>>> Please propose a header file change in api-next to start the discussion
>>> to solve your need.
>>>
>>> Mike
>>>
>>> On 8 May 2015 at 03:48, Gábor Sándor Enyedi <
>>> gabor.sandor.eny...@ericsson.com> wrote:
>>>
 Hi,

 Thanks. So, is the workaround for now to start the threads, and do all
 the memory reservation on the thread? And to call odp_shm_reserve() instead
 of simple malloc() calls? Can I use multiple buffer pools, one for each
 thread or interface?
 BR,

 Gabor

 P.s.: Do you know when will this issue in the API be fixed (e.g. in
 next release or whatever)?


 On 05/08/2015 09:06 AM, Jerin Jacob wrote:

> On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
>
>  Hi,
>>
>> I'm not aware of any such interface, but others with more knowledge
>> can
>> comment about it. The ODP-DPDK implementation creates buffer pools on
>> the
>> NUMA node where the pool create function were actually called.
>>
> current ODP spec is not NUMA aware. We need to have API to support
> nodes enumeration and
> explicit node parameter to alloc/free resource from specific node like
> odp_shm_reserve_onnode(node, ...)
> and while keeping existing API odp_shm_reserve() allocated on node
> where the current code runs
>
>
>  Regards,
>>
>> Zoli
>>
>> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
>>
>>> Hi!
>>>
>>> I just started to test ODP, trying to write my first application, but
>>> found a problem: if I want to write NUMA aware code, how should I
>>> allocate memory close to a given thread? I mean, I know there is
>>> libnuma, but should I use it? I guess not, but I cannot find memory
>>> allocation functions in ODP. Is there a function similar to
>>> numa_alloc_onnode()?
>>> Thanks,
>>>
>>> Gabor
>>> ___
>>> 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

>>>
>>>
>>>
>>> --
>>> Mike Holmes
>>> Technical Manager - Linaro Networking Group
>>> Linaro.org  *│ *Open source software for ARM
>>> SoCs
>>>
>>>
>>>
>>> ___
>>> 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
>
>
>

Re: [lng-odp] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Mike Holmes]

On 8 May 2015 at 08:47, Bill Fischofer  wrote:

> I guess the question is:
>
> 1. Who was using these?
>

Applications want to know the implementation and API versions, I think that
was the driver to adding the APIs originally and I think that remains true.
Certainly the patch as it stands subverts the original APIs intention of
indicating just the implementation revision level.


> 2. How do we intend for them to be used going forward?
>

Original APIs for the version remain as originally intended, the new API
makes debugging and identification of the code in use much easier



>
> If we can answer those questions then any needed "course correction"
> should be clearer.
>

> On Fri, May 8, 2015 at 7:40 AM, Mike Holmes 
> wrote:
>
>> sorry paste failed me insert odp_version_impl_str
>>
>> However we just re-purposed odp_version_impl_str  from returning that
>> "1" to a string that is good for debug logs.
>>
>> odp_version_impl_str  = 0  << revert this to its old purpose
>>
>> On 8 May 2015 at 08:38, Mike Holmes  wrote:
>>
>>> I think we may have made a mistake.
>>>
>>> We need a way to indicate linux-generic changes that do not in any way
>>> touch the API given that linux-generic and the API are released together.
>>> We have that information already it is the version digit that was
>>> returned by odp_version_api_str()
>>> 
>>>  and
>>> was set to 0
>>>
>>> We should be releasing 1.1.0-0 right now, and when we make a point
>>> release that in no way touches the API will will release maybe 1.1.0-1.
>>> However we just re-purposed odp_version_api_str()
>>> 
>>>  from
>>> returning that "1" to a string that is good for debug logs.
>>>
>>> I think we need a new API for the verbose string.
>>>
>>> odp_version_api_str
>>> 
>>> = 1.1.0
>>> odp_version_api_str()
>>> 
>>> = 0  << revert this to its old purpose
>>>
>>> odp_version_description_str()
>>> 
>>> << add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
>>> https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)
>>>
>>>
>>>
>>>
>>> On 8 May 2015 at 06:20, Maxim Uvarov  wrote:
>>>
 v2 patch is ok, going to apply it if no more objections.

 Maxim.



 On 05/07/2015 15:38, Mike Holmes wrote:

> Signed-off-by: Mike Holmes 
> ---
>
> V2
> Reduce the number fo files touched.
>
>   platform/Makefile.inc |  4 
>   platform/linux-generic/odp_impl.c | 14 --
>   scripts/git_hash.sh   |  9 +
>   3 files changed, 25 insertions(+), 2 deletions(-)
>   create mode 100755 scripts/git_hash.sh
>
> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
> index 9e73fc4..4000d64 100644
> --- a/platform/Makefile.inc
> +++ b/platform/Makefile.inc
> @@ -11,3 +11,7 @@ VPATH = $(srcdir) $(builddir)
>   lib_LTLIBRARIES = $(LIB)/libodp.la
> AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
> +
> +GIT_DESC !=$(top_builddir)/scripts/git_hash.sh
> +AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
> +AM_CFLAGS += -DPLATFORM=${with_platform}
> diff --git a/platform/linux-generic/odp_impl.c
> b/platform/linux-generic/odp_impl.c
> index ca3224d..46d0e40 100644
> --- a/platform/linux-generic/odp_impl.c
> +++ b/platform/linux-generic/odp_impl.c
> @@ -20,8 +20,18 @@ extern "C" {
> #include 
>   -#define  ODP_VERSION_IMPL 0
> -#define  ODP_VERSION_IMPL_STR ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
> +#define ODP_VERSION_IMPL 0
> +#define ODP_VERSION_IMPL_STR \
> +   ODP_VERSION_TO_STR(PLATFORM) " " \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
> +   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
> +   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
> +   __DATE__ " " __TIME__ " " \
> +   ODP_VERSION_TO_STR(GIT_HASH)
> const char *odp_version_impl_str(void)
>   {
> diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
> new file mode 100755
> index 000..c9f1faf
> --- /dev/null
> +++ b/s

Re: [lng-odp] NUMA aware memory allocation?

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

Hi,

ODP is OS agnostic and thus thread management (e.g. thread creation and pinning 
to physical cores) and NUMA awareness should happen mostly outside of ODP APIs.

For example, NUMA could be visible in ODP APIs this way:
* Add odp_cpumask_xxx() calls that indicate NUMA dependency between CPUs (just 
for information)
* Add a way to identify groups of threads which frequently share resources 
(memory and handles) within the group
* Give the thread group as a hint (parameter) to various ODP calls that create 
shared resources. Implementation can use the information to allocate resources 
"near" to the threads in the group. However, the user is responsible to group 
the threads and map/pin those into physical CPUs in a way that enables NUMA 
aware optimizations.


-Petri
 


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Gábor Sándor Enyedi
> Sent: Friday, May 08, 2015 10:48 AM
> To: Jerin Jacob; Zoltan Kiss
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] NUMA aware memory allocation?
> 
> Hi,
> 
> Thanks. So, is the workaround for now to start the threads, and do all
> the memory reservation on the thread? And to call odp_shm_reserve()
> instead of simple malloc() calls? Can I use multiple buffer pools, one
> for each thread or interface?
> BR,
> 
> Gabor
> 
> P.s.: Do you know when will this issue in the API be fixed (e.g. in next
> release or whatever)?
> 
> On 05/08/2015 09:06 AM, Jerin Jacob wrote:
> > On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
> >
> >> Hi,
> >>
> >> I'm not aware of any such interface, but others with more knowledge can
> >> comment about it. The ODP-DPDK implementation creates buffer pools on
> the
> >> NUMA node where the pool create function were actually called.
> > current ODP spec is not NUMA aware. We need to have API to support nodes
> enumeration and
> > explicit node parameter to alloc/free resource from specific node like
> odp_shm_reserve_onnode(node, ...)
> > and while keeping existing API odp_shm_reserve() allocated on node where
> the current code runs
> >
> >
> >> Regards,
> >>
> >> Zoli
> >>
> >> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
> >>> Hi!
> >>>
> >>> I just started to test ODP, trying to write my first application, but
> >>> found a problem: if I want to write NUMA aware code, how should I
> >>> allocate memory close to a given thread? I mean, I know there is
> >>> libnuma, but should I use it? I guess not, but I cannot find memory
> >>> allocation functions in ODP. Is there a function similar to
> >>> numa_alloc_onnode()?
> >>> Thanks,
> >>>
> >>> Gabor
> >>> ___
> >>> 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] NUMA aware memory allocation?

[Bill Fischofer]

Insofar as possible, the mechanics of NUMA should be the responsibility of
the ODP implementation, rather than the application, since that way the
application retains maximum portability.

However, from an ODP API perspective, I think we need to be mindful of NUMA
considerations to give implementations the necessary "hooks" to properly
support the NUMA aspects of their platform.  This is why ODP APIs need to
be careful about what addressability assumptions they make.

If Gábor or Jerrin can list a couple of specific relevant cases I think
that will help in focusing the discussion and get us off to a good start.

On Fri, May 8, 2015 at 8:26 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Hi,
>
> ODP is OS agnostic and thus thread management (e.g. thread creation and
> pinning to physical cores) and NUMA awareness should happen mostly outside
> of ODP APIs.
>
> For example, NUMA could be visible in ODP APIs this way:
> * Add odp_cpumask_xxx() calls that indicate NUMA dependency between CPUs
> (just for information)
> * Add a way to identify groups of threads which frequently share resources
> (memory and handles) within the group
> * Give the thread group as a hint (parameter) to various ODP calls that
> create shared resources. Implementation can use the information to allocate
> resources "near" to the threads in the group. However, the user is
> responsible to group the threads and map/pin those into physical CPUs in a
> way that enables NUMA aware optimizations.
>
>
> -Petri
>
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> > Gábor Sándor Enyedi
> > Sent: Friday, May 08, 2015 10:48 AM
> > To: Jerin Jacob; Zoltan Kiss
> > Cc: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] NUMA aware memory allocation?
> >
> > Hi,
> >
> > Thanks. So, is the workaround for now to start the threads, and do all
> > the memory reservation on the thread? And to call odp_shm_reserve()
> > instead of simple malloc() calls? Can I use multiple buffer pools, one
> > for each thread or interface?
> > BR,
> >
> > Gabor
> >
> > P.s.: Do you know when will this issue in the API be fixed (e.g. in next
> > release or whatever)?
> >
> > On 05/08/2015 09:06 AM, Jerin Jacob wrote:
> > > On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm not aware of any such interface, but others with more knowledge
> can
> > >> comment about it. The ODP-DPDK implementation creates buffer pools on
> > the
> > >> NUMA node where the pool create function were actually called.
> > > current ODP spec is not NUMA aware. We need to have API to support
> nodes
> > enumeration and
> > > explicit node parameter to alloc/free resource from specific node like
> > odp_shm_reserve_onnode(node, ...)
> > > and while keeping existing API odp_shm_reserve() allocated on node
> where
> > the current code runs
> > >
> > >
> > >> Regards,
> > >>
> > >> Zoli
> > >>
> > >> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
> > >>> Hi!
> > >>>
> > >>> I just started to test ODP, trying to write my first application, but
> > >>> found a problem: if I want to write NUMA aware code, how should I
> > >>> allocate memory close to a given thread? I mean, I know there is
> > >>> libnuma, but should I use it? I guess not, but I cannot find memory
> > >>> allocation functions in ODP. Is there a function similar to
> > >>> numa_alloc_onnode()?
> > >>> Thanks,
> > >>>
> > >>> Gabor
> > >>> ___
> > >>> 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 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 v2] linux-generic/odp_impl: add implementation version details

[Stuart Haslam]

On Fri, May 08, 2015 at 08:40:39AM -0400, Mike Holmes wrote:
> sorry paste failed me insert odp_version_impl_str
> 
> However we just re-purposed odp_version_impl_str  from returning that "1"
> to a string that is good for debug logs.
> 
> odp_version_impl_str  = 0  << revert this to its old purpose

Wouldn't it make sense for this function to return a string that
matches the name of the tag that gets applied for releases that change
the implementation and not the API?.. surely that won't be "0"

By the way, looking at bugzilla it seems we're using the API version for
all ODP bugs, but most of them are actually with the implementation.

> 
> On 8 May 2015 at 08:38, Mike Holmes  wrote:
> 
> > I think we may have made a mistake.
> >
> > We need a way to indicate linux-generic changes that do not in any way
> > touch the API given that linux-generic and the API are released together.
> > We have that information already it is the version digit that was returned
> > by odp_version_api_str()
> > 
> >  and
> > was set to 0
> >
> > We should be releasing 1.1.0-0 right now, and when we make a point release
> > that in no way touches the API will will release maybe 1.1.0-1.  However we
> > just re-purposed odp_version_api_str()
> > 
> >  from
> > returning that "1" to a string that is good for debug logs.
> >
> > I think we need a new API for the verbose string.
> >
> > odp_version_api_str
> > 
> > = 1.1.0
> > odp_version_api_str()
> > 
> > = 0  << revert this to its old purpose
> >
> > odp_version_description_str()
> > 
> > << add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
> > https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)
> >

Makes sense to me, though I would name this odp_version_str().

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

Re: [lng-odp] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Mike Holmes]

On 8 May 2015 at 09:37, Stuart Haslam  wrote:

> On Fri, May 08, 2015 at 08:40:39AM -0400, Mike Holmes wrote:
> > sorry paste failed me insert odp_version_impl_str
> >
> > However we just re-purposed odp_version_impl_str  from returning that "1"
> > to a string that is good for debug logs.
> >
> > odp_version_impl_str  = 0  << revert this to its old purpose
>
> Wouldn't it make sense for this function to return a string that
> matches the name of the tag that gets applied for releases that change
> the implementation and not the API?.. surely that won't be "0"
>

We did start with this solution concatenating the api number and an
implementation number only. For this next release it would be 1.1.0.0  and
the tag in the repo should be v1.1.0.0  so I think you are suggesting the
original proposal. For a  non API change if it happened right after 1.1 it
becomes 1.1.0.1


>
> By the way, looking at bugzilla it seems we're using the API version for
> all ODP bugs, but most of them are actually with the implementation.
>

Agree, that is what started the discussion and then resulted in this patch.


>
> >
> > On 8 May 2015 at 08:38, Mike Holmes  wrote:
> >
> > > I think we may have made a mistake.
> > >
> > > We need a way to indicate linux-generic changes that do not in any way
> > > touch the API given that linux-generic and the API are released
> together.
> > > We have that information already it is the version digit that was
> returned
> > > by odp_version_api_str()
> > > <
> http://docs.opendataplane.org/linux-generic-doxygen-html/group__odp__ver__abt__log__dbg.html#ga36ea138f559454eee62c343107947cb6>
> and
> > > was set to 0
> > >
> > > We should be releasing 1.1.0-0 right now, and when we make a point
> release
> > > that in no way touches the API will will release maybe 1.1.0-1.
> However we
> > > just re-purposed odp_version_api_str()
> > > <
> http://docs.opendataplane.org/linux-generic-doxygen-html/group__odp__ver__abt__log__dbg.html#ga36ea138f559454eee62c343107947cb6>
> from
> > > returning that "1" to a string that is good for debug logs.
> > >
> > > I think we need a new API for the verbose string.
> > >
> > > odp_version_api_str
> > > <
> http://docs.opendataplane.org/linux-generic-doxygen-html/group__odp__ver__abt__log__dbg.html#ga36ea138f559454eee62c343107947cb6
> >
> > > = 1.1.0
> > > odp_version_api_str()
> > > <
> http://docs.opendataplane.org/linux-generic-doxygen-html/group__odp__ver__abt__log__dbg.html#ga36ea138f559454eee62c343107947cb6
> >
> > > = 0  << revert this to its old purpose
> > >
> > > odp_version_description_str()
> > > <
> http://docs.opendataplane.org/linux-generic-doxygen-html/group__odp__ver__abt__log__dbg.html#ga36ea138f559454eee62c343107947cb6
> >
> > > << add this  =  linux-generic 1.0.4-0 (v1.0.4) May  8 2015 07:34:05 '
> > > https://git.linaro.org/lng/odp.git' (v1.0.4-22-g9a02ee4-dirty)
> > >
>
> Makes sense to me, though I would name this odp_version_str().
>

I like it, agree and will make that change if we go this route.


>
> --
> Stuart.
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] NUMA aware memory allocation?

[Gábor Sándor Enyedi]

For me and for now the use-case is very simple: we have an x86 with two 
Xeon CPU-s (dual socket) in it. Each of the CPU-s have its own memory 
and own PCIExpress bus, as usual. First, I want to make only some test 
code, but later we may want to port our high speed OF soft switch to ODP 
(now, its on DPDK). We want to assign a correct core for each interface, 
and each slot must use its own copy of forwarding data in its own 
memory. We have the experience that if we accidentally assigned a bad 
core to an interface, we could get even about 50% performance drop, so 
NUMA is essential.
Based on the previous, for us something similar to that used in DPDK's 
rte_malloc (and its variants) and a NUMA aware buffer pool create was 
enough for now. Later we want to investigate other architectures... but 
I don't know the use-cases yet.


Gabor



On 05/08/2015 03:35 PM, Bill Fischofer wrote:
Insofar as possible, the mechanics of NUMA should be the 
responsibility of the ODP implementation, rather than the application, 
since that way the application retains maximum portability.


However, from an ODP API perspective, I think we need to be mindful of 
NUMA considerations to give implementations the necessary "hooks" to 
properly support the NUMA aspects of their platform.  This is why ODP 
APIs need to be careful about what addressability assumptions they make.


If Gábor or Jerrin can list a couple of specific relevant cases I 
think that will help in focusing the discussion and get us off to a 
good start.


On Fri, May 8, 2015 at 8:26 AM, Savolainen, Petri (Nokia - FI/Espoo) 
mailto:petri.savolai...@nokia.com>> wrote:


Hi,

ODP is OS agnostic and thus thread management (e.g. thread
creation and pinning to physical cores) and NUMA awareness should
happen mostly outside of ODP APIs.

For example, NUMA could be visible in ODP APIs this way:
* Add odp_cpumask_xxx() calls that indicate NUMA dependency
between CPUs (just for information)
* Add a way to identify groups of threads which frequently share
resources (memory and handles) within the group
* Give the thread group as a hint (parameter) to various ODP calls
that create shared resources. Implementation can use the
information to allocate resources "near" to the threads in the
group. However, the user is responsible to group the threads and
map/pin those into physical CPUs in a way that enables NUMA aware
optimizations.


-Petri



> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
] On Behalf Of ext
> Gábor Sándor Enyedi
> Sent: Friday, May 08, 2015 10:48 AM
> To: Jerin Jacob; Zoltan Kiss
> Cc: lng-odp@lists.linaro.org 
> Subject: Re: [lng-odp] NUMA aware memory allocation?
>
> Hi,
>
> Thanks. So, is the workaround for now to start the threads, and
do all
> the memory reservation on the thread? And to call odp_shm_reserve()
> instead of simple malloc() calls? Can I use multiple buffer
pools, one
> for each thread or interface?
> BR,
>
> Gabor
>
> P.s.: Do you know when will this issue in the API be fixed (e.g.
in next
> release or whatever)?
>
> On 05/08/2015 09:06 AM, Jerin Jacob wrote:
> > On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
> >
> >> Hi,
> >>
> >> I'm not aware of any such interface, but others with more
knowledge can
> >> comment about it. The ODP-DPDK implementation creates buffer
pools on
> the
> >> NUMA node where the pool create function were actually called.
> > current ODP spec is not NUMA aware. We need to have API to
support nodes
> enumeration and
> > explicit node parameter to alloc/free resource from specific
node like
> odp_shm_reserve_onnode(node, ...)
> > and while keeping existing API odp_shm_reserve() allocated on
node where
> the current code runs
> >
> >
> >> Regards,
> >>
> >> Zoli
> >>
> >> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
> >>> Hi!
> >>>
> >>> I just started to test ODP, trying to write my first
application, but
> >>> found a problem: if I want to write NUMA aware code, how
should I
> >>> allocate memory close to a given thread? I mean, I know there is
> >>> libnuma, but should I use it? I guess not, but I cannot find
memory
> >>> allocation functions in ODP. Is there a function similar to
> >>> numa_alloc_onnode()?
> >>> Thanks,
> >>>
> >>> Gabor
> >>> ___
> >>> lng-odp mailing list
> >>> lng-odp@lists.linaro.org 
> >>> https://lists.linaro.org/mailman/listinfo/lng-odp
> >> ___
> >> lng-odp mailing list
> >> lng-odp@lists.l

[lng-odp] Fwd: [PATCH 1/1 v1] helpers: fix udp checksum computation

[Alexandru Badicioiu]

Ping.

-- Forwarded message --
From: 
Date: 5 May 2015 at 15:07
Subject: [lng-odp][PATCH 1/1 v1] helpers: fix udp checksum computation
To: lng-odp@lists.linaro.org
Cc: Alexandru Badicioiu 


From: Alexandru Badicioiu 

v1 - fixed compile error due to -Wcast-align

Signed-off-by: Alexandru Badicioiu 
---
 helper/include/odp/helper/udp.h |   37
+
 1 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/helper/include/odp/helper/udp.h
b/helper/include/odp/helper/udp.h
index 99a96f2..d14cbef 100644
--- a/helper/include/odp/helper/udp.h
+++ b/helper/include/odp/helper/udp.h
@@ -33,15 +33,6 @@ typedef struct ODP_PACKED {
uint16be_t chksum;   /**< UDP header and data checksum (0 if not
used)*/
 } odph_udphdr_t;

-/** UDP pseudo header */
-typedef struct ODPH_PACKET {
-   uint32be_t src_addr; /**< Source addr */
-   uint32be_t dst_addr; /**< Destination addr */
-   uint8_t pad; /**< pad byte */
-   uint8_t proto;   /**< UDP protocol */
-   uint16be_t length;   /**< data length */
-} odph_udpphdr_t;
-
 /**
  * UDP checksum
  *
@@ -53,10 +44,10 @@ typedef struct ODPH_PACKET {
 static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
 {
uint32_t sum = 0;
-   odph_udpphdr_t phdr;
odph_udphdr_t *udph;
odph_ipv4hdr_t *iph;
uint16_t udplen;
+   uint8_t *buf;

if (!odp_packet_l3_offset(pkt))
return 0;
@@ -68,24 +59,22 @@ static inline uint16_t
odph_ipv4_udp_chksum(odp_packet_t pkt)
udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
udplen = odp_be_to_cpu_16(udph->length);

-   /* the source ip */
-   phdr.src_addr = iph->src_addr;
-   /* the dest ip */
-   phdr.dst_addr = iph->dst_addr;
-   /* proto */
-   phdr.pad = 0;
-   phdr.proto = ODPH_IPPROTO_UDP;
-   /* the length */
-   phdr.length = udph->length;
-
-   /* calc UDP pseudo header chksum */
-   sum = (__odp_force uint32_t) odp_chksum(&phdr,
sizeof(odph_udpphdr_t));
-   /* calc udp header and data chksum */
-   sum += (__odp_force uint32_t) odp_chksum(udph, udplen);
+   /* 32-bit sum of all 16-bit words covered by UDP chksum */
+   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
+ (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
+ (uint16_t) iph->proto + udplen;
+   for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
+   sum += ((*buf << 8) + *(buf + 1));
+   buf += 2;
+   }

/* Fold sum to 16 bits: add carrier to result */
while (sum >> 16)
sum = (sum & 0x) + (sum >> 16);
+
+   /* 1's complement */
+   sum = ~sum;
+
/* set computation result */
sum = (sum == 0x0) ? 0x : sum;

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

Re: [lng-odp] NUMA aware memory allocation?

[Bill Fischofer]

Thanks, that's good info. So in this case is it sufficient to say that the
memory used for odp_pool_create() is the one associated with the thread
that executes the create call?  Presumably then when a packet arrives and
is assigned to a CoS that points to that pool then events from that pool
are sent to queues that are only scheduled to the corresponding cores that
have fast access to that pool.  Right now queues have an
odp_schedule_group_t but that's still fairly rudimentary.  It sounds like
we might want to point the queue at the pool for scheduling purposes so
that it would inherit the NUMA considerations you mention.

On Fri, May 8, 2015 at 9:00 AM, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

>  For me and for now the use-case is very simple: we have an x86 with two
> Xeon CPU-s (dual socket) in it. Each of the CPU-s have its own memory and
> own PCIExpress bus, as usual. First, I want to make only some test code,
> but later we may want to port our high speed OF soft switch to ODP (now,
> its on DPDK). We want to assign a correct core for each interface, and each
> slot must use its own copy of forwarding data in its own memory. We have
> the experience that if we accidentally assigned a bad core to an interface,
> we could get even about 50% performance drop, so NUMA is essential.
> Based on the previous, for us something similar to that used in DPDK's
> rte_malloc (and its variants) and a NUMA aware buffer pool create was
> enough for now. Later we want to investigate other architectures... but I
> don't know the use-cases yet.
>
> Gabor
>
>
>
>
> On 05/08/2015 03:35 PM, Bill Fischofer wrote:
>
> Insofar as possible, the mechanics of NUMA should be the responsibility of
> the ODP implementation, rather than the application, since that way the
> application retains maximum portability.
>
>  However, from an ODP API perspective, I think we need to be mindful of
> NUMA considerations to give implementations the necessary "hooks" to
> properly support the NUMA aspects of their platform.  This is why ODP APIs
> need to be careful about what addressability assumptions they make.
>
>  If Gábor or Jerrin can list a couple of specific relevant cases I think
> that will help in focusing the discussion and get us off to a good start.
>
> On Fri, May 8, 2015 at 8:26 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>> Hi,
>>
>> ODP is OS agnostic and thus thread management (e.g. thread creation and
>> pinning to physical cores) and NUMA awareness should happen mostly outside
>> of ODP APIs.
>>
>> For example, NUMA could be visible in ODP APIs this way:
>> * Add odp_cpumask_xxx() calls that indicate NUMA dependency between CPUs
>> (just for information)
>> * Add a way to identify groups of threads which frequently share
>> resources (memory and handles) within the group
>> * Give the thread group as a hint (parameter) to various ODP calls that
>> create shared resources. Implementation can use the information to allocate
>> resources "near" to the threads in the group. However, the user is
>> responsible to group the threads and map/pin those into physical CPUs in a
>> way that enables NUMA aware optimizations.
>>
>>
>> -Petri
>>
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> ext
>> > Gábor Sándor Enyedi
>> > Sent: Friday, May 08, 2015 10:48 AM
>> > To: Jerin Jacob; Zoltan Kiss
>> > Cc: lng-odp@lists.linaro.org
>> > Subject: Re: [lng-odp] NUMA aware memory allocation?
>> >
>> > Hi,
>> >
>> > Thanks. So, is the workaround for now to start the threads, and do all
>> > the memory reservation on the thread? And to call odp_shm_reserve()
>> > instead of simple malloc() calls? Can I use multiple buffer pools, one
>> > for each thread or interface?
>> > BR,
>> >
>> > Gabor
>> >
>> > P.s.: Do you know when will this issue in the API be fixed (e.g. in next
>> > release or whatever)?
>> >
>> > On 05/08/2015 09:06 AM, Jerin Jacob wrote:
>> > > On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I'm not aware of any such interface, but others with more knowledge
>> can
>> > >> comment about it. The ODP-DPDK implementation creates buffer pools on
>> > the
>> > >> NUMA node where the pool create function were actually called.
>> > > current ODP spec is not NUMA aware. We need to have API to support
>> nodes
>> > enumeration and
>> > > explicit node parameter to alloc/free resource from specific node like
>> > odp_shm_reserve_onnode(node, ...)
>> > > and while keeping existing API odp_shm_reserve() allocated on node
>> where
>> > the current code runs
>> > >
>> > >
>> > >> Regards,
>> > >>
>> > >> Zoli
>> > >>
>> > >> On 07/05/15 16:32, Gábor Sándor Enyedi wrote:
>> > >>> Hi!
>> > >>>
>> > >>> I just started to test ODP, trying to write my first application,
>> but
>> > >>> found a problem: if I want to write NUMA aware code, how should I
>> > >>> allocate memory 

Re: [lng-odp] Fwd: [PATCH 1/1 v1] helpers: fix udp checksum computation

[Bill Fischofer]

If we're going to fix this, it should be a complete fix.  This seems to be
tied to IPv4 and it should support IPv6 as well.

On Fri, May 8, 2015 at 9:02 AM, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:

> Ping.
>
> -- Forwarded message --
> From: 
> Date: 5 May 2015 at 15:07
> Subject: [lng-odp][PATCH 1/1 v1] helpers: fix udp checksum computation
> To: lng-odp@lists.linaro.org
> Cc: Alexandru Badicioiu 
>
>
> From: Alexandru Badicioiu 
>
> v1 - fixed compile error due to -Wcast-align
>
> Signed-off-by: Alexandru Badicioiu 
> ---
>  helper/include/odp/helper/udp.h |   37
> +
>  1 files changed, 13 insertions(+), 24 deletions(-)
>
> diff --git a/helper/include/odp/helper/udp.h
> b/helper/include/odp/helper/udp.h
> index 99a96f2..d14cbef 100644
> --- a/helper/include/odp/helper/udp.h
> +++ b/helper/include/odp/helper/udp.h
> @@ -33,15 +33,6 @@ typedef struct ODP_PACKED {
> uint16be_t chksum;   /**< UDP header and data checksum (0 if not
> used)*/
>  } odph_udphdr_t;
>
> -/** UDP pseudo header */
> -typedef struct ODPH_PACKET {
> -   uint32be_t src_addr; /**< Source addr */
> -   uint32be_t dst_addr; /**< Destination addr */
> -   uint8_t pad; /**< pad byte */
> -   uint8_t proto;   /**< UDP protocol */
> -   uint16be_t length;   /**< data length */
> -} odph_udpphdr_t;
> -
>  /**
>   * UDP checksum
>   *
> @@ -53,10 +44,10 @@ typedef struct ODPH_PACKET {
>  static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
>  {
> uint32_t sum = 0;
> -   odph_udpphdr_t phdr;
> odph_udphdr_t *udph;
> odph_ipv4hdr_t *iph;
> uint16_t udplen;
> +   uint8_t *buf;
>
> if (!odp_packet_l3_offset(pkt))
> return 0;
> @@ -68,24 +59,22 @@ static inline uint16_t
> odph_ipv4_udp_chksum(odp_packet_t pkt)
> udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
> udplen = odp_be_to_cpu_16(udph->length);
>
> -   /* the source ip */
> -   phdr.src_addr = iph->src_addr;
> -   /* the dest ip */
> -   phdr.dst_addr = iph->dst_addr;
> -   /* proto */
> -   phdr.pad = 0;
> -   phdr.proto = ODPH_IPPROTO_UDP;
> -   /* the length */
> -   phdr.length = udph->length;
> -
> -   /* calc UDP pseudo header chksum */
> -   sum = (__odp_force uint32_t) odp_chksum(&phdr,
> sizeof(odph_udpphdr_t));
> -   /* calc udp header and data chksum */
> -   sum += (__odp_force uint32_t) odp_chksum(udph, udplen);
> +   /* 32-bit sum of all 16-bit words covered by UDP chksum */
> +   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
> + (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> + (uint16_t) iph->proto + udplen;
> +   for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
> +   sum += ((*buf << 8) + *(buf + 1));
> +   buf += 2;
> +   }
>
> /* Fold sum to 16 bits: add carrier to result */
> while (sum >> 16)
> sum = (sum & 0x) + (sum >> 16);
> +
> +   /* 1's complement */
> +   sum = ~sum;
> +
> /* set computation result */
> sum = (sum == 0x0) ? 0x : sum;
>
> --
> 1.7.3.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] Fwd: [PATCH 1/1 v1] helpers: fix udp checksum computation

[Alexandru Badicioiu]

I think we need to fix this (at least for IPv4) as it is likely to fail
pktio validation suite. Packets with wrong checksums are likely to be
discarded by ports configured for checksum validation. IPv6 support can be
added later.

Alex

On 8 May 2015 at 17:17, Bill Fischofer  wrote:

> If we're going to fix this, it should be a complete fix.  This seems to be
> tied to IPv4 and it should support IPv6 as well.
>
> On Fri, May 8, 2015 at 9:02 AM, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>> Ping.
>>
>> -- Forwarded message --
>> From: 
>> Date: 5 May 2015 at 15:07
>> Subject: [lng-odp][PATCH 1/1 v1] helpers: fix udp checksum computation
>> To: lng-odp@lists.linaro.org
>> Cc: Alexandru Badicioiu 
>>
>>
>> From: Alexandru Badicioiu 
>>
>> v1 - fixed compile error due to -Wcast-align
>>
>> Signed-off-by: Alexandru Badicioiu 
>> ---
>>  helper/include/odp/helper/udp.h |   37
>> +
>>  1 files changed, 13 insertions(+), 24 deletions(-)
>>
>> diff --git a/helper/include/odp/helper/udp.h
>> b/helper/include/odp/helper/udp.h
>> index 99a96f2..d14cbef 100644
>> --- a/helper/include/odp/helper/udp.h
>> +++ b/helper/include/odp/helper/udp.h
>> @@ -33,15 +33,6 @@ typedef struct ODP_PACKED {
>> uint16be_t chksum;   /**< UDP header and data checksum (0 if not
>> used)*/
>>  } odph_udphdr_t;
>>
>> -/** UDP pseudo header */
>> -typedef struct ODPH_PACKET {
>> -   uint32be_t src_addr; /**< Source addr */
>> -   uint32be_t dst_addr; /**< Destination addr */
>> -   uint8_t pad; /**< pad byte */
>> -   uint8_t proto;   /**< UDP protocol */
>> -   uint16be_t length;   /**< data length */
>> -} odph_udpphdr_t;
>> -
>>  /**
>>   * UDP checksum
>>   *
>> @@ -53,10 +44,10 @@ typedef struct ODPH_PACKET {
>>  static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
>>  {
>> uint32_t sum = 0;
>> -   odph_udpphdr_t phdr;
>> odph_udphdr_t *udph;
>> odph_ipv4hdr_t *iph;
>> uint16_t udplen;
>> +   uint8_t *buf;
>>
>> if (!odp_packet_l3_offset(pkt))
>> return 0;
>> @@ -68,24 +59,22 @@ static inline uint16_t
>> odph_ipv4_udp_chksum(odp_packet_t pkt)
>> udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
>> udplen = odp_be_to_cpu_16(udph->length);
>>
>> -   /* the source ip */
>> -   phdr.src_addr = iph->src_addr;
>> -   /* the dest ip */
>> -   phdr.dst_addr = iph->dst_addr;
>> -   /* proto */
>> -   phdr.pad = 0;
>> -   phdr.proto = ODPH_IPPROTO_UDP;
>> -   /* the length */
>> -   phdr.length = udph->length;
>> -
>> -   /* calc UDP pseudo header chksum */
>> -   sum = (__odp_force uint32_t) odp_chksum(&phdr,
>> sizeof(odph_udpphdr_t));
>> -   /* calc udp header and data chksum */
>> -   sum += (__odp_force uint32_t) odp_chksum(udph, udplen);
>> +   /* 32-bit sum of all 16-bit words covered by UDP chksum */
>> +   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
>> + (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
>> + (uint16_t) iph->proto + udplen;
>> +   for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
>> +   sum += ((*buf << 8) + *(buf + 1));
>> +   buf += 2;
>> +   }
>>
>> /* Fold sum to 16 bits: add carrier to result */
>> while (sum >> 16)
>> sum = (sum & 0x) + (sum >> 16);
>> +
>> +   /* 1's complement */
>> +   sum = ~sum;
>> +
>> /* set computation result */
>> sum = (sum == 0x0) ? 0x : sum;
>>
>> --
>> 1.7.3.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] [PATCH v2] linux-generic/odp_impl: add implementation version details

[Stuart Haslam]

On Fri, May 08, 2015 at 09:48:39AM -0400, Mike Holmes wrote:
> On 8 May 2015 at 09:37, Stuart Haslam  wrote:
> 
> > On Fri, May 08, 2015 at 08:40:39AM -0400, Mike Holmes wrote:
> > > sorry paste failed me insert odp_version_impl_str
> > >
> > > However we just re-purposed odp_version_impl_str  from returning that "1"
> > > to a string that is good for debug logs.
> > >
> > > odp_version_impl_str  = 0  << revert this to its old purpose
> >
> > Wouldn't it make sense for this function to return a string that
> > matches the name of the tag that gets applied for releases that change
> > the implementation and not the API?.. surely that won't be "0"
> >
> 
> We did start with this solution concatenating the api number and an
> implementation number only. For this next release it would be 1.1.0.0  and
> the tag in the repo should be v1.1.0.0  so I think you are suggesting the
> original proposal. For a  non API change if it happened right after 1.1 it
> becomes 1.1.0.1

Actually I didn't really know what to suggest so I was just asking a
question :).. point is that the implementation version string should
actually be useful for both tracking down where the release originated
from (git tag) and using in bug reports (dropdown box in bugzilla).

I think just appending it to the API version is going be confusing (it
already is), but given that we can't make API and implementation
releases independently perhaps it's still the best thing to do.

Still not clear on how tags would be applied though, would both API
version and implementation version tags be applied for releases that
change both?

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

[lng-odp] [PATCH] linux-generic: add implementation version for packaging

[Maxim Uvarov]

Signed-off-by: Maxim Uvarov 
---
 scripts/odp_version.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/odp_version.sh b/scripts/odp_version.sh
index d71d2f7..2487b7f 100755
--- a/scripts/odp_version.sh
+++ b/scripts/odp_version.sh
@@ -6,4 +6,7 @@ GEN=`grep "define ODP_VERSION_API_GENERATION"   ${VFILE} | cut 
-d ' ' -f 3`
 MAJ=`grep "define ODP_VERSION_API_MAJOR"   ${VFILE} | cut -d ' ' -f 3`
 MIN=`grep "define ODP_VERSION_API_MINOR"   ${VFILE} | cut -d ' ' -f 3`
 
-echo -n $GEN.$MAJ.$MIN
+IMPL_FILE="platform/linux-generic/odp_impl.c"
+IMPL=`grep "define ODP_VERSION_IMPL "  ${IMPL_FILE} | cut -d ' ' -f 3`
+
+echo -n $GEN.$MAJ.$MIN.$IMPL
-- 
1.9.1

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

Re: [lng-odp] Fwd: [PATCH 1/1 v1] helpers: fix udp checksum computation

[Maxim Uvarov]

On 05/08/2015 17:21, Alexandru Badicioiu wrote:
I think we need to fix this (at least for IPv4) as it is likely to 
fail pktio validation suite. Packets with wrong checksums are likely 
to be discarded by ports configured for checksum validation. IPv6 
support can be added later.


Alex

agree, ipv6 can be separate patch. If ipv6 also need fixing we need to 
create bug for it, not not forget about this issue.


Maxim.
On 8 May 2015 at 17:17, Bill Fischofer > wrote:


If we're going to fix this, it should be a complete fix.  This
seems to be tied to IPv4 and it should support IPv6 as well.

On Fri, May 8, 2015 at 9:02 AM, Alexandru Badicioiu
mailto:alexandru.badici...@linaro.org>> wrote:

Ping.

-- Forwarded message --
From: mailto:alexandru.badici...@linaro.org>>
Date: 5 May 2015 at 15:07
Subject: [lng-odp][PATCH 1/1 v1] helpers: fix udp checksum
computation
To: lng-odp@lists.linaro.org 
Cc: Alexandru Badicioiu mailto:alexandru.badici...@linaro.org>>


From: Alexandru Badicioiu mailto:alexandru.badici...@linaro.org>>

v1 - fixed compile error due to -Wcast-align

Signed-off-by: Alexandru Badicioiu
mailto:alexandru.badici...@linaro.org>>
---
 helper/include/odp/helper/udp.h |   37
+
 1 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/helper/include/odp/helper/udp.h
b/helper/include/odp/helper/udp.h
index 99a96f2..d14cbef 100644
--- a/helper/include/odp/helper/udp.h
+++ b/helper/include/odp/helper/udp.h
@@ -33,15 +33,6 @@ typedef struct ODP_PACKED {
uint16be_t chksum;   /**< UDP header and data checksum
(0 if not used)*/
 } odph_udphdr_t;

-/** UDP pseudo header */
-typedef struct ODPH_PACKET {
-   uint32be_t src_addr; /**< Source addr */
-   uint32be_t dst_addr; /**< Destination addr */
-   uint8_t pad; /**< pad byte */
-   uint8_t proto;   /**< UDP protocol */
-   uint16be_t length;   /**< data length */
-} odph_udpphdr_t;
-
 /**
  * UDP checksum
  *
@@ -53,10 +44,10 @@ typedef struct ODPH_PACKET {
 static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
 {
uint32_t sum = 0;
-   odph_udpphdr_t phdr;
odph_udphdr_t *udph;
odph_ipv4hdr_t *iph;
uint16_t udplen;
+   uint8_t *buf;

if (!odp_packet_l3_offset(pkt))
return 0;
@@ -68,24 +59,22 @@ static inline uint16_t
odph_ipv4_udp_chksum(odp_packet_t pkt)
udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
udplen = odp_be_to_cpu_16(udph->length);

-   /* the source ip */
-   phdr.src_addr = iph->src_addr;
-   /* the dest ip */
-   phdr.dst_addr = iph->dst_addr;
-   /* proto */
-   phdr.pad = 0;
-   phdr.proto = ODPH_IPPROTO_UDP;
-   /* the length */
-   phdr.length = udph->length;
-
-   /* calc UDP pseudo header chksum */
-   sum = (__odp_force uint32_t) odp_chksum(&phdr,
sizeof(odph_udpphdr_t));
-   /* calc udp header and data chksum */
-   sum += (__odp_force uint32_t) odp_chksum(udph, udplen);
+   /* 32-bit sum of all 16-bit words covered by UDP chksum */
+   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
+ (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
+ (uint16_t) iph->proto + udplen;
+   for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
+   sum += ((*buf << 8) + *(buf + 1));
+   buf += 2;
+   }

/* Fold sum to 16 bits: add carrier to result */
while (sum >> 16)
sum = (sum & 0x) + (sum >> 16);
+
+   /* 1's complement */
+   sum = ~sum;
+
/* set computation result */
sum = (sum == 0x0) ? 0x : sum;

--
1.7.3.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

Re: [lng-odp] NUMA aware memory allocation?

[Jacob, Jerin]

In multi node ODP implementation / application usage perceptive,
we need to consider, How we can expose the HW resources in each node.
resources could be cpus, memory and any hw accelerated blocks for packet 
processing.


In case of CPU resource, we could take the current API model like, API's for 
querying how may
cpu resource available in each node and start specific work on selected cpus 
using odp_cpu_mask_t/
Let implementation take care of pinning/exposing the number cores for ODP on 
each node.

In case of memory resource, IMO odp_shm_reserve can extended to allocated form a
specific node

In case of hw accelerated blocks resources, IMO we should add node
parameter while creating the handles


IMO, Gábor Sándor Enyedi's example may be visualized like this on multi node ODP


-local_pool = odp_pool_create() // create a local pool
-odp_pktio_open(..,local_pool)  // open local node pktio and attach to local 
pool

-remote_pool = odp_pool_create_onnode(node...) // create a remote pool as 
packet needs to go remote node DDR
-odp_pktio_open_onnode(node,...,remote_pool) // open remote node pktio with 
remote pool

-odp_cpu_count()
-create cpu mask and lunch work on local node

-odp_cpu_count(node) // to get number works available on remote node
-create cpu mask and lunch work on remote node​


From: Bill Fischofer 
Sent: Friday, May 8, 2015 7:43 PM
To: Gábor Sándor Enyedi
Cc: Savolainen, Petri (Nokia - FI/Espoo); Jacob, Jerin; Zoltan Kiss; 
lng-odp@lists.linaro.org
Subject: Re: [lng-odp] NUMA aware memory allocation?
  

Thanks, that's good info. So in this case is it sufficient to say that the 
memory used for odp_pool_create() is the one associated with the thread that 
executes the create call?  Presumably then when a packet arrives and is 
assigned to a CoS  that points to that pool then events from that pool are sent 
to queues that are only scheduled to the corresponding cores that have fast 
access to that pool.  Right now queues have an odp_schedule_group_t but that's 
still fairly rudimentary.  It sounds like  we might want to point the queue at 
the pool for scheduling purposes so that it would inherit the NUMA 
considerations you mention.


On Fri, May 8, 2015 at 9:00 AM, Gábor Sándor Enyedi  
 wrote:

For me and for now the use-case is very simple: we have an x86 with two Xeon 
CPU-s (dual socket) in it. Each of the CPU-s have its own memory and own 
PCIExpress bus, as usual. First, I want to make only some test code, but later 
we may  want to port our high speed OF soft switch to ODP (now, its on DPDK). 
We want to assign a correct core for each interface, and each slot must use its 
own copy of forwarding data in its own memory. We have the experience that if 
we accidentally assigned a bad  core to an interface, we could get even about 
50% performance drop, so NUMA is essential.
Based on the previous, for us something similar to that used in DPDK's 
rte_malloc (and its variants) and a NUMA aware buffer pool create was enough 
for now. Later we want to investigate other architectures... but I don't know 
the use-cases yet.

Gabor






On 05/08/2015 03:35 PM, Bill Fischofer wrote:
 
Insofar as possible, the mechanics of NUMA should be the responsibility of the 
ODP implementation, rather than the application, since that way the application 
retains maximum portability.


However, from an ODP API perspective, I think we need to be mindful of NUMA 
considerations to give implementations the necessary "hooks" to properly 
support the NUMA aspects of their platform.  This is why ODP APIs need to be 
careful about what addressability  assumptions they make.


If Gábor or Jerrin can list a couple of specific relevant cases I think that 
will help in focusing the discussion and get us off to a good start. 


On Fri, May 8, 2015 at 8:26 AM, Savolainen, Petri (Nokia - FI/Espoo) 
 wrote:
 Hi,

ODP is OS agnostic and thus thread management (e.g. thread creation and pinning 
to physical cores) and NUMA awareness should happen mostly outside of ODP APIs.

For example, NUMA could be visible in ODP APIs this way:
* Add odp_cpumask_xxx() calls that indicate NUMA dependency between CPUs (just 
for information)
* Add a way to identify groups of threads which frequently share resources 
(memory and handles) within the group
* Give the thread group as a hint (parameter) to various ODP calls that create 
shared resources. Implementation can use the information to allocate resources 
"near" to the threads in the group. However, the user is responsible to group 
the threads and map/pin  those into physical CPUs in a way that enables NUMA 
aware optimizations.


-Petri





> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Gábor Sándor Enyedi
> Sent: Friday, May 08, 2015 10:48 AM
> To: Jerin Jacob; Zoltan Kiss
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] NUMA aware memory allocation?
>
> Hi,
>
> Thanks. So, is the workaround for now to start the t

[lng-odp] [PATCH] linux-generic: revert ODP_VERSION_IMPL_STR

[Mike Holmes]

Signed-off-by: Mike Holmes 
---
 platform/linux-generic/odp_impl.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/platform/linux-generic/odp_impl.c 
b/platform/linux-generic/odp_impl.c
index 46d0e40..a31bbbe 100644
--- a/platform/linux-generic/odp_impl.c
+++ b/platform/linux-generic/odp_impl.c
@@ -22,16 +22,7 @@ extern "C" {
 
 #define ODP_VERSION_IMPL 0
 #define ODP_VERSION_IMPL_STR \
-   ODP_VERSION_TO_STR(PLATFORM) " " \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
-   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
-   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
-   __DATE__ " " __TIME__ " " \
-   ODP_VERSION_TO_STR(GIT_HASH)
+   ODP_VERSION_TO_STR(ODP_VERSION_IMPL)
 
 const char *odp_version_impl_str(void)
 {
-- 
2.1.4

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

[lng-odp] [API-NEXT PATCH] api: version.h: add odp_version_str

[Mike Holmes]

Signed-off-by: Mike Holmes 
---
 include/odp/api/version.h | 17 +
 platform/linux-generic/odp_impl.c | 16 
 test/miscellaneous/odp_api_from_cpp.cpp   |  1 +
 test/validation/common/odp_cunit_common.c |  1 +
 test/validation/odp_init.c|  1 +
 test/validation/odp_init_abort.c  |  1 +
 test/validation/odp_init_log.c|  1 +
 7 files changed, 38 insertions(+)

diff --git a/include/odp/api/version.h b/include/odp/api/version.h
index 027095d..f64e4ef 100644
--- a/include/odp/api/version.h
+++ b/include/odp/api/version.h
@@ -50,6 +50,8 @@ extern "C" {
 
 /**
  * Returns ODP API version string
+ * @sa odp_version_impl_str()
+ * @sa odp_version_str()
  */
 const char *odp_version_api_str(void);
 
@@ -61,10 +63,25 @@ const char *odp_version_api_str(void);
  * of the API changing, this function returns that indication string.
  * @note This string is implementation specific.
  * @sa odp_version_api_str()
+ * @sa odp_version_str()
  *
  * @return null terminated implementation specific version identifier string
   */
 const char *odp_version_impl_str(void);
+
+/**
+ * Returns ODP version string
+ *
+ * Verbosely describe the build in use, typicaly for use in log file.
+ * @note This string is implementation specific.
+ * @sa odp_version_api_str()
+ * @sa odp_version_impl_str()
+ *
+ * @return null terminated implementation specific version string
+  */
+const char *odp_version_str(void);
+
+
 /**
  * @}
  */
diff --git a/platform/linux-generic/odp_impl.c 
b/platform/linux-generic/odp_impl.c
index 46d0e40..26ee3f9 100644
--- a/platform/linux-generic/odp_impl.c
+++ b/platform/linux-generic/odp_impl.c
@@ -38,6 +38,22 @@ const char *odp_version_impl_str(void)
return ODP_VERSION_IMPL_STR;
 }
 
+#define ODP_VERSION_STR \
+   ODP_VERSION_TO_STR(PLATFORM) " " \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) "-" \
+   ODP_VERSION_TO_STR(ODP_VERSION_IMPL) " (v" \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_GENERATION) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MAJOR) "." \
+   ODP_VERSION_TO_STR(ODP_VERSION_API_MINOR) ") " \
+   __DATE__ " " __TIME__ " " \
+   ODP_VERSION_TO_STR(GIT_HASH)
+
+const char *odp_version_str(void)
+{
+   return ODP_VERSION_STR;
+}
 #ifdef __cplusplus
 }
 #endif
diff --git a/test/miscellaneous/odp_api_from_cpp.cpp 
b/test/miscellaneous/odp_api_from_cpp.cpp
index e62ef8d..f044f92 100644
--- a/test/miscellaneous/odp_api_from_cpp.cpp
+++ b/test/miscellaneous/odp_api_from_cpp.cpp
@@ -7,6 +7,7 @@ int main(int argc, const char *argv[])
 
printf("\tODP API version: %s\n", odp_version_api_str());
printf("\tODP implementation version: %s\n", odp_version_impl_str());
+   printf("\tODP version: %s\n", odp_version_str());
 
return 0;
 }
diff --git a/test/validation/common/odp_cunit_common.c 
b/test/validation/common/odp_cunit_common.c
index 2af4410..315a902 100644
--- a/test/validation/common/odp_cunit_common.c
+++ b/test/validation/common/odp_cunit_common.c
@@ -55,6 +55,7 @@ int main(void)
 
printf("\tODP API version: %s\n", odp_version_api_str());
printf("\tODP implementation version: %s\n", odp_version_impl_str());
+   printf("\tODP version: %s\n", odp_version_str());
 
if (0 != odp_init_global(NULL, NULL)) {
fprintf(stderr, "error: odp_init_global() failed.\n");
diff --git a/test/validation/odp_init.c b/test/validation/odp_init.c
index 82f8849..08e0b08 100644
--- a/test/validation/odp_init.c
+++ b/test/validation/odp_init.c
@@ -37,6 +37,7 @@ int main(void)
 
printf("\tODP API version: %s\n", odp_version_api_str());
printf("\tODP implementation version: %s\n", odp_version_impl_str());
+   printf("\tODP version: %s\n", odp_version_str());
 
CU_set_error_action(CUEA_ABORT);
 
diff --git a/test/validation/odp_init_abort.c b/test/validation/odp_init_abort.c
index ceb82b5..7844066 100644
--- a/test/validation/odp_init_abort.c
+++ b/test/validation/odp_init_abort.c
@@ -42,6 +42,7 @@ int main(void)
 
printf("\tODP API version: %s\n", odp_version_api_str());
printf("\tODP implementation version: %s\n", odp_version_impl_str());
+   printf("\tODP version: %s\n", odp_version_str());
 
CU_set_error_action(CUEA_ABORT);
 
diff --git a/test/validation/odp_init_log.c b/test/validation/odp_init_log.c
index 275d343..f905850 100644
--- a/test/validation/odp_init_log.c
+++ b/test/validation/odp_init_log.c
@@ -48,6 +48,7 @@ int main(void)
 
printf("\tODP API version: %s\n", odp_version_api_str());
printf("\tODP implementation version: %s\n", odp_version_impl_str());
+   printf("\tODP version: %s\n", odp_version_str());
 
CU_set_error_action(CUEA_ABORT);
 
-

[lng-odp] ODP mainline Build is broken

[Mike Holmes]

https://ci.linaro.org/view/odp-ci/job/odp-tool-check/build_type=m32_on_64,label=docker-utopic/59/console

In file included from ./include/odp/debug.h:28:0,
 from odp_classification.c:10:
../../include/odp/api/debug.h:48:40: error: static assertion failed:
"ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^
In file included from ./include/odp/debug.h:28:0,
 from odp_crypto.c:12:
../../include/odp/api/debug.h:48:40: error: static assertion failed:
"ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^

BISECT looks like it is this commit

1a042da102ee03f1ba05821af0664906e3409d09 is the first bad commit
commit 1a042da102ee03f1ba05821af0664906e3409d09
Author: Bill Fischofer 
Date:   Fri Apr 10 10:52:15 2015 -0500

linux-generic: buffer: restructure user mdatadata fields

Signed-off-by: Bill Fischofer 
Reviewed-and-tested-by: Ciprian Barbu 
Signed-off-by: Maxim Uvarov 

:04 04 eb6bd6ceb600e8328a798b26cb34678231e53a1f
5bdcd46831800064aac606163a03e79cf2665306 M platform

Mike

-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] NUMA aware memory allocation?

[Bill Fischofer]

Good points, however rather than having odp_..._onnode() variants, I think
encoding the extra info in an appropriate odp_xxx_params_t structure would
be more consistent with how we've been shaping the APIs.  That way it
doesn't require separate API calls to handle the variants.

On Fri, May 8, 2015 at 10:11 AM, Jacob, Jerin <
jerin.ja...@caviumnetworks.com> wrote:

>
> In multi node ODP implementation / application usage perceptive,
> we need to consider, How we can expose the HW resources in each node.
> resources could be cpus, memory and any hw accelerated blocks for packet
> processing.
>
>
> In case of CPU resource, we could take the current API model like, API's
> for querying how may
> cpu resource available in each node and start specific work on selected
> cpus using odp_cpu_mask_t/
> Let implementation take care of pinning/exposing the number cores for ODP
> on each node.
>
> In case of memory resource, IMO odp_shm_reserve can extended to allocated
> form a
> specific node
>
> In case of hw accelerated blocks resources, IMO we should add node
> parameter while creating the handles
>
>
> IMO, Gábor Sándor Enyedi's example may be visualized like this on multi
> node ODP
>
>
> -local_pool = odp_pool_create() // create a local pool
> -odp_pktio_open(..,local_pool)  // open local node pktio and attach to
> local pool
>
> -remote_pool = odp_pool_create_onnode(node...) // create a remote pool as
> packet needs to go remote node DDR
> -odp_pktio_open_onnode(node,...,remote_pool) // open remote node pktio
> with remote pool
>
> -odp_cpu_count()
> -create cpu mask and lunch work on local node
>
> -odp_cpu_count(node) // to get number works available on remote node
> -create cpu mask and lunch work on remote node​
>
>
> From: Bill Fischofer 
> Sent: Friday, May 8, 2015 7:43 PM
> To: Gábor Sándor Enyedi
> Cc: Savolainen, Petri (Nokia - FI/Espoo); Jacob, Jerin; Zoltan Kiss;
> lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] NUMA aware memory allocation?
>
>
> Thanks, that's good info. So in this case is it sufficient to say that the
> memory used for odp_pool_create() is the one associated with the thread
> that executes the create call?  Presumably then when a packet arrives and
> is assigned to a CoS  that points to that pool then events from that pool
> are sent to queues that are only scheduled to the corresponding cores that
> have fast access to that pool.  Right now queues have an
> odp_schedule_group_t but that's still fairly rudimentary.  It sounds like
> we might want to point the queue at the pool for scheduling purposes so
> that it would inherit the NUMA considerations you mention.
>
>
> On Fri, May 8, 2015 at 9:00 AM, Gábor Sándor Enyedi  <
> gabor.sandor.eny...@ericsson.com> wrote:
>
> For me and for now the use-case is very simple: we have an x86 with two
> Xeon CPU-s (dual socket) in it. Each of the CPU-s have its own memory and
> own PCIExpress bus, as usual. First, I want to make only some test code,
> but later we may  want to port our high speed OF soft switch to ODP (now,
> its on DPDK). We want to assign a correct core for each interface, and each
> slot must use its own copy of forwarding data in its own memory. We have
> the experience that if we accidentally assigned a bad  core to an
> interface, we could get even about 50% performance drop, so NUMA is
> essential.
> Based on the previous, for us something similar to that used in DPDK's
> rte_malloc (and its variants) and a NUMA aware buffer pool create was
> enough for now. Later we want to investigate other architectures... but I
> don't know the use-cases yet.
>
> Gabor
>
>
>
>
>
>
> On 05/08/2015 03:35 PM, Bill Fischofer wrote:
>
> Insofar as possible, the mechanics of NUMA should be the responsibility of
> the ODP implementation, rather than the application, since that way the
> application retains maximum portability.
>
>
> However, from an ODP API perspective, I think we need to be mindful of
> NUMA considerations to give implementations the necessary "hooks" to
> properly support the NUMA aspects of their platform.  This is why ODP APIs
> need to be careful about what addressability  assumptions they make.
>
>
> If Gábor or Jerrin can list a couple of specific relevant cases I think
> that will help in focusing the discussion and get us off to a good start.
>
>
> On Fri, May 8, 2015 at 8:26 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>  Hi,
>
> ODP is OS agnostic and thus thread management (e.g. thread creation and
> pinning to physical cores) and NUMA awareness should happen mostly outside
> of ODP APIs.
>
> For example, NUMA could be visible in ODP APIs this way:
> * Add odp_cpumask_xxx() calls that indicate NUMA dependency between CPUs
> (just for information)
> * Add a way to identify groups of threads which frequently share resources
> (memory and handles) within the group
> * Give the thread group as a hint (parameter) to various ODP calls that
> create shared resources. Implementat

Re: [lng-odp] ODP mainline Build is broken

[Bill Fischofer]

For linux-generic all of those size asserts are vestigial and serve no
purpose because all buffer/packet headers are cache-aligned elsewhere.  I
can submit a patch to remove the offending ASSERT.

On Fri, May 8, 2015 at 1:24 PM, Mike Holmes  wrote:

>
> https://ci.linaro.org/view/odp-ci/job/odp-tool-check/build_type=m32_on_64,label=docker-utopic/59/console
>
> In file included from ./include/odp/debug.h:28:0,
>  from odp_classification.c:10:
> ../../include/odp/api/debug.h:48:40: error: static assertion failed:
> "ODP_PACKET_HDR_T__SIZE_ERR2"
>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
> ^
> ./include/odp_packet_internal.h:142:1: note: in expansion of macro
> '_ODP_STATIC_ASSERT'
>  _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
>  ^
> In file included from ./include/odp/debug.h:28:0,
>  from odp_crypto.c:12:
> ../../include/odp/api/debug.h:48:40: error: static assertion failed:
> "ODP_PACKET_HDR_T__SIZE_ERR2"
>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
> ^
> ./include/odp_packet_internal.h:142:1: note: in expansion of macro
> '_ODP_STATIC_ASSERT'
>  _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
>  ^
>
> BISECT looks like it is this commit
>
> 1a042da102ee03f1ba05821af0664906e3409d09 is the first bad commit
> commit 1a042da102ee03f1ba05821af0664906e3409d09
> Author: Bill Fischofer 
> Date:   Fri Apr 10 10:52:15 2015 -0500
>
> linux-generic: buffer: restructure user mdatadata fields
>
> Signed-off-by: Bill Fischofer 
> Reviewed-and-tested-by: Ciprian Barbu 
> Signed-off-by: Maxim Uvarov 
>
> :04 04 eb6bd6ceb600e8328a798b26cb34678231e53a1f
> 5bdcd46831800064aac606163a03e79cf2665306 M platform
>
> Mike
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
>
>
>
> ___
> 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] ODP mainline Build is broken

[Maxim Uvarov]

On 05/08/2015 21:29, Bill Fischofer wrote:
For linux-generic all of those size asserts are vestigial and serve no 
purpose because all buffer/packet headers are cache-aligned 
elsewhere.  I can submit a patch to remove the offending ASSERT.



successful builds:
log-amd64
log-arm
log-arm64

failed builds:
log-amd64_32


On Fri, May 8, 2015 at 1:24 PM, Mike Holmes > wrote:



https://ci.linaro.org/view/odp-ci/job/odp-tool-check/build_type=m32_on_64,label=docker-utopic/59/console

In file included from ./include/odp/debug.h:28:0,
 from odp_classification.c:10:
../../include/odp/api/debug.h:48:40: error: static assertion
failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^
In file included from ./include/odp/debug.h:28:0,
 from odp_crypto.c:12:
../../include/odp/api/debug.h:48:40: error: static assertion
failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^

BISECT looks like it is this commit

1a042da102ee03f1ba05821af0664906e3409d09 is the first bad commit
commit 1a042da102ee03f1ba05821af0664906e3409d09
Author: Bill Fischofer mailto:bill.fischo...@linaro.org>>
Date:   Fri Apr 10 10:52:15 2015 -0500

linux-generic: buffer: restructure user mdatadata fields
Signed-off-by: Bill Fischofer mailto:bill.fischo...@linaro.org>>
Reviewed-and-tested-by: Ciprian Barbu
mailto:ciprian.ba...@linaro.org>>
Signed-off-by: Maxim Uvarov mailto:maxim.uva...@linaro.org>>

:04 04 eb6bd6ceb600e8328a798b26cb34678231e53a1f
5bdcd46831800064aac606163a03e79cf2665306 Mplatform

Mike

-- 
Mike Holmes

Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software for
ARM SoCs


___
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

Re: [lng-odp] ODP mainline Build is broken

[Maxim Uvarov]

On 05/08/2015 21:29, Bill Fischofer wrote:
For linux-generic all of those size asserts are vestigial and serve no 
purpose because all buffer/packet headers are cache-aligned 
elsewhere.  I can submit a patch to remove the offending ASSERT.



+1 to remove it. warning is not needed.

Maxim.

On Fri, May 8, 2015 at 1:24 PM, Mike Holmes > wrote:



https://ci.linaro.org/view/odp-ci/job/odp-tool-check/build_type=m32_on_64,label=docker-utopic/59/console

In file included from ./include/odp/debug.h:28:0,
 from odp_classification.c:10:
../../include/odp/api/debug.h:48:40: error: static assertion
failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^
In file included from ./include/odp/debug.h:28:0,
 from odp_crypto.c:12:
../../include/odp/api/debug.h:48:40: error: static assertion
failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
 #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
^
./include/odp_packet_internal.h:142:1: note: in expansion of macro
'_ODP_STATIC_ASSERT'
 _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
 ^

BISECT looks like it is this commit

1a042da102ee03f1ba05821af0664906e3409d09 is the first bad commit
commit 1a042da102ee03f1ba05821af0664906e3409d09
Author: Bill Fischofer mailto:bill.fischo...@linaro.org>>
Date:   Fri Apr 10 10:52:15 2015 -0500

linux-generic: buffer: restructure user mdatadata fields
Signed-off-by: Bill Fischofer mailto:bill.fischo...@linaro.org>>
Reviewed-and-tested-by: Ciprian Barbu
mailto:ciprian.ba...@linaro.org>>
Signed-off-by: Maxim Uvarov mailto:maxim.uva...@linaro.org>>

:04 04 eb6bd6ceb600e8328a798b26cb34678231e53a1f
5bdcd46831800064aac606163a03e79cf2665306 Mplatform

Mike

-- 
Mike Holmes

Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software for
ARM SoCs


___
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] linux-generic: packet: remove extraneous ASSERT

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp_packet_internal.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index c3dcdd8..90dfe80 100644
--- a/platform/linux-generic/include/odp_packet_internal.h
+++ b/platform/linux-generic/include/odp_packet_internal.h
@@ -139,9 +139,6 @@ typedef struct odp_packet_hdr_stride {
uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(odp_packet_hdr_t))];
 } odp_packet_hdr_stride;
 
-_ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
-  "ODP_PACKET_HDR_T__SIZE_ERR2");
-
 /**
  * Return the packet header
  */
-- 
2.1.0

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

Re: [lng-odp] ODP mainline Build is broken

[Bill Fischofer]

Patch http://patches.opendataplane.org/patch/1586/ posted to address this
issue.

On Fri, May 8, 2015 at 1:38 PM, Maxim Uvarov 
wrote:

> On 05/08/2015 21:29, Bill Fischofer wrote:
>
>> For linux-generic all of those size asserts are vestigial and serve no
>> purpose because all buffer/packet headers are cache-aligned elsewhere.  I
>> can submit a patch to remove the offending ASSERT.
>>
>>  +1 to remove it. warning is not needed.
>
> Maxim.
>
>  On Fri, May 8, 2015 at 1:24 PM, Mike Holmes > > wrote:
>>
>>
>> https://ci.linaro.org/view/odp-ci/job/odp-tool-check/build_type=m32_on_64,label=docker-utopic/59/console
>>
>> In file included from ./include/odp/debug.h:28:0,
>>  from odp_classification.c:10:
>> ../../include/odp/api/debug.h:48:40: error: static assertion
>> failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
>>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
>> ^
>> ./include/odp_packet_internal.h:142:1: note: in expansion of macro
>> '_ODP_STATIC_ASSERT'
>>  _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
>>  ^
>> In file included from ./include/odp/debug.h:28:0,
>>  from odp_crypto.c:12:
>> ../../include/odp/api/debug.h:48:40: error: static assertion
>> failed: "ODP_PACKET_HDR_T__SIZE_ERR2"
>>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
>> ^
>> ./include/odp_packet_internal.h:142:1: note: in expansion of macro
>> '_ODP_STATIC_ASSERT'
>>  _ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
>>  ^
>>
>> BISECT looks like it is this commit
>>
>> 1a042da102ee03f1ba05821af0664906e3409d09 is the first bad commit
>> commit 1a042da102ee03f1ba05821af0664906e3409d09
>> Author: Bill Fischofer > >
>> Date:   Fri Apr 10 10:52:15 2015 -0500
>>
>> linux-generic: buffer: restructure user mdatadata fields
>> Signed-off-by: Bill Fischofer > >
>> Reviewed-and-tested-by: Ciprian Barbu
>> mailto:ciprian.ba...@linaro.org>>
>> Signed-off-by: Maxim Uvarov > >
>>
>> :04 04 eb6bd6ceb600e8328a798b26cb34678231e53a1f
>> 5bdcd46831800064aac606163a03e79cf2665306 Mplatform
>>
>> Mike
>>
>> -- Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org ***│ *Open source software for
>> ARM SoCs
>>
>>
>> ___
>> 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv2] linux-generic: packet: remove extraneous ASSERT

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp_packet_internal.h | 3 ---
 platform/linux-generic/odp_pool.c| 3 ---
 2 files changed, 6 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index c3dcdd8..90dfe80 100644
--- a/platform/linux-generic/include/odp_packet_internal.h
+++ b/platform/linux-generic/include/odp_packet_internal.h
@@ -139,9 +139,6 @@ typedef struct odp_packet_hdr_stride {
uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(odp_packet_hdr_t))];
 } odp_packet_hdr_stride;
 
-_ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
-  "ODP_PACKET_HDR_T__SIZE_ERR2");
-
 /**
  * Return the packet header
  */
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index f887665..cd2c449 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -35,9 +35,6 @@ typedef union buffer_type_any_u {
odp_timeout_hdr_t tmo;
 } odp_anybuf_t;
 
-_ODP_STATIC_ASSERT((sizeof(union buffer_type_any_u) % 8) == 0,
-  "BUFFER_TYPE_ANY_U__SIZE_ERR");
-
 /* Any buffer type header */
 typedef struct {
union buffer_type_any_u any_hdr;/* any buffer type */
-- 
2.1.0

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

[lng-odp] [PATCHv3] linux-generic: remove extraneous ASSERTs

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp_packet_internal.h | 3 ---
 platform/linux-generic/odp_pool.c| 3 ---
 2 files changed, 6 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index c3dcdd8..90dfe80 100644
--- a/platform/linux-generic/include/odp_packet_internal.h
+++ b/platform/linux-generic/include/odp_packet_internal.h
@@ -139,9 +139,6 @@ typedef struct odp_packet_hdr_stride {
uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(odp_packet_hdr_t))];
 } odp_packet_hdr_stride;
 
-_ODP_STATIC_ASSERT(sizeof(odp_packet_hdr_t) % sizeof(uint64_t) == 0,
-  "ODP_PACKET_HDR_T__SIZE_ERR2");
-
 /**
  * Return the packet header
  */
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index f887665..cd2c449 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -35,9 +35,6 @@ typedef union buffer_type_any_u {
odp_timeout_hdr_t tmo;
 } odp_anybuf_t;
 
-_ODP_STATIC_ASSERT((sizeof(union buffer_type_any_u) % 8) == 0,
-  "BUFFER_TYPE_ANY_U__SIZE_ERR");
-
 /* Any buffer type header */
 typedef struct {
union buffer_type_any_u any_hdr;/* any buffer type */
-- 
2.1.0

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