date:20150421


Merged,
Maxim.

On 04/21/15 10:25, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Assuming that entire api_test directory will be removed next.


Reviewed-by: Petri Savolainen 



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
Mike Holmes
Sent: Tuesday, April 14, 2015 11:00 PM
To: christophe.mil...@linaro.org
Cc: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCH] api_test: remove odp_shm_test

The shm test is obsolte, remove it

Signed-off-by: Mike Holmes 
---
  test/api_test/Makefile.am|  6 +---
  test/api_test/odp_common.c   |  2 --
  test/api_test/odp_shm_test.c | 67 ---
-
  test/api_test/odp_shm_test.h | 24 
  4 files changed, 1 insertion(+), 98 deletions(-)
  delete mode 100644 test/api_test/odp_shm_test.c
  delete mode 100644 test/api_test/odp_shm_test.h

diff --git a/test/api_test/Makefile.am b/test/api_test/Makefile.am
index f231fee..ddbac53 100644
--- a/test/api_test/Makefile.am
+++ b/test/api_test/Makefile.am
@@ -1,17 +1,13 @@
  include $(top_srcdir)/test/Makefile.inc

-bin_PROGRAMS = odp_shm odp_ring
+bin_PROGRAMS = odp_ring

-odp_shm_CFLAGS = $(AM_CFLAGS)
  odp_ring_CFLAGS = $(AM_CFLAGS)

-odp_shm_LDFLAGS = $(AM_LDFLAGS) -static
  odp_ring_LDFLAGS = $(AM_LDFLAGS) -static

  noinst_HEADERS = \
  $(top_srcdir)/test/api_test/odp_common.h \
- $(top_srcdir)/test/api_test/odp_shm_test.h \
  $(top_srcdir)/test/test_debug.h

-dist_odp_shm_SOURCES = odp_shm_test.c odp_common.c
  dist_odp_ring_SOURCES = odp_ring_test.c odp_common.c
diff --git a/test/api_test/odp_common.c b/test/api_test/odp_common.c
index 18b365e..0677f9b 100644
--- a/test/api_test/odp_common.c
+++ b/test/api_test/odp_common.c
@@ -14,7 +14,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 

  #define MAX_WORKERS   32/**< Max worker threads */
@@ -22,7 +21,6 @@
  /* Globals */
  static odph_linux_pthread_t thread_tbl[MAX_WORKERS]; /**< worker threads
table*/
  static int num_workers;   /**< number of 
workers
*/
-__thread test_shared_data_t *test_shared_data; /**< pointer to shared
data */

  /**
   * Print system information
diff --git a/test/api_test/odp_shm_test.c b/test/api_test/odp_shm_test.c
deleted file mode 100644
index 13d037d..000
--- a/test/api_test/odp_shm_test.c
+++ /dev/null
@@ -1,67 +0,0 @@
-/* Copyright (c) 2013, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @file
- *
- * ODP test shared memory
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static void *run_thread(void *arg)
-{
-   pthrd_arg *parg = (pthrd_arg *)arg;
-   int thr;
-   odp_shm_t shm;
-
-   thr = odp_thread_id();
-
-   printf("Thread %i starts\n", thr);
-
-   switch (parg->testcase) {
-   case ODP_SHM_TEST:
-   shm = odp_shm_lookup("test_shared_data");
-   test_shared_data = odp_shm_addr(shm);
-   printf("  [%i] shared data at %p\n", thr, test_shared_data);
-   break;
-   default:
-   LOG_ERR("Invalid test case [%d]\n", parg->testcase);
-   }
-   fflush(stdout);
-
-   return parg;
-}
-
-int main(int argc __attribute__((__unused__)),
-char *argv[] __attribute__((__unused__)))
-{
-   pthrd_arg thrdarg;
-   odp_shm_t shm;
-
-   if (odp_test_global_init() != 0)
-   return -1;
-
-   odp_print_system_info();
-
-   shm = odp_shm_reserve("test_shared_data",
- sizeof(test_shared_data_t), 128, 0);
-   test_shared_data = odp_shm_addr(shm);
-   memset(test_shared_data, 0, sizeof(test_shared_data_t));
-   printf("test shared data at %p\n\n", test_shared_data);
-
-   thrdarg.testcase = ODP_SHM_TEST;
-   thrdarg.numthrds = odp_cpu_count();
-   odp_test_thread_create(run_thread, &thrdarg);
-
-   odp_test_thread_exit(&thrdarg);
-
-   return 0;
-}
diff --git a/test/api_test/odp_shm_test.h b/test/api_test/odp_shm_test.h
deleted file mode 100644
index 3b3f49b..000
--- a/test/api_test/odp_shm_test.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/* Copyright (c) 2013, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @file
- *
- * ODP api test shared memory header
- */
-
-#ifndef ODP_SHM_TEST_H
-#define ODP_SHM_TEST_H
-
-typedef struct {
-   int foo;
-   int bar;
-} test_shared_data_t;
-
-extern __thread test_shared_data_t *test_shared_data;
-extern int test_shm(void);
-
-#endif /* ODP_SHM_TEST_H */
--
2.1.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] [PATCH] pool: Make sure all atomics are initialized before stored or incremented

2015-04-21 Thread Nicolas Morey-Chaisemartin

Signed-off-by: Nicolas Morey-Chaisemartin 
---
 platform/linux-generic/odp_pool.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index bf49623..23cd503 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -342,13 +342,24 @@ odp_pool_t odp_pool_create(const char *name,
pool->s.blk_freelist = NULL;
 
/* Initialization will increment these to their target vals */
-   odp_atomic_store_u32(&pool->s.bufcount, 0);
-   odp_atomic_store_u32(&pool->s.blkcount, 0);
+   odp_atomic_init_u32(&pool->s.bufcount, 0);
+   odp_atomic_init_u32(&pool->s.blkcount, 0);
 
uint8_t *buf = udata_base_addr - buf_stride;
uint8_t *udat = udata_stride == 0 ? NULL :
block_base_addr - udata_stride;
 
+
+   /* Initialize pool statistics counters */
+   odp_atomic_init_u64(&pool->s.bufallocs, 0);
+   odp_atomic_init_u64(&pool->s.buffrees, 0);
+   odp_atomic_init_u64(&pool->s.blkallocs, 0);
+   odp_atomic_init_u64(&pool->s.blkfrees, 0);
+   odp_atomic_init_u64(&pool->s.bufempty, 0);
+   odp_atomic_init_u64(&pool->s.blkempty, 0);
+   odp_atomic_init_u64(&pool->s.high_wm_count, 0);
+   odp_atomic_init_u64(&pool->s.low_wm_count, 0);
+
/* Init buffer common header and add to pool buffer freelist */
do {
odp_buffer_hdr_t *tmp =
@@ -359,7 +370,7 @@ odp_pool_t odp_pool_create(const char *name,
tmp->flags.all = 0;
tmp->flags.zeroized = zeroized;
tmp->size = 0;
-   odp_atomic_store_u32(&tmp->ref_count, 0);
+   odp_atomic_init_u32(&tmp->ref_count, 0);
tmp->type = params->type;
tmp->pool_hdl = pool->s.pool_hdl;
tmp->udata_addr = (void *)udat;
@@ -397,15 +408,10 @@ odp_pool_t odp_pool_create(const char *name,
blk -= pool->s.seg_size;
} while (blk >= block_base_addr);
 
-   /* Initialize pool statistics counters */
-   odp_atomic_store_u64(&pool->s.bufallocs, 0);
+   /* Reset the statistics counters that might
+* have been changed by ret_buf */
odp_atomic_store_u64(&pool->s.buffrees, 0);
-   odp_atomic_store_u64(&pool->s.blkallocs, 0);
-   odp_atomic_store_u64(&pool->s.blkfrees, 0);
-   odp_atomic_store_u64(&pool->s.bufempty, 0);
-   odp_atomic_store_u64(&pool->s.blkempty, 0);
odp_atomic_store_u64(&pool->s.high_wm_count, 0);
-   odp_atomic_store_u64(&pool->s.low_wm_count, 0);
 
/* Reset other pool globals to initial state */
pool->s.low_wm_assert = 0;
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] pool: Do not flush cache of non-initialized pools

2015-04-21 Thread Nicolas Morey-Chaisemartin

Flush cache triggers atomic_add on some of the pool atomics which have never 
been initialized if the pool hasn't been.

Signed-off-by: Nicolas Morey-Chaisemartin 
---
 platform/linux-generic/odp_pool.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index bf49623..31bf537 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -575,6 +575,8 @@ void _odp_flush_caches(void)
 
for (i = 0; i < ODP_CONFIG_POOLS; i++) {
pool_entry_t *pool = get_pool_entry(i);
+   if (pool->s.pool_shm == ODP_SHM_INVALID)
+   continue;
flush_cache(&local_cache[i], &pool->s);
}
 }
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH API-NEXT 5/5] api: packet_io: added start and stop


On 04/20/15 15:10, Petri Savolainen wrote:

Packet IO start and stop enable a controlled setup and
tear down phases.

Interface control sequence:
* odp_pktio_open() creates a pktio interface object
* potential interface configurations (classification, input queues, etc)
* odp_pktio_start() enables packet input/output
* receive / transmit packets
* odp_pktio_stop() disables packet input/output
* drain remaining packets from queues
* remove / destroy input queues
* odp_pktio_close() destroys the pktio interface object


Petri that is also needed to remove locks inside pktio, right? For 
example odp_pktio_inq_remdef()

should be called only after odp_pktio_stop(), right?

Thanks,
Maxim.


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

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 97f79ee..6e77705 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -118,6 +118,26 @@ odp_pktio_t odp_pktio_open(const char *dev, odp_pool_t 
pool,
   const odp_pktio_param_t *param);
  
  /**

+ * Start packet receive and transmit
+ *
+ * @param pktio  Packet IO handle
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_pktio_start(odp_pktio_t pktio);
+
+/**
+ * Stop packet receive and transmit
+ *
+ * @param pktio  Packet IO handle
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_pktio_stop(odp_pktio_t pktio);
+
+/**
   * Close a packet IO interface
   *
   * @param pktio  Packet IO handle


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

Re: [lng-odp] [PATCH] example: timer: clean up prescheduled events

On 20 April 2015 at 19:15, Mike Holmes  wrote:

> I think the current patch solves the bug, there are no longer failures to
> terminate threads which is a bug in the implementation.
>
> It sounds like there is a new lower priority bug to clean out the example
> which throws up EXAMPLE_ERR.
>
> If that makes sense I am happy to add reviewed by.
>
Makes sense to me.


>
> On 20 April 2015 at 08:32, Ola Liljedahl  wrote:
>
>> Fixes https://bugs.linaro.org/show_bug.cgi?id=1450
>>
>> Signed-off-by: Ola Liljedahl 
>>
>
> Tested-
>
>
>> ---
>> (This document/code contribution attached is provided under the terms of
>> agreement LES-LTM-21309)
>>
>>  example/timer/odp_timer_test.c | 38
>> ++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/example/timer/odp_timer_test.c
>> b/example/timer/odp_timer_test.c
>> index 6b60ec4..fd31466 100644
>> --- a/example/timer/odp_timer_test.c
>> +++ b/example/timer/odp_timer_test.c
>> @@ -79,6 +79,41 @@ struct test_timer {
>>  static struct test_timer tt[256];
>>
>>  /** @private test timeout */
>> +static void free_event(odp_event_t ev)
>> +{
>> +   switch (odp_event_type(ev)) {
>> +   case ODP_EVENT_BUFFER:
>> +   odp_buffer_free(odp_buffer_from_event(ev));
>> +   break;
>> +   case ODP_EVENT_PACKET:
>> +   odp_packet_free(odp_packet_from_event(ev));
>> +   break;
>> +   case ODP_EVENT_TIMEOUT:
>> +   odp_timeout_free(odp_timeout_from_event(ev));
>> +   break;
>> +   case ODP_EVENT_CRYPTO_COMPL:
>> +   odp_crypto_compl_free(odp_crypto_compl_from_event(ev));
>> +   break;
>> +   default:
>> +   fprintf(stderr, "Unrecognized event type %d\n",
>> +   odp_event_type(ev));
>> +   abort();
>> +   }
>> +}
>> +
>> +/** @private test timeout */
>> +static void remove_prescheduled_events(void)
>> +{
>> +   odp_event_t ev;
>> +   odp_queue_t queue;
>> +   odp_schedule_pause();
>> +   while ((ev = odp_schedule(&queue, ODP_SCHED_NO_WAIT)) !=
>> +   ODP_EVENT_INVALID) {
>> +   free_event(ev);
>> +   }
>> +}
>> +
>> +/** @private test timeout */
>>  static void test_abs_timeouts(int thr, test_args_t *args)
>>  {
>> uint64_t period;
>> @@ -173,6 +208,9 @@ static void test_abs_timeouts(int thr, test_args_t
>> *args)
>> /* Since we have cancelled the timer, there is no timeout event to
>>  * return from odp_timer_free() */
>> (void)odp_timer_free(ttp->tim);
>> +
>> +   /* Remove any prescheduled events */
>> +   remove_prescheduled_events();
>>  }
>>
>>
>> --
>> 1.9.1
>>
>> ___
>> 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] [PATCHv3] example: ODP classifier example


Bala, one more comment. Please do parsing arguments before odp init.


About this code Mike found that it will be abort if you do not run it 
under root due to

unable do raw socket operations.


pktio = odp_pktio_open(dev, pool);
if (pktio == ODP_PKTIO_INVALID)
EXAMPLE_ABORT("pktio create failed for %s\n", dev);

I tried "loop" application starts well. But needed some traffic so that 
loop is no good fit.
I think it's better to exit from this app with some return code and add 
small note to
Usage that for linux-generic user has to be root to open real devices in 
raw mode.


Thanks,
Maxim.

On 04/16/15 14:41, bala.manoha...@linaro.org wrote:

From: Balasubramanian Manoharan 

ODP Classifier example

This programs gets pmr rules as command-line parameter and configures the 
classification engine
in the system.

This initial version supports the following
* ODP_PMR_SIP_ADDR pmr term
* PMR term MATCH and RANGE type
* Multiple PMR rule can be set on a single pktio interface with different 
queues associated to each PMR rule
* Automatically configures a default queue and provides statistics for the same

Signed-off-by: Balasubramanian Manoharan 
---
V3: Incorporates review comments from Mike and Maxim
Adds a timeout variable to configure the time in seconds for classifier example 
to run.

  configure.ac|   1 +
  example/Makefile.am |   2 +-
  example/classifier/Makefile.am  |  10 +
  example/classifier/odp_classifier.c | 820 
  4 files changed, 832 insertions(+), 1 deletion(-)
  create mode 100644 example/classifier/Makefile.am
  create mode 100644 example/classifier/odp_classifier.c

diff --git a/configure.ac b/configure.ac
index 78ff245..d20bad2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
  AC_CONFIG_FILES([Makefile
 doc/Makefile
 example/Makefile
+example/classifier/Makefile
 example/generator/Makefile
 example/ipsec/Makefile
 example/packet/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 6bb4f5c..353f397 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec packet timer
+SUBDIRS = classifier generator ipsec packet timer
diff --git a/example/classifier/Makefile.am b/example/classifier/Makefile.am
new file mode 100644
index 000..938f094
--- /dev/null
+++ b/example/classifier/Makefile.am
@@ -0,0 +1,10 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_classifier
+odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
+odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_classifier_SOURCES = odp_classifier.c
diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
new file mode 100644
index 000..85b6e00
--- /dev/null
+++ b/example/classifier/odp_classifier.c
@@ -0,0 +1,820 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** @def MAX_WORKERS
+ * @brief Maximum number of worker threads
+ */
+#define MAX_WORKERS32
+
+/** @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_PMR_COUNT
+ * @brief Maximum number of Classification Policy
+ */
+#define MAX_PMR_COUNT  8
+
+/** @def DISPLAY_STRING_LEN
+ * @brief Length of string used to display term value
+ */
+#define DISPLAY_STRING_LEN 32
+
+/** Get rid of path in filename - only for unix-type paths using '/' */
+#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
+   strrchr((file_name), '/') + 1 : (file_name))
+
+typedef struct {
+   odp_queue_t queue;  /**< Associated queue handle */
+   odp_cos_t cos;  /**< Associated cos handle */
+   odp_pmr_t pmr;  /**< Associated pmr handle */
+   odp_atomic_u64_t packet_count;  /**< count of received packets */
+   odp_pmr_term_e term;/**< odp pmr term value */
+   char queue_name[ODP_QUEUE_NAME_LEN];/**< queue name */
+   odp_pmr_match_type_e match_type;/**< pmr match type */
+   int val_sz; /**< size of the pmr term */
+   union {
+   struct {
+   uint32_t val;   /**< pmr term value */
+   uint32_t mask;  /**< pmr term mask */
+   } match;
+   struct  {
+   uint32_t val1;  /**< pmr term start range */
+   uint32_t val2;  /**< pmr term end range */
+

Re: [lng-odp] [PATCH] example: timer: clean up prescheduled events

On 20 April 2015 at 08:32, Ola Liljedahl  wrote:

> Fixes https://bugs.linaro.org/show_bug.cgi?id=1450
>
> Signed-off-by: Ola Liljedahl 
>

Reviewed-by: Mike Holmes 


> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
>
>  example/timer/odp_timer_test.c | 38 ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/example/timer/odp_timer_test.c
> b/example/timer/odp_timer_test.c
> index 6b60ec4..fd31466 100644
> --- a/example/timer/odp_timer_test.c
> +++ b/example/timer/odp_timer_test.c
> @@ -79,6 +79,41 @@ struct test_timer {
>  static struct test_timer tt[256];
>
>  /** @private test timeout */
> +static void free_event(odp_event_t ev)
> +{
> +   switch (odp_event_type(ev)) {
> +   case ODP_EVENT_BUFFER:
> +   odp_buffer_free(odp_buffer_from_event(ev));
> +   break;
> +   case ODP_EVENT_PACKET:
> +   odp_packet_free(odp_packet_from_event(ev));
> +   break;
> +   case ODP_EVENT_TIMEOUT:
> +   odp_timeout_free(odp_timeout_from_event(ev));
> +   break;
> +   case ODP_EVENT_CRYPTO_COMPL:
> +   odp_crypto_compl_free(odp_crypto_compl_from_event(ev));
> +   break;
> +   default:
> +   fprintf(stderr, "Unrecognized event type %d\n",
> +   odp_event_type(ev));
> +   abort();
> +   }
> +}
> +
> +/** @private test timeout */
> +static void remove_prescheduled_events(void)
> +{
> +   odp_event_t ev;
> +   odp_queue_t queue;
> +   odp_schedule_pause();
> +   while ((ev = odp_schedule(&queue, ODP_SCHED_NO_WAIT)) !=
> +   ODP_EVENT_INVALID) {
> +   free_event(ev);
> +   }
> +}
> +
> +/** @private test timeout */
>  static void test_abs_timeouts(int thr, test_args_t *args)
>  {
> uint64_t period;
> @@ -173,6 +208,9 @@ static void test_abs_timeouts(int thr, test_args_t
> *args)
> /* Since we have cancelled the timer, there is no timeout event to
>  * return from odp_timer_free() */
> (void)odp_timer_free(ttp->tim);
> +
> +   /* Remove any prescheduled events */
> +   remove_prescheduled_events();
>  }
>
>
> --
> 1.9.1
>
> ___
> 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] Atomics

On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin 
wrote:

> Hello every one,
>
> I am currently working on porting the linux-generic implementation of DPDK
> on Kalray architecture and slightly pulling my hair out with all the
> atomics.
>
Surely you mean ODP and not DPDK?


> By going through the code I noticed that there are a *lot* of functions
> for atomics that do almost the same thing but not exactly.
>
The differences are quite important here...
The public odp/atomic.h uses a relaxed memory model so only suitable for
things like statistics and shared sequence numbers etc.
The internal atomics support supports a memory ordering parameter which
make these functions usable for designing lock-less multithreaded data
structures (and the implementation of the locks themselves). As it is not
supposed that the user will design their own lock-less data structures,
this API is internal to linux-generic (and thus may not exist on all
platforms).


> Fox example in include/odp/atomic.h, all the load/store/add/sub function
> are defined using GCC builtins, but almost the same functions (adding the
> memory model as a parameters)  are also defined in odp_atomic_internal.h
> Wouldn't it make sense to reuse these internals functions in atomic.h so
> there is only one place where we rely on "external" atomic features?
>
Yes I agree. The internal functions have their names prepended with an "_"
so it should be obvious to the user that those are not part of the public
API. odp_atomic_inteŕnal.h must then become part of the ODP release (for
linux-generic). Patch?


>
> The reason behind this is that our GCC does not support all the atomic
> builtins yet and I'd rather factor some code than reimplement the same
> atomic functions all over the place :)
>
> Also, odp_atomic_internal.h defined the _odp_atomic_flag_t and the
> associated lock/release helpers.
> But the type is not used for odp_spin_lock, and neither the type nor the
> helpers are used for odp_atomic_u64_t when GCC does not support 64b atomic
> operations.
> Is there a reason for that?
>
Probably because odp_atomic_flag was introduced after odp_spin_lock was
implemented. One could use odp_atomic_flag in the vanilla spin lock
implementation.

I am not that happy with the emulated odp_atomic_u64 implementation. Using
a lock per atomic variable increases the size of the variable which may
cause consequences down the line. An alternative would be to use a separate
fixed-size array of (spin) locks and map each odp_atomic_u64 variable to
one of the locks using e.g. a simple hash function. The question is which
architectures in practice will need the emulated support (PPC32 is one),
most of the networking world is already 64-bit (and 32-bit ARMv7 supports
64-bit atomic operations).


> Regards
>
>
> --
> Nicolas Morey Chaisemartin
> Phone : +33 6 42 46 68 87
>
> ___
> 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] [PATCHv3] example: ODP classifier example

On 21 April 2015 at 13:27, Maxim Uvarov  wrote:

> Bala, one more comment. Please do parsing arguments before odp init.
>
>
> About this code Mike found that it will be abort if you do not run it
> under root due to
> unable do raw socket operations.
>
What error code do you get from Linux? EPERM?

>
>
> pktio = odp_pktio_open(dev, pool);
> if (pktio == ODP_PKTIO_INVALID)
> EXAMPLE_ABORT("pktio create failed for %s\n", dev);
>
Here could be a check for odp_errno() == EPERM (or which is the actual
error code return in this situation).

odp_pktio_open() must store the Linux errno in the ODP errno variable.


> I tried "loop" application starts well. But needed some traffic so that
> loop is no good fit.
> I think it's better to exit from this app with some return code and add
> small note to
> Usage that for linux-generic user has to be root to open real devices in
> raw mode.
>
> Thanks,
> Maxim.
>
> On 04/16/15 14:41, bala.manoha...@linaro.org wrote:
>
>> From: Balasubramanian Manoharan 
>>
>> ODP Classifier example
>>
>> This programs gets pmr rules as command-line parameter and configures the
>> classification engine
>> in the system.
>>
>> This initial version supports the following
>> * ODP_PMR_SIP_ADDR pmr term
>> * PMR term MATCH and RANGE type
>> * Multiple PMR rule can be set on a single pktio interface with different
>> queues associated to each PMR rule
>> * Automatically configures a default queue and provides statistics for
>> the same
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> V3: Incorporates review comments from Mike and Maxim
>> Adds a timeout variable to configure the time in seconds for classifier
>> example to run.
>>
>>   configure.ac|   1 +
>>   example/Makefile.am |   2 +-
>>   example/classifier/Makefile.am  |  10 +
>>   example/classifier/odp_classifier.c | 820
>> 
>>   4 files changed, 832 insertions(+), 1 deletion(-)
>>   create mode 100644 example/classifier/Makefile.am
>>   create mode 100644 example/classifier/odp_classifier.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78ff245..d20bad2 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
>>   AC_CONFIG_FILES([Makefile
>>  doc/Makefile
>>  example/Makefile
>> +example/classifier/Makefile
>>  example/generator/Makefile
>>  example/ipsec/Makefile
>>  example/packet/Makefile
>> diff --git a/example/Makefile.am b/example/Makefile.am
>> index 6bb4f5c..353f397 100644
>> --- a/example/Makefile.am
>> +++ b/example/Makefile.am
>> @@ -1 +1 @@
>> -SUBDIRS = generator ipsec packet timer
>> +SUBDIRS = classifier generator ipsec packet timer
>> diff --git a/example/classifier/Makefile.am
>> b/example/classifier/Makefile.am
>> new file mode 100644
>> index 000..938f094
>> --- /dev/null
>> +++ b/example/classifier/Makefile.am
>> @@ -0,0 +1,10 @@
>> +include $(top_srcdir)/example/Makefile.inc
>> +
>> +bin_PROGRAMS = odp_classifier
>> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
>> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
>> +
>> +noinst_HEADERS = \
>> + $(top_srcdir)/example/example_debug.h
>> +
>> +dist_odp_classifier_SOURCES = odp_classifier.c
>> diff --git a/example/classifier/odp_classifier.c
>> b/example/classifier/odp_classifier.c
>> new file mode 100644
>> index 000..85b6e00
>> --- /dev/null
>> +++ b/example/classifier/odp_classifier.c
>> @@ -0,0 +1,820 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/** @def MAX_WORKERS
>> + * @brief Maximum number of worker threads
>> + */
>> +#define MAX_WORKERS32
>> +
>> +/** @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_PMR_COUNT
>> + * @brief Maximum number of Classification Policy
>> + */
>> +#define MAX_PMR_COUNT  8
>> +
>> +/** @def DISPLAY_STRING_LEN
>> + * @brief Length of string used to display term value
>> + */
>> +#define DISPLAY_STRING_LEN 32
>> +
>> +/** Get rid of path in filename - only for unix-type paths using '/' */
>> +#define NO_PATH(file_name) (strrchr((file_name), '/') ? \
>> +   strrchr((file_name), '/') + 1 : (file_name))
>> +
>> +typedef struct {
>> +   odp_queue_t queue;  /**< Associated queue handle */
>> +   odp_cos_t cos;  /**< Associated cos handle */
>> +   odp_pmr_t pmr;  /**< Associated pmr handle */
>> +

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

On 20 April 2015 at 21:49, Bill Fischofer  wrote:

> Classification is a collaboration between the implementation and the
> application.  It is the application's responsibility to write unambiguous
> classification rules and it is the implementation's job to perform the
> match as efficiently and as specifically as possible.
>
What should an implementation do if the classification rules are ambiguous?
E.g. if partial matches (of different partially overlapping rules) use
different CoS? Is this an error already when creating the PMR rules?

-- Ola


> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl 
> wrote:
>
>> On 17 April 2015 at 22:55, Rosenboim, Leonid <
>> leonid.rosenb...@caviumnetworks.com> wrote:
>>
>>>
>>> Guys,
>>>
>>> There are several versions of the Classifier API document floating in
>>> Google docs, here is one such copy:
>>>
>>>
>>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
>>>
>>> Here is a different perspective on what PMR and COS mean,  perhaps in
>>> terms of an abstract hardware implementation:
>>>
>>> CoS is a meta-data field assigned to each packet as it traverses the
>>> classifier pipe-line.
>>>
>>> A packet is assigned an initial CoS by the pktio port which received it.
>>>
>>> Then, the packet is compared multiple times against a set of rules, and
>>> as it is common with TCAMs, each comparisons happens against all rules in
>>> parallel.
>>>
>>> Each rule has two values to match: 1. the current CoS meta-data field;
>>> and 2. a certain packet header field (value with a mask).
>>> If both these values match, the packet met-data CoS field is changed
>>> (Action taken) with the destination CoS of the matching rule.
>>>
>>> It is assumed that up to  one such rule has matched.
>>>
>>> If a rule has matched, CoS has changed, the process continues one more
>>> time.
>>>
>>> If NO MATCH occured, the classification process is finished, and the
>>> packet is delivered in accordance to the current CoS (i.e. the last
>>> matching rule or the pktio default CoS if the first rule match failed).
>>>
>> So partial matches are valid. Is this what we want, e.g. from application
>> point of view and from HW point of view?
>>
>> Is partial matches what is commonly supported by HW classifiers?
>>
>> A classifier which supports these longest prefix matches can easily
>> implement perfect matching (all partial matches just specify the "default"
>> CoS). But a classifier which only supports perfect matching cannot directly
>> support partial matches. I assume you would have to internally create
>> rules/patterns for all (relevant) partial matches as well. The
>> implementation can find all relevant partial matches (prefix rules which
>> specify a CoS different from the default CoS) and add those to the list of
>> rules. Longer prefix matches should be prioritized (however that is done)
>> over shorter prefix matches.
>>
>> The reason I really want to understand the required semantics is that I
>> am planning to design an optimized parser/classifier in SW. Pointer-chasing
>> is a no-no, performance will come from cache-friendly access pattern and
>> some kind of parallelism (e.g. SIMD). I don't know how good it can get.
>>
>>
>>
>>> According to CoS, the packet buffer pool and the destination queue are
>>> selected, and the packet is ready for application processing.
>>>
>>> Here are some additional observations with regads to use of CoS values:
>>>
>>> Multiple pktio may assign the same CoS initially. (eaming many pktio to
>>> one CoS)
>>>
>>> Multple rules can assign the same CoS as destination (action). (meaning
>>> multuple PMR to one destination CoS).
>>>
>>> Regarding the source CoS of a PMR, I can not rule out a PMR that can
>>> match multiple CoS values (that is creating a many-to-many src-CoS to PMR
>>> relationship), but this scheme seems problematic for ease of use as well as
>>> implementation, so I would recommend to assume that each PMR should only
>>> have a single source CoS.
>>>
>>> Multiple PMRs may have the same source-CoS, but different header fields
>>> ot value/mask (creating an OR  combination of PMRs).
>>>
>>> I felt that I had to take this discussion ina completely different
>>> direction to avoid infinite recursion ;-)
>>>
>>> Good weekend all,
>>>
>>> - Leo
>>>
>>>
>>>
>>> ___
>>> 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] Atomics

2015-04-21 Thread Nicolas Morey-Chaisemartin


On 04/21/2015 01:31 PM, Ola Liljedahl wrote:
> On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin  > wrote:
>
> Hello every one,
>
> I am currently working on porting the linux-generic implementation of 
> DPDK on Kalray architecture and slightly pulling my hair out with all the 
> atomics.
>
> Surely you mean ODP and not DPDK?

Yes sorry. I was looking at the ODP-DPDK sources too and got mixed up.

>  
>
> By going through the code I noticed that there are a *lot* of functions 
> for atomics that do almost the same thing but not exactly.
>
> The differences are quite important here...
> The public odp/atomic.h uses a relaxed memory model so only suitable for 
> things like statistics and shared sequence numbers etc.
> The internal atomics support supports a memory ordering parameter which make 
> these functions usable for designing lock-less multithreaded data structures 
> (and the implementation of the locks themselves). As it is not supposed that 
> the user will design their own lock-less data structures, this API is 
> internal to linux-generic (and thus may not exist on all platforms).

OK

>
>
> Fox example in include/odp/atomic.h, all the load/store/add/sub function 
> are defined using GCC builtins, but almost the same functions (adding the 
> memory model as a parameters)  are also defined in odp_atomic_internal.h
> Wouldn't it make sense to reuse these internals functions in atomic.h so 
> there is only one place where we rely on "external" atomic features?
>
> Yes I agree. The internal functions have their names prepended with an "_" so 
> it should be obvious to the user that those are not part of the public API. 
> odp_atomic_inteŕnal.h must then become part of the ODP release (for 
> linux-generic). Patch?

I am not sure where the odp_atomic_internal should be moved (I'm still learning 
where things are supposed to be and why), but with some guidelines, I'd be 
happy to propose a patch for this.


Thanks for the info

Nicolas

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

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

Behavior is undefined if rules are ambiguous.  Consider the following rules:

protocol == UDP --> CoS A
port == 1234 --> CoS B

What happens if a UDP packet for port 1234 arrives?  Answer: undefined.
The result may be either CoS A or CoS B.

A better rule set would be:

protocol == UDP --> CoS A

CoS A && port == 1234 --> CoS B

Now this is unambiguous.  UDP packets go to CoS A unless they also specify
port 1234, in which case they go to CoS B.

On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl 
wrote:

> On 20 April 2015 at 21:49, Bill Fischofer 
> wrote:
>
>> Classification is a collaboration between the implementation and the
>> application.  It is the application's responsibility to write unambiguous
>> classification rules and it is the implementation's job to perform the
>> match as efficiently and as specifically as possible.
>>
> What should an implementation do if the classification rules are
> ambiguous? E.g. if partial matches (of different partially overlapping
> rules) use different CoS? Is this an error already when creating the PMR
> rules?
>
> -- Ola
>
>
>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl 
>> wrote:
>>
>>> On 17 April 2015 at 22:55, Rosenboim, Leonid <
>>> leonid.rosenb...@caviumnetworks.com> wrote:
>>>

 Guys,

 There are several versions of the Classifier API document floating in
 Google docs, here is one such copy:

 https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing

 Here is a different perspective on what PMR and COS mean,  perhaps in
 terms of an abstract hardware implementation:

 CoS is a meta-data field assigned to each packet as it traverses the
 classifier pipe-line.

 A packet is assigned an initial CoS by the pktio port which received it.

 Then, the packet is compared multiple times against a set of rules, and
 as it is common with TCAMs, each comparisons happens against all rules in
 parallel.

 Each rule has two values to match: 1. the current CoS meta-data field;
 and 2. a certain packet header field (value with a mask).
 If both these values match, the packet met-data CoS field is changed
 (Action taken) with the destination CoS of the matching rule.

 It is assumed that up to  one such rule has matched.

 If a rule has matched, CoS has changed, the process continues one more
 time.

 If NO MATCH occured, the classification process is finished, and the
 packet is delivered in accordance to the current CoS (i.e. the last
 matching rule or the pktio default CoS if the first rule match failed).

>>> So partial matches are valid. Is this what we want, e.g. from
>>> application point of view and from HW point of view?
>>>
>>> Is partial matches what is commonly supported by HW classifiers?
>>>
>>> A classifier which supports these longest prefix matches can easily
>>> implement perfect matching (all partial matches just specify the "default"
>>> CoS). But a classifier which only supports perfect matching cannot directly
>>> support partial matches. I assume you would have to internally create
>>> rules/patterns for all (relevant) partial matches as well. The
>>> implementation can find all relevant partial matches (prefix rules which
>>> specify a CoS different from the default CoS) and add those to the list of
>>> rules. Longer prefix matches should be prioritized (however that is done)
>>> over shorter prefix matches.
>>>
>>> The reason I really want to understand the required semantics is that I
>>> am planning to design an optimized parser/classifier in SW. Pointer-chasing
>>> is a no-no, performance will come from cache-friendly access pattern and
>>> some kind of parallelism (e.g. SIMD). I don't know how good it can get.
>>>
>>>
>>>
 According to CoS, the packet buffer pool and the destination queue are
 selected, and the packet is ready for application processing.

 Here are some additional observations with regads to use of CoS values:

 Multiple pktio may assign the same CoS initially. (eaming many pktio to
 one CoS)

 Multple rules can assign the same CoS as destination (action). (meaning
 multuple PMR to one destination CoS).

 Regarding the source CoS of a PMR, I can not rule out a PMR that can
 match multiple CoS values (that is creating a many-to-many src-CoS to PMR
 relationship), but this scheme seems problematic for ease of use as well as
 implementation, so I would recommend to assume that each PMR should only
 have a single source CoS.

 Multiple PMRs may have the same source-CoS, but different header fields
 ot value/mask (creating an OR  combination of PMRs).

 I felt that I had to take this discussion ina completely different
 direction to avoid infinite recursion ;-)

 Good weekend all,

 - Leo

 ___

Re: [lng-odp] Atomics

On 21 April 2015 at 14:01, Nicolas Morey-Chaisemartin 
wrote:

>
> On 04/21/2015 01:31 PM, Ola Liljedahl wrote:
>
>  On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin <
> nmo...@kalray.eu> wrote:
>
>> Hello every one,
>>
>> I am currently working on porting the linux-generic implementation of
>> DPDK on Kalray architecture and slightly pulling my hair out with all the
>> atomics.
>>
> Surely you mean ODP and not DPDK?
>
>
> Yes sorry. I was looking at the ODP-DPDK sources too and got mixed up.
>
>
>
>> By going through the code I noticed that there are a *lot* of functions
>> for atomics that do almost the same thing but not exactly.
>>
> The differences are quite important here...
> The public odp/atomic.h uses a relaxed memory model so only suitable for
> things like statistics and shared sequence numbers etc.
> The internal atomics support supports a memory ordering parameter which
> make these functions usable for designing lock-less multithreaded data
> structures (and the implementation of the locks themselves). As it is not
> supposed that the user will design their own lock-less data structures,
> this API is internal to linux-generic (and thus may not exist on all
> platforms).
>
>
> OK
>
>
>
>> Fox example in include/odp/atomic.h, all the load/store/add/sub function
>> are defined using GCC builtins, but almost the same functions (adding the
>> memory model as a parameters)  are also defined in odp_atomic_internal.h
>> Wouldn't it make sense to reuse these internals functions in atomic.h so
>> there is only one place where we rely on "external" atomic features?
>>
> Yes I agree. The internal functions have their names prepended with an "_"
> so it should be obvious to the user that those are not part of the public
> API. odp_atomic_inteŕnal.h must then become part of the ODP release (for
> linux-generic). Patch?
>
>
> I am not sure where the odp_atomic_internal should be moved (I'm still
> learning where things are supposed to be and why), but with some
> guidelines, I'd be happy to propose a patch for this.
>
If the public odp/atomic.h references functions defined in
odp_atomic_internal.h, then that header file must also be included in the
files that are installed by "make install". I don't know if this influences
the location of odp_atomic_internal.h in the ODP source structure. Maybe
the makefiles can grab files (to be installed) from anywhere. Maxim, Anders?


>
> Thanks for the info
>
> Nicolas
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

On 04/21/15 15:01, Bill Fischofer wrote:
Behavior is undefined if rules are ambiguous. Consider the following
rules:

protocol == UDP --> CoS A
port == 1234 --> CoS B

What happens if a UDP packet for port 1234 arrives? Answer: undefined.

Isn't pmr created one by one to the table? And first match will return
Cos A in that case.

Maxim.

The result may be either CoS A or CoS B.

A better rule set would be:

protocol == UDP --> CoS A

CoS A && port == 1234 --> CoS B

Now this is unambiguous. UDP packets go to CoS A unless they also
specify port 1234, in which case they go to CoS B.

On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl
mailto:ola.liljed...@linaro.org>> wrote:

On 20 April 2015 at 21:49, Bill Fischofer
mailto:bill.fischo...@linaro.org>> wrote:

Classification is a collaboration between the implementation
and the application. It is the application's responsibility to
write unambiguous classification rules and it is the
implementation's job to perform the match as efficiently and
as specifically as possible.

What should an implementation do if the classification rules are
ambiguous? E.g. if partial matches (of different partially
overlapping rules) use different CoS? Is this an error already
when creating the PMR rules?

-- Ola

On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
mailto:ola.liljed...@linaro.org>>
wrote:

On 17 April 2015 at 22:55, Rosenboim, Leonid
mailto:leonid.rosenb...@caviumnetworks.com>> wrote:

Guys,

There are several versions of the Classifier API
document floating in Google docs, here is one such copy:

https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing

Here is a different perspective on what PMR and COS
mean, perhaps in terms of an abstract hardware
implementation:

CoS is a meta-data field assigned to each packet as it
traverses the classifier pipe-line.

A packet is assigned an initial CoS by the pktio port
which received it.

Then, the packet is compared multiple times against a
set of rules, and as it is common with TCAMs, each
comparisons happens against all rules in parallel.

Each rule has two values to match: 1. the current CoS
meta-data field; and 2. a certain packet header field
(value with a mask).
If both these values match, the packet met-data CoS
field is changed (Action taken) with the destination
CoS of the matching rule.

It is assumed that up to one such rule has matched.

If a rule has matched, CoS has changed, the process
continues one more time.

If NO MATCH occured, the classification process is
finished, and the packet is delivered in accordance to
the current CoS (i.e. the last matching rule or the
pktio default CoS if the first rule match failed).

So partial matches are valid. Is this what we want, e.g.
from application point of view and from HW point of view?

Is partial matches what is commonly supported by HW
classifiers?

A classifier which supports these longest prefix matches
can easily implement perfect matching (all partial matches
just specify the "default" CoS). But a classifier which
only supports perfect matching cannot directly support
partial matches. I assume you would have to internally
create rules/patterns for all (relevant) partial matches
as well. The implementation can find all relevant partial
matches (prefix rules which specify a CoS different from
the default CoS) and add those to the list of rules.
Longer prefix matches should be prioritized (however that
is done) over shorter prefix matches.

The reason I really want to understand the required
semantics is that I am planning to design an optimized
parser/classifier in SW. Pointer-chasing is a no-no,
performance will come from cache-friendly access pattern
and some kind of parallelism (e.g. SIMD). I don't know how
good it can get.

According to CoS, the packet buffer pool and the
destination queue are selected, and the packet is
ready for application processing.

Here are some additional observations with regads to
use of CoS values:

Multiple pktio may assign the same CoS initially.
(eaming many pktio to one CoS)

Re: [lng-odp] [PATCH API-NEXT 5/5] api: packet_io: added start and stop

2015-04-21 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Maxim Uvarov
> Sent: Tuesday, April 21, 2015 1:39 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH API-NEXT 5/5] api: packet_io: added start
> and stop
> 
> On 04/20/15 15:10, Petri Savolainen wrote:
> > Packet IO start and stop enable a controlled setup and
> > tear down phases.
> >
> > Interface control sequence:
> > * odp_pktio_open() creates a pktio interface object
> > * potential interface configurations (classification, input queues, etc)
> > * odp_pktio_start() enables packet input/output
> > * receive / transmit packets
> > * odp_pktio_stop() disables packet input/output
> > * drain remaining packets from queues
> > * remove / destroy input queues
> > * odp_pktio_close() destroys the pktio interface object
> 
> Petri that is also needed to remove locks inside pktio, right? For
> example odp_pktio_inq_remdef()
> should be called only after odp_pktio_stop(), right?
> 
> Thanks,
> Maxim.

Yes, initially we could specify that pktio interface configuration (including 
classification) can be changed only when the interface is "stopped".

Later on some exceptions could be defined to that - e.g. how classification 
rules can be modified when an interface is active.

-Petri


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

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

On 21 April 2015 at 14:26, Maxim Uvarov  wrote:

> On 04/21/15 15:01, Bill Fischofer wrote:
>
>> Behavior is undefined if rules are ambiguous. Consider the following
>> rules:
>>
>> protocol == UDP --> CoS A
>> port == 1234 --> CoS B
>>
>> What happens if a UDP packet for port 1234 arrives? Answer: undefined.
>>
>
>
> Isn't pmr created one by one to the table? And first match will return Cos
> A in that case.
>
Since we are having this discussion, it is obvious that we need a
definition of the ODP classification that cannot be misunderstood or
misinterpreted. Probably a formal definition. Or do everyone here agree
that the (current) linux-generic implementation can serve as *the*
definition?




>
> Maxim.
>
>  The result may be either CoS A or CoS B.
>>
>> A better rule set would be:
>>
>> protocol == UDP --> CoS A
>>
>> CoS A && port == 1234 --> CoS B
>>
>> Now this is unambiguous.  UDP packets go to CoS A unless they also
>> specify port 1234, in which case they go to CoS B.
>>
>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl > > wrote:
>>
>> On 20 April 2015 at 21:49, Bill Fischofer
>> mailto:bill.fischo...@linaro.org>> wrote:
>>
>> Classification is a collaboration between the implementation
>> and the application. It is the application's responsibility to
>> write unambiguous classification rules and it is the
>> implementation's job to perform the match as efficiently and
>> as specifically as possible.
>>
>> What should an implementation do if the classification rules are
>> ambiguous? E.g. if partial matches (of different partially
>> overlapping rules) use different CoS? Is this an error already
>> when creating the PMR rules?
>>
>> -- Ola
>>
>>
>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
>> mailto:ola.liljed...@linaro.org>>
>> wrote:
>>
>> On 17 April 2015 at 22:55, Rosenboim, Leonid
>> > > wrote:
>>
>>
>> Guys,
>>
>> There are several versions of the Classifier API
>> document floating in Google docs, here is one such copy:
>>
>>
>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
>>
>> Here is a different perspective on what PMR and COS
>> mean,  perhaps in terms of an abstract hardware
>> implementation:
>>
>> CoS is a meta-data field assigned to each packet as it
>> traverses the classifier pipe-line.
>>
>> A packet is assigned an initial CoS by the pktio port
>> which received it.
>>
>> Then, the packet is compared multiple times against a
>> set of rules, and as it is common with TCAMs, each
>> comparisons happens against all rules in parallel.
>>
>> Each rule has two values to match: 1. the current CoS
>> meta-data field; and 2. a certain packet header field
>> (value with a mask).
>> If both these values match, the packet met-data CoS
>> field is changed (Action taken) with the destination
>> CoS of the matching rule.
>>
>> It is assumed that up to one such rule has matched.
>>
>> If a rule has matched, CoS has changed, the process
>> continues one more time.
>>
>> If NO MATCH occured, the classification process is
>> finished, and the packet is delivered in accordance to
>> the current CoS (i.e. the last matching rule or the
>> pktio default CoS if the first rule match failed).
>>
>> So partial matches are valid. Is this what we want, e.g.
>> from application point of view and from HW point of view?
>>
>> Is partial matches what is commonly supported by HW
>> classifiers?
>>
>> A classifier which supports these longest prefix matches
>> can easily implement perfect matching (all partial matches
>> just specify the "default" CoS). But a classifier which
>> only supports perfect matching cannot directly support
>> partial matches. I assume you would have to internally
>> create rules/patterns for all (relevant) partial matches
>> as well. The implementation can find all relevant partial
>> matches (prefix rules which specify a CoS different from
>> the default CoS) and add those to the list of rules.
>> Longer prefix matches should be prioritized (however that
>> is done) over shorter prefix matches.
>>
>> The reason I really want to understand the required
>> semantics is that I am planning to design an optimized
>>

Re: [lng-odp] [PATCHv3] example: ODP classifier example

2015-04-21 Thread Bala Manoharan

On 21 April 2015 at 16:57, Maxim Uvarov  wrote:
> Bala, one more comment. Please do parsing arguments before odp init.
>
>
> About this code Mike found that it will be abort if you do not run it under
> root due to
> unable do raw socket operations.
>
>
> pktio = odp_pktio_open(dev, pool);
> if (pktio == ODP_PKTIO_INVALID)
> EXAMPLE_ABORT("pktio create failed for %s\n", dev);


The abort in this case if because the EXAMPLE_ABORT macro implements
abort() function instead of exit(EXIT_FAILURE)
IMO calling exit is better as this causes a graceful shutdown of the
system. In any case I believe it is better for the application to call
this macro and the macro definition can implement exit() instead of
abort()

>
> I tried "loop" application starts well. But needed some traffic so that loop
> is no good fit.
> I think it's better to exit from this app with some return code and add
> small note to
> Usage that for linux-generic user has to be root to open real devices in raw
> mode.

I believe the reason we added this macro EXAMPLE_ABORT was to be used
by the application in the scenario when it wants to terminate the
function so that the macro can be modified by different platforms.
We can call usage() to display the usage here but I am against calling
exit() directly in the application
>
> Thanks,
> Maxim.
>
>
> On 04/16/15 14:41, bala.manoha...@linaro.org wrote:
>>
>> From: Balasubramanian Manoharan 
>>
>> ODP Classifier example
>>
>> This programs gets pmr rules as command-line parameter and configures the
>> classification engine
>> in the system.
>>
>> This initial version supports the following
>> * ODP_PMR_SIP_ADDR pmr term
>> * PMR term MATCH and RANGE type
>> * Multiple PMR rule can be set on a single pktio interface with different
>> queues associated to each PMR rule
>> * Automatically configures a default queue and provides statistics for the
>> same
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> V3: Incorporates review comments from Mike and Maxim
>> Adds a timeout variable to configure the time in seconds for classifier
>> example to run.
>>
>>   configure.ac|   1 +
>>   example/Makefile.am |   2 +-
>>   example/classifier/Makefile.am  |  10 +
>>   example/classifier/odp_classifier.c | 820
>> 
>>   4 files changed, 832 insertions(+), 1 deletion(-)
>>   create mode 100644 example/classifier/Makefile.am
>>   create mode 100644 example/classifier/odp_classifier.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78ff245..d20bad2 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -272,6 +272,7 @@ AM_CXXFLAGS="-std=c++11"
>>   AC_CONFIG_FILES([Makefile
>>  doc/Makefile
>>  example/Makefile
>> +example/classifier/Makefile
>>  example/generator/Makefile
>>  example/ipsec/Makefile
>>  example/packet/Makefile
>> diff --git a/example/Makefile.am b/example/Makefile.am
>> index 6bb4f5c..353f397 100644
>> --- a/example/Makefile.am
>> +++ b/example/Makefile.am
>> @@ -1 +1 @@
>> -SUBDIRS = generator ipsec packet timer
>> +SUBDIRS = classifier generator ipsec packet timer
>> diff --git a/example/classifier/Makefile.am
>> b/example/classifier/Makefile.am
>> new file mode 100644
>> index 000..938f094
>> --- /dev/null
>> +++ b/example/classifier/Makefile.am
>> @@ -0,0 +1,10 @@
>> +include $(top_srcdir)/example/Makefile.inc
>> +
>> +bin_PROGRAMS = odp_classifier
>> +odp_classifier_LDFLAGS = $(AM_LDFLAGS) -static
>> +odp_classifier_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
>> +
>> +noinst_HEADERS = \
>> + $(top_srcdir)/example/example_debug.h
>> +
>> +dist_odp_classifier_SOURCES = odp_classifier.c
>> diff --git a/example/classifier/odp_classifier.c
>> b/example/classifier/odp_classifier.c
>> new file mode 100644
>> index 000..85b6e00
>> --- /dev/null
>> +++ b/example/classifier/odp_classifier.c
>> @@ -0,0 +1,820 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/** @def MAX_WORKERS
>> + * @brief Maximum number of worker threads
>> + */
>> +#define MAX_WORKERS32
>> +
>> +/** @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_PMR_COUNT
>> + * @brief Maximum number of Classification Policy
>> + */
>> +#define MAX_PMR_COUNT  8
>> +
>> +/** @def DISPLAY_STRING_LEN
>> + * @brief Length of string used to display term value
>> + */
>> +#define DISPLAY_STRING_LEN 32
>> +
>> +/** Get rid of p

Re: [lng-odp] [API-NEXT PATCHv4 0/6] Add packet user metadata support

2015-04-21 Thread Zoltan Kiss

It seems to me all questions were answered, is there anything which 
prevents applying this into master branch?

Petri?

On 10/04/15 16:52, Bill Fischofer wrote:

v4 changes:
- Removed RFC status, patch is now ready for API-NEXT
- Added implementation of approved APIs
- Added user metadata tests to packet validation test

v3 changes:
- Renamed odp_packet_user_metadata() to odp_packet_user_data()
- Split addr/size return, adding odp_packet_user_data_size()
- Moved udata_size to pkt structure within odp_pool_param_t

v2 changes:
- Moved udata_size to odp_pool_param_t
- Renamed odp_packet_udata() to odp_packet_user_metadata()
- Removed odp_buffer_udata().  User metadata is for packets only

RFC for proposed minimal API set for user metadata support
based on today's discussions.  Note that all initialization
and management of user metadata contents is the responsibility of
the ODP application. ODP APIs that copy system metadata will also
copy any associated user metadata as part of that operation, but
ODP will otherwise ignore these bytes.

Bill Fischofer (6):
   api: packet: add user metadata APIs
   api: pool: add user metadata APIs
   linux-generic: buffer: restructure user mdatadata fields
   linux-generic: pool: add user metadata support
   linux-generic: packet: add user metadata support
   validation: packet: add user metadata tests

  include/odp/api/packet.h   | 20 
  include/odp/api/pool.h |  4 ++
  .../linux-generic/include/odp_buffer_internal.h|  4 +-
  platform/linux-generic/include/odp_pool_internal.h |  2 +-
  platform/linux-generic/odp_packet.c| 34 ++
  platform/linux-generic/odp_pool.c  | 34 +-
  test/validation/odp_packet.c   | 54 ++
  7 files changed, 126 insertions(+), 26 deletions(-)


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

Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation

2015-04-21 Thread Bala Manoharan

On 21 April 2015 at 18:15, Ola Liljedahl  wrote:
> On 21 April 2015 at 14:26, Maxim Uvarov  wrote:
>>
>> On 04/21/15 15:01, Bill Fischofer wrote:
>>>
>>> Behavior is undefined if rules are ambiguous. Consider the following
>>> rules:
>>>
>>> protocol == UDP --> CoS A
>>> port == 1234 --> CoS B
>>>
>>> What happens if a UDP packet for port 1234 arrives? Answer: undefined.
>>
>>
>>
>> Isn't pmr created one by one to the table? And first match will return Cos
>> A in that case.
>
> Since we are having this discussion, it is obvious that we need a definition
> of the ODP classification that cannot be misunderstood or misinterpreted.
> Probably a formal definition. Or do everyone here agree that the (current)
> linux-generic implementation can serve as *the* definition?

Shouldn't we use the classification design document as the definition
of classification and the linux-generic implementation can be used as
a reference and not "the" definition.

Regards,
Bala
>
>
>
>>
>>
>> Maxim.
>>
>>> The result may be either CoS A or CoS B.
>>>
>>> A better rule set would be:
>>>
>>> protocol == UDP --> CoS A
>>>
>>> CoS A && port == 1234 --> CoS B
>>>
>>> Now this is unambiguous.  UDP packets go to CoS A unless they also
>>> specify port 1234, in which case they go to CoS B.
>>>
>>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl >> > wrote:
>>>
>>> On 20 April 2015 at 21:49, Bill Fischofer
>>> mailto:bill.fischo...@linaro.org>> wrote:
>>>
>>> Classification is a collaboration between the implementation
>>> and the application. It is the application's responsibility to
>>> write unambiguous classification rules and it is the
>>> implementation's job to perform the match as efficiently and
>>> as specifically as possible.
>>>
>>> What should an implementation do if the classification rules are
>>> ambiguous? E.g. if partial matches (of different partially
>>> overlapping rules) use different CoS? Is this an error already
>>> when creating the PMR rules?
>>>
>>> -- Ola
>>>
>>>
>>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
>>> mailto:ola.liljed...@linaro.org>>
>>> wrote:
>>>
>>> On 17 April 2015 at 22:55, Rosenboim, Leonid
>>> >> > wrote:
>>>
>>>
>>> Guys,
>>>
>>> There are several versions of the Classifier API
>>> document floating in Google docs, here is one such copy:
>>>
>>>
>>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
>>>
>>> Here is a different perspective on what PMR and COS
>>> mean,  perhaps in terms of an abstract hardware
>>> implementation:
>>>
>>> CoS is a meta-data field assigned to each packet as it
>>> traverses the classifier pipe-line.
>>>
>>> A packet is assigned an initial CoS by the pktio port
>>> which received it.
>>>
>>> Then, the packet is compared multiple times against a
>>> set of rules, and as it is common with TCAMs, each
>>> comparisons happens against all rules in parallel.
>>>
>>> Each rule has two values to match: 1. the current CoS
>>> meta-data field; and 2. a certain packet header field
>>> (value with a mask).
>>> If both these values match, the packet met-data CoS
>>> field is changed (Action taken) with the destination
>>> CoS of the matching rule.
>>>
>>> It is assumed that up to one such rule has matched.
>>>
>>> If a rule has matched, CoS has changed, the process
>>> continues one more time.
>>>
>>> If NO MATCH occured, the classification process is
>>> finished, and the packet is delivered in accordance to
>>> the current CoS (i.e. the last matching rule or the
>>> pktio default CoS if the first rule match failed).
>>>
>>> So partial matches are valid. Is this what we want, e.g.
>>> from application point of view and from HW point of view?
>>>
>>> Is partial matches what is commonly supported by HW
>>> classifiers?
>>>
>>> A classifier which supports these longest prefix matches
>>> can easily implement perfect matching (all partial matches
>>> just specify the "default" CoS). But a classifier which
>>> only supports perfect matching cannot directly support
>>> partial matches. I assume you would have to internally
>>> create rules/patterns for all (relevant) partial matches
>>> as well. The implementation can find all relevant partial
>>> matches (prefix rules which spec

Re: [lng-odp] [RFC API-NEXT PATCH] packet_io: add bitmap to specify what level of parsing needed

2015-04-21 Thread Zoltan Kiss




On 20/04/15 10:36, Ola Liljedahl wrote:

On 20 April 2015 at 11:12, Maxim Uvarov mailto:maxim.uva...@linaro.org>> wrote:

How that supposed to increase performance?

The code will be like:

if (parse_vlan)
 do_parse_vlan
if (parse_ipv4)
 do_parse_ipv4

and etc. I.e. You will add about 20-30 if branches.

That's exactly how you are *not* supposed to implemented the parsing and
that is the coding I wanted to avoid with specifying the layer instead
of individual protocols. But as I then suggested, an implementation can
set the parsing levels based on the individual flags.

if (pktio->parse_layer_2) {
 //Unconditional parsing of Ethernet/VLAN etc
 
 if (pkt->parse_layer_3) {
 //Unconditional parsing of IPv4/IPv6 headers
 
 if (pkt->parse_layer_4) {
  //Unconditional parsing of e.g. UDP/TCP/SCTP headers
 }
 }
}



That would work with a more detailed parsing configuration as well:


if (pktio->eth) &&
   ((pktio->jumbo) || (frame_len < 1524)) &&
   ((pktio->vlan) || (ethertype != 0x8100)) &&
...

And the branch predictor can optimize this out as well.

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

[lng-odp] UberConference Reminder

2015-04-21 Thread UberConference

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

Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse mode

2015-04-21 Thread Zoltan Kiss


Reviewed-by: Zoltan Kiss 

On 20/04/15 13:10, Petri Savolainen wrote:

Application can indicate which packet parsing results it is
interested in (all, none or selected).

Signed-off-by: Petri Savolainen 
---
  include/odp/api/packet_flags.h | 26 ++
  include/odp/api/packet_io.h| 19 +++
  2 files changed, 45 insertions(+)

diff --git a/include/odp/api/packet_flags.h b/include/odp/api/packet_flags.h
index bfbcc94..9444fdc 100644
--- a/include/odp/api/packet_flags.h
+++ b/include/odp/api/packet_flags.h
@@ -26,6 +26,32 @@ extern "C" {
   *  @{
   */

+
+/**
+ * Packet input parsing flags
+ *
+ * Each flag represents a parser output. See parser output functions for
+ * details.
+ */
+typedef struct odp_packet_parse_flags_t {
+   uint32_t eth:1;   /**< See odp_packet_has_eth() */
+   uint32_t jumbo:1; /**< See odp_packet_has_jumbo() */
+   uint32_t vlan:1;  /**< See odp_packet_has_vlan() */
+   uint32_t vlan_qinq:1; /**< See odp_packet_has_vlan_qinq() */
+   uint32_t arp:1;   /**< See odp_packet_has_arp() */
+   uint32_t ipv4:1;  /**< See odp_packet_has_ipv4() */
+   uint32_t ipv6:1;  /**< See odp_packet_has_ipv6() */
+   uint32_t ipfrag:1;/**< See odp_packet_has_ipfrag() */
+   uint32_t ipopt:1; /**< See odp_packet_has_ipopt() */
+   uint32_t ipsec:1; /**< See odp_packet_has_ipsec() */
+   uint32_t udp:1;   /**< See odp_packet_has_udp() */
+   uint32_t tcp:1;   /**< See odp_packet_has_tcp() */
+   uint32_t sctp:1;  /**< See odp_packet_has_sctp() */
+   uint32_t icmp:1;  /**< See odp_packet_has_icmp() */
+
+   uint32_t _reserved1:18; /**< Reserved. Do not use. */
+} odp_packet_parse_flags_t;
+
  /**
   * Check for packet errors
   *
diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 77c207e..97f79ee 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -18,6 +18,8 @@
  extern "C" {
  #endif

+#include 
+
  /** @defgroup odp_packet_io ODP PACKET IO
   *  Operations on a packet.
   *  @{
@@ -58,6 +60,19 @@ enum odp_pktio_input_mode {
  };

  /**
+ * Packet parsing mode
+ */
+enum odp_pktio_parse_mode {
+   /** Parse all protocols */
+   ODP_PKTIN_PARSE_ALL = 0,
+   /** Parsing not needed */
+   ODP_PKTIN_PARSE_NONE,
+   /** Parsing can be limited to the flags set in
+   odp_packet_parse_flags_t */
+   ODP_PKTIN_PARSE_SELECTED
+};
+
+/**
   * Packet IO parameters
   *
   * In minimum, user must select the input mode. Use 0 for defaults. Initialize
@@ -66,6 +81,10 @@ enum odp_pktio_input_mode {
  typedef struct odp_pktio_param_t {
/** Packet input mode */
enum odp_pktio_input_mode in_mode;
+   /** Packet parse mode */
+   enum odp_pktio_parse_mode parse_mode;
+   /** Parse selection when parse_mode is ODP_PKTIN_PARSE_SELECTED */
+   odp_packet_parse_flags_t parse;
  } odp_pktio_param_t;

  /**


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

Re: [lng-odp] [PATCHv3] example: ODP classifier example

On 21 April 2015 at 09:01, Bala Manoharan  wrote:

> On 21 April 2015 at 16:57, Maxim Uvarov  wrote:
> > Bala, one more comment. Please do parsing arguments before odp init.
> >
> >
> > About this code Mike found that it will be abort if you do not run it
> under
> > root due to
> > unable do raw socket operations.
> >
> >
> > pktio = odp_pktio_open(dev, pool);
> > if (pktio == ODP_PKTIO_INVALID)
> > EXAMPLE_ABORT("pktio create failed for %s\n", dev);
>
>
> The abort in this case if because the EXAMPLE_ABORT macro implements
> abort() function instead of exit(EXIT_FAILURE)
> IMO calling exit is better as this causes a graceful shutdown of the
> system. In any case I believe it is better for the application to call
> this macro and the macro definition can implement exit() instead of
> abort()
>
> >
> > I tried "loop" application starts well. But needed some traffic so that
> loop
> > is no good fit.
> > I think it's better to exit from this app with some return code and add
> > small note to
> > Usage that for linux-generic user has to be root to open real devices in
> raw
> > mode.
>
> I believe the reason we added this macro EXAMPLE_ABORT was to be used
> by the application in the scenario when it wants to terminate the
> function so that the macro can be modified by different platforms.
> We can call usage() to display the usage here but I am against calling
> exit() directly in the application
>
>
EXAMPLE_ABORT cant call exit, that would be EXAMPLE_EXIT and there is no
reason not to add one.
As soon as make  check starts to call the examples which it does in my
sandbox having a non root run fault out is ugly. It would be better in my
opinion to wrap this with a script or have it directly return 99 so that
make check knows that it cant run unless you are root and so it reports
"TEST_SKIPPED" rather than an error that is indistinguishable from an
actual error in the test.



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

[lng-odp] [RFC API-NEXT PATCH] IPC version v4

Signed-off-by: Maxim Uvarov 
---
 I'm updating IPC patch version to the latest ODP code here:

 https://git.linaro.org/people/maxim.uvarov/odp.git odp_ipc_v4

 And found that it will be good to add more parameters to pool_create().
 For example I need to pass there flag about shared memory. Can that be 
accepted?

 That is not final version of patch and platform/linux-generic/odp_ipc.c will
 be moved to platform/linux-generic/include/odp_pktio_ipc_internal.h.

 But if somebody also started look at IPC I think it's reasonable to look at 
this patch.

 Thanks,
 Maxim.

 configure.ac   |   1 +
 example/Makefile.am|   2 +-
 example/ipc/.gitignore |   1 +
 example/ipc/Makefile.am|   7 +
 example/ipc/odp_ipc.c  | 425 +++
 helper/include/odp/helper/ring.h   |   2 +
 include/odp/api/pool.h |   1 +
 include/odp/api/shared_memory.h|   2 +-
 platform/linux-generic/Makefile.am |   1 +
 .../linux-generic/include/odp_buffer_internal.h|   2 +
 platform/linux-generic/include/odp_ipc.h   |  47 ++
 .../linux-generic/include/odp_packet_io_internal.h |  15 +
 platform/linux-generic/include/odp_pool_internal.h |   1 +
 platform/linux-generic/odp_init.c  |   6 +
 platform/linux-generic/odp_ipc.c   | 597 +
 platform/linux-generic/odp_packet_io.c |  30 +-
 platform/linux-generic/odp_pool.c  |  14 +-
 platform/linux-generic/odp_ring.c  |   9 +-
 platform/linux-generic/odp_schedule.c  |   1 +
 platform/linux-generic/odp_shared_memory.c |  10 +-
 20 files changed, 1165 insertions(+), 9 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_ipc.h
 create mode 100644 platform/linux-generic/odp_ipc.c

diff --git a/configure.ac b/configure.ac
index 57054c5..edd335a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -251,6 +251,7 @@ AC_CONFIG_FILES([Makefile
 doc/Makefile
 example/Makefile
 example/generator/Makefile
+example/ipc/Makefile
 example/ipsec/Makefile
 example/l2fwd/Makefile
 example/packet/Makefile
diff --git a/example/Makefile.am b/example/Makefile.am
index 3021571..2d1b02a 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = generator ipsec l2fwd packet timer
+SUBDIRS = generator ipc ipsec l2fwd 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..aadf27a
--- /dev/null
+++ b/example/ipc/odp_ipc.c
@@ -0,0 +1,425 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example odp_pktio.c  ODP basic packet IO loopback test application
+ */
+
+#include 
+#include 
+#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 int drop_err_pkts(odp_packet_t pkt_tbl[], unsigned len);
+static void parse_args(int argc, char *argv[]);
+static void print_info(char *progname);
+static void usage(char *progname);
+
+/**
+ * Create a pktio handle, optionally associating a default input queue.
+ *
+ * @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

Re: [lng-odp] [PATCH] pool: Do not flush cache of non-initialized pools

On 21 April 2015 at 05:06, Nicolas Morey-Chaisemartin 
wrote:

> Flush cache triggers atomic_add on some of the pool atomics which have
> never been initialized if the pool hasn't been.
>
> Signed-off-by: Nicolas Morey-Chaisemartin 
>

Subject needs to isolate the basic area for the patch by adding
"linux-generic:"  and we try to avoid punctuation, in this case the "Do" =
"do"
linux-generic: pool: do not flush cache of non-initialized pools

Do you have any test case we can add to test/validation that exposes the
need to do this ?
The test suit is currently sunny day focused and I am guessing you tripped
over this in real code

With the subject fixed
Reviewed-and-tested-by: Mike Holmes 


> ---
>  platform/linux-generic/odp_pool.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/platform/linux-generic/odp_pool.c
> b/platform/linux-generic/odp_pool.c
> index bf49623..31bf537 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -575,6 +575,8 @@ void _odp_flush_caches(void)
>
> for (i = 0; i < ODP_CONFIG_POOLS; i++) {
> pool_entry_t *pool = get_pool_entry(i);
> +   if (pool->s.pool_shm == ODP_SHM_INVALID)
> +   continue;
> flush_cache(&local_cache[i], &pool->s);
> }
>  }
> ___
> 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] [PATCH] validation: odp_pool: add double destroy

Signed-off-by: Mike Holmes 
---
 test/validation/odp_pool.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/test/validation/odp_pool.c b/test/validation/odp_pool.c
index 1a518a0..c2f9a1b 100644
--- a/test/validation/odp_pool.c
+++ b/test/validation/odp_pool.c
@@ -11,6 +11,30 @@ static int pool_name_number = 1;
 static const int default_buffer_size = 1500;
 static const int default_buffer_num = 1000;
 
+static void pool_double_destroy(void)
+{
+   odp_pool_param_t params = {
+   .buf = {
+   .size  = default_buffer_size,
+   .align = ODP_CACHE_LINE_SIZE,
+   .num   = default_buffer_num,
+   },
+   .type = ODP_POOL_BUFFER,
+   };
+   odp_pool_t pool;
+   char pool_name[ODP_POOL_NAME_LEN];
+
+   snprintf(pool_name, sizeof(pool_name),
+"test_pool-%d", pool_name_number++);
+
+   pool = odp_pool_create(pool_name, ODP_SHM_INVALID, ¶ms);
+   CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
+   CU_ASSERT(odp_pool_to_u64(pool) !=
+ odp_pool_to_u64(ODP_POOL_INVALID));
+   CU_ASSERT(odp_pool_destroy(pool) == 0);
+   CU_ASSERT(odp_pool_destroy(pool) < 0);
+}
+
 static void pool_create_destroy(odp_pool_param_t *params)
 {
odp_pool_t pool;
@@ -133,6 +157,7 @@ CU_TestInfo pool_tests[] = {
_CU_TEST_INFO(pool_create_destroy_timeout),
_CU_TEST_INFO(pool_create_destroy_buffer_shm),
_CU_TEST_INFO(pool_lookup_info_print),
+   _CU_TEST_INFO(pool_double_destroy),
CU_TEST_INFO_NULL,
 };
 
-- 
2.1.0

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

[lng-odp] [PATCH] doc: api_guide_lines: add guidance on ODP_DEPRECATED

Signed-off-by: Mike Holmes 
---
 doc/api_guide_lines.dox | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/api_guide_lines.dox b/doc/api_guide_lines.dox
index 2bc63a1..f26ce38 100644
--- a/doc/api_guide_lines.dox
+++ b/doc/api_guide_lines.dox
@@ -187,6 +187,10 @@ This is one of the reasons why some features MAY be 
defined as OPTIONAL.
 While allowed, the proliferation of OPTIONAL features SHOULD be avoided to 
enable broad application portability across many implementations.
 At the same time, a “least common denominator” approach MUST NOT be taken as 
that defeats the purpose of providing higher-level abstractions in APIs.
 
+@subsection odp_deprecated ODP DEPRECATED
+A deprecated API will remain marked as such in the public API using 
#ODP_DEPRECATED for two release cycles for the #ODP_VERSION_API_MAJOR number.
+For example an API marked as deprecated in 1.1.0 will still be present in 
1.2.0 and removed in 1.3.0
+
 @section defaults Default behaviours
 When an API has a default behaviour it must be possible for the application to 
explicitly call for that behaviour, this guards against the default changing 
and breaking the application.
 
-- 
2.1.0

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

Re: [lng-odp] [PATCH] pool: Do not flush cache of non-initialized pools

2015-04-21 Thread Nicolas Morey Chaisemartin

- Original Message -

> From: "Mike Holmes" 
> To: "Nicolas Morey-Chaisemartin" 
> Cc: "lng-odp" 
> Sent: Tuesday, 21 April, 2015 7:24:44 PM
> Subject: Re: [lng-odp] [PATCH] pool: Do not flush cache of non-initialized
> pools

> On 21 April 2015 at 05:06, Nicolas Morey-Chaisemartin < nmo...@kalray.eu >
> wrote:

> > Flush cache triggers atomic_add on some of the pool atomics which have
> > never
> > been initialized if the pool hasn't been.
> 

> > Signed-off-by: Nicolas Morey-Chaisemartin < nmo...@kalray.eu >
> 

> Subject needs to isolate the basic area for the patch by adding
> "linux-generic:" and we try to avoid punctuation, in this case the "Do" =
> "do"
> linux-generic: pool: do not flush cache of non-initialized pools

Noted for next time. Do you need me to resubmit with a fixed title? 

> Do you have any test case we can add to test/validation that exposes the need
> to do this ?
> The test suit is currently sunny day focused and I am guessing you tripped
> over this in real code

The reason behind this patch (and the other fixing create_pool) is that we 
don't have a test and set in our first generation of processor but a test and 
clear. 
So if for some reason atomic operations (using the lock) are run on an 
unitialized atomic, it stalls forever. 
The ideal way to test this would be to have a Debug/Check mode that makes sure 
an "init" field was initialized to a dummy non zero value. 
But it needs a lot of ifdefs and not-so-pretty code to build a complete test 
case and I'm not sure that is something you would want upstream. 

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

Re: [lng-odp] [PATCH] doc: api_guide_lines: add guidance on ODP_DEPRECATED

Looks good, however we should have some standards for why an API may be
deprecated and what should be done to document it.  For example, an API may
be deprecated if it is superseded by another API that provides a more
complete function.  Or it may be deprecated if there is agreement that it
is not being used or it cannot be implemented efficiently, etc.  When an
API is deprecated, the doxygen should state clearly why this has occurred
and offer migration advice for applications that may be using it.
Deprecated APIs should probably also issue a warning (does ODP_DEPRECATED
already do this?) if an application uses them.

On Tue, Apr 21, 2015 at 2:33 PM, Mike Holmes  wrote:

> Signed-off-by: Mike Holmes 
> ---
>  doc/api_guide_lines.dox | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/doc/api_guide_lines.dox b/doc/api_guide_lines.dox
> index 2bc63a1..f26ce38 100644
> --- a/doc/api_guide_lines.dox
> +++ b/doc/api_guide_lines.dox
> @@ -187,6 +187,10 @@ This is one of the reasons why some features MAY be
> defined as OPTIONAL.
>  While allowed, the proliferation of OPTIONAL features SHOULD be avoided
> to enable broad application portability across many implementations.
>  At the same time, a “least common denominator” approach MUST NOT be taken
> as that defeats the purpose of providing higher-level abstractions in APIs.
>
> +@subsection odp_deprecated ODP DEPRECATED
> +A deprecated API will remain marked as such in the public API using
> #ODP_DEPRECATED for two release cycles for the #ODP_VERSION_API_MAJOR
> number.
> +For example an API marked as deprecated in 1.1.0 will still be present in
> 1.2.0 and removed in 1.3.0
> +
>  @section defaults Default behaviours
>  When an API has a default behaviour it must be possible for the
> application to explicitly call for that behaviour, this guards against the
> default changing and breaking the application.
>
> --
> 2.1.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] pool: Do not flush cache of non-initialized pools

I have no problem with these changes however they appear unnecessary.  To
the extent that the pool stats require initialization beyond the store
that's already done, I'd do this as part of the odp_pool_global_init()
routine.  That way, like the pool locks, they are initialized only once
rather than every time a pool entry is allocated.  After the global init
they are simply reused.

On Tue, Apr 21, 2015 at 2:38 PM, Nicolas Morey Chaisemartin <
nmo...@kalray.eu> wrote:

>
>
> --
>
> *From: *"Mike Holmes" 
> *To: *"Nicolas Morey-Chaisemartin" 
> *Cc: *"lng-odp" 
> *Sent: *Tuesday, 21 April, 2015 7:24:44 PM
> *Subject: *Re: [lng-odp] [PATCH] pool: Do not flush cache of
> non-initialized pools
>
>
>
> On 21 April 2015 at 05:06, Nicolas Morey-Chaisemartin 
> wrote:
>
>> Flush cache triggers atomic_add on some of the pool atomics which have
>> never been initialized if the pool hasn't been.
>>
>> Signed-off-by: Nicolas Morey-Chaisemartin 
>>
>
> Subject needs to isolate the basic area for the patch by adding
> "linux-generic:"  and we try to avoid punctuation, in this case the "Do" =
> "do"
> linux-generic: pool: do not flush cache of non-initialized pools
>
> Noted for next time. Do you need me to resubmit with a fixed title?
>
>
> Do you have any test case we can add to test/validation that exposes the
> need to do this ?
> The test suit is currently sunny day focused and I am guessing you tripped
> over this in real code
>
>
> The reason behind this patch (and the other fixing create_pool) is that we
> don't have a test and set in our first generation of processor but a test
> and clear.
> So if for some reason atomic operations (using the lock) are run on an
> unitialized atomic, it stalls forever.
> The ideal way to test this would be to have a Debug/Check mode that makes
> sure an "init" field was initialized to a dummy non zero value.
> But it needs a lot of ifdefs and not-so-pretty code to build a complete
> test case and I'm not sure that is something you would want upstream.
>
> Nicolas
>
>
> ___
> 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] validation: odp_pool: add double destroy

On Tue, Apr 21, 2015 at 2:14 PM, Mike Holmes  wrote:

> Signed-off-by: Mike Holmes 
>

Reviewed-by: Bill Fischofer 


> ---
>  test/validation/odp_pool.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/test/validation/odp_pool.c b/test/validation/odp_pool.c
> index 1a518a0..c2f9a1b 100644
> --- a/test/validation/odp_pool.c
> +++ b/test/validation/odp_pool.c
> @@ -11,6 +11,30 @@ static int pool_name_number = 1;
>  static const int default_buffer_size = 1500;
>  static const int default_buffer_num = 1000;
>
> +static void pool_double_destroy(void)
> +{
> +   odp_pool_param_t params = {
> +   .buf = {
> +   .size  = default_buffer_size,
> +   .align = ODP_CACHE_LINE_SIZE,
> +   .num   = default_buffer_num,
> +   },
> +   .type = ODP_POOL_BUFFER,
> +   };
> +   odp_pool_t pool;
> +   char pool_name[ODP_POOL_NAME_LEN];
> +
> +   snprintf(pool_name, sizeof(pool_name),
> +"test_pool-%d", pool_name_number++);
> +
> +   pool = odp_pool_create(pool_name, ODP_SHM_INVALID, ¶ms);
> +   CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
> +   CU_ASSERT(odp_pool_to_u64(pool) !=
> + odp_pool_to_u64(ODP_POOL_INVALID));
> +   CU_ASSERT(odp_pool_destroy(pool) == 0);
> +   CU_ASSERT(odp_pool_destroy(pool) < 0);
> +}
> +
>  static void pool_create_destroy(odp_pool_param_t *params)
>  {
> odp_pool_t pool;
> @@ -133,6 +157,7 @@ CU_TestInfo pool_tests[] = {
> _CU_TEST_INFO(pool_create_destroy_timeout),
> _CU_TEST_INFO(pool_create_destroy_buffer_shm),
> _CU_TEST_INFO(pool_lookup_info_print),
> +   _CU_TEST_INFO(pool_double_destroy),
> CU_TEST_INFO_NULL,
>  };
>
> --
> 2.1.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] doc: api_guide_lines: add guidance on ODP_DEPRECATED

On 21 April 2015 at 15:39, Bill Fischofer  wrote:

> Looks good, however we should have some standards for why an API may be
> deprecated and what should be done to document it.  For example, an API may
> be deprecated if it is superseded by another API that provides a more
> complete function.  Or it may be deprecated if there is agreement that it
> is not being used or it cannot be implemented efficiently, etc.  When an
> API is deprecated, the doxygen should state clearly why this has occurred
> and offer migration advice for applications that may be using it.
> Deprecated APIs should probably also issue a warning (does ODP_DEPRECATED
> already do this?) if an application uses them.
>

ODP_DEPRECATED will warn at compile time - it is defined
as __attribute__((__deprecated__))

>From the gcc manual
"The deprecated attribute results in a warning if the function is used
anywhere in the source file. This is useful when identifying functions that
are expected to be removed in a future version of a program. The warning
also includes the location of the declaration of the deprecated function,
to enable users to easily find further information about why the function
is deprecated, or what they should do instead."


I completely agree on documenting the change, and you just reminded me that
we can add @deprecated to the doxygen as well so maybe we will have to
update ODP_DEPRECATED

to take a string to make it easy to hit both mechanisms with a single
change.

e.g.
void foo(void)  ODP_DEPRECATED("this was a rubbish api and it is Tuesday
already so lets delete it");



>
> On Tue, Apr 21, 2015 at 2:33 PM, Mike Holmes 
> wrote:
>
>> Signed-off-by: Mike Holmes 
>> ---
>>  doc/api_guide_lines.dox | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/doc/api_guide_lines.dox b/doc/api_guide_lines.dox
>> index 2bc63a1..f26ce38 100644
>> --- a/doc/api_guide_lines.dox
>> +++ b/doc/api_guide_lines.dox
>> @@ -187,6 +187,10 @@ This is one of the reasons why some features MAY be
>> defined as OPTIONAL.
>>  While allowed, the proliferation of OPTIONAL features SHOULD be avoided
>> to enable broad application portability across many implementations.
>>  At the same time, a “least common denominator” approach MUST NOT be
>> taken as that defeats the purpose of providing higher-level abstractions in
>> APIs.
>>
>> +@subsection odp_deprecated ODP DEPRECATED
>> +A deprecated API will remain marked as such in the public API using
>> #ODP_DEPRECATED for two release cycles for the #ODP_VERSION_API_MAJOR
>> number.
>> +For example an API marked as deprecated in 1.1.0 will still be present
>> in 1.2.0 and removed in 1.3.0
>> +
>>  @section defaults Default behaviours
>>  When an API has a default behaviour it must be possible for the
>> application to explicitly call for that behaviour, this guards against the
>> default changing and breaking the application.
>>
>> --
>> 2.1.0
>>
>> ___
>> 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] doc: api_guide_lines: add guidance on ODP_DEPRECATED

I like the idea of a reason string on ODP_DEPRECATED().

On Tue, Apr 21, 2015 at 3:06 PM, Mike Holmes  wrote:

>
>
> On 21 April 2015 at 15:39, Bill Fischofer 
> wrote:
>
>> Looks good, however we should have some standards for why an API may be
>> deprecated and what should be done to document it.  For example, an API may
>> be deprecated if it is superseded by another API that provides a more
>> complete function.  Or it may be deprecated if there is agreement that it
>> is not being used or it cannot be implemented efficiently, etc.  When an
>> API is deprecated, the doxygen should state clearly why this has occurred
>> and offer migration advice for applications that may be using it.
>> Deprecated APIs should probably also issue a warning (does ODP_DEPRECATED
>> already do this?) if an application uses them.
>>
>
> ODP_DEPRECATED will warn at compile time - it is defined
> as __attribute__((__deprecated__))
>
> From the gcc manual
> "The deprecated attribute results in a warning if the function is used
> anywhere in the source file. This is useful when identifying functions that
> are expected to be removed in a future version of a program. The warning
> also includes the location of the declaration of the deprecated function,
> to enable users to easily find further information about why the function
> is deprecated, or what they should do instead."
>
>
> I completely agree on documenting the change, and you just reminded me
> that we can add @deprecated to the doxygen as well so maybe we will have to
> update ODP_DEPRECATED
> 
> to take a string to make it easy to hit both mechanisms with a single
> change.
>
> e.g.
> void foo(void)  ODP_DEPRECATED("this was a rubbish api and it is Tuesday
> already so lets delete it");
>
>
>
>>
>> On Tue, Apr 21, 2015 at 2:33 PM, Mike Holmes 
>> wrote:
>>
>>> Signed-off-by: Mike Holmes 
>>> ---
>>>  doc/api_guide_lines.dox | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/doc/api_guide_lines.dox b/doc/api_guide_lines.dox
>>> index 2bc63a1..f26ce38 100644
>>> --- a/doc/api_guide_lines.dox
>>> +++ b/doc/api_guide_lines.dox
>>> @@ -187,6 +187,10 @@ This is one of the reasons why some features MAY be
>>> defined as OPTIONAL.
>>>  While allowed, the proliferation of OPTIONAL features SHOULD be avoided
>>> to enable broad application portability across many implementations.
>>>  At the same time, a “least common denominator” approach MUST NOT be
>>> taken as that defeats the purpose of providing higher-level abstractions in
>>> APIs.
>>>
>>> +@subsection odp_deprecated ODP DEPRECATED
>>> +A deprecated API will remain marked as such in the public API using
>>> #ODP_DEPRECATED for two release cycles for the #ODP_VERSION_API_MAJOR
>>> number.
>>> +For example an API marked as deprecated in 1.1.0 will still be present
>>> in 1.2.0 and removed in 1.3.0
>>> +
>>>  @section defaults Default behaviours
>>>  When an API has a default behaviour it must be possible for the
>>> application to explicitly call for that behaviour, this guards against the
>>> default changing and breaking the application.
>>>
>>> --
>>> 2.1.0
>>>
>>> ___
>>> 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] [PATCH] test: helper: add process and thread tests

The helpers need to be tested independently from the ODP API, create a
folder to contain helper tests, adding tests for process and thread
creation.

Signed-off-by: Mike Holmes 
---
 configure.ac  | 15 +
 test/Makefile.am  |  5 ++-
 test/helper/.gitignore|  4 +++
 test/helper/Makefile.am   | 25 ++
 test/helper/odp_process.c | 85 +++
 test/helper/odp_thread.c  | 79 +++
 6 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 test/helper/.gitignore
 create mode 100644 test/helper/Makefile.am
 create mode 100644 test/helper/odp_process.c
 create mode 100644 test/helper/odp_thread.c

diff --git a/configure.ac b/configure.ac
index 78ff245..c03778f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -138,6 +138,20 @@ AC_ARG_ENABLE([test-perf],
 AM_CONDITIONAL([test_perf], [test x$test_perf = xyes ])
 
 ##
+# Enable/disable test-helper
+##
+test_helper=no
+AC_ARG_ENABLE([test-helper],
+[  --enable-test-helper  run test in test/helper],
+[if test "x$enableval" = "xyes"; then
+test_helper=yes
+fi])
+
+AM_CONDITIONAL([test_helper], [test x$test_helper = xyes ])
+
+##
+
+##
 # Enable/disable test-cpp
 ##
 test_cpp=no
@@ -284,6 +298,7 @@ AC_CONFIG_FILES([Makefile
 test/performance/Makefile
 test/validation/Makefile
 test/miscellaneous/Makefile
+test/helper/Makefile
 ])
 
 AC_SEARCH_LIBS([timer_create],[rt posix4])
diff --git a/test/Makefile.am b/test/Makefile.am
index 2ba8008..31872b0 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -1,4 +1,7 @@
-SUBDIRS = api_test performance miscellaneous
+SUBDIRS = api_test \
+  performance \
+  miscellaneous \
+  helper
 
 if cunit_support
 SUBDIRS += validation
diff --git a/test/helper/.gitignore b/test/helper/.gitignore
new file mode 100644
index 000..fe65f30
--- /dev/null
+++ b/test/helper/.gitignore
@@ -0,0 +1,4 @@
+*.trs
+*.log
+odp_process
+odp_thread
diff --git a/test/helper/Makefile.am b/test/helper/Makefile.am
new file mode 100644
index 000..f330533
--- /dev/null
+++ b/test/helper/Makefile.am
@@ -0,0 +1,25 @@
+include $(top_srcdir)/test/Makefile.inc
+
+AM_CFLAGS += -I$(srcdir)/common
+AM_LDFLAGS += -static
+
+TESTS_ENVIRONMENT = ODP_PLATFORM=${with_platform} TEST_DIR=${builddir}
+
+EXECUTABLES = odp_thread \
+  odp_process
+
+COMPILE_ONLY =
+
+TESTSCRIPTS =
+
+if test_helper
+TESTS = $(EXECUTABLES) $(TESTSCRIPTS)
+endif
+
+dist_bin_SCRIPTS =
+
+bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
+
+
+dist_odp_thread_SOURCES = odp_thread.c
+dist_odp_process_SOURCES = odp_process.c
diff --git a/test/helper/odp_process.c b/test/helper/odp_process.c
new file mode 100644
index 000..495cb00
--- /dev/null
+++ b/test/helper/odp_process.c
@@ -0,0 +1,85 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+
+#define NUMBER_WORKERS 16 /* 0 = max */
+
+static void *worker_fn(void *arg TEST_UNUSED)
+{
+   /* depend on the odp helper to call odp_init_local */
+   printf("Worker thread on CPU %d\n", odp_cpu_id());
+
+   return 0;
+}
+
+/* Create additional dataplane processes */
+int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
+{
+   odp_cpumask_t cpu_mask;
+   int num_workers;
+   int cpu;
+   char cpumaskstr[ODP_CPUMASK_STR_SIZE];
+   int ret;
+   odph_linux_process_t proc[NUMBER_WORKERS];
+
+   if (odp_init_global(NULL, NULL)) {
+   LOG_ERR("Error: ODP global init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   if (odp_init_local()) {
+   LOG_ERR("Error: ODP local init failed.\n");
+   exit(EXIT_FAILURE);
+   }
+
+   /* discover how many threads this system can support */
+   num_workers = odph_linux_cpumask_default(&cpu_mask, NUMBER_WORKERS);
+   if (num_workers < NUMBER_WORKERS) {
+   printf("System can only support %d threads and not the %d 
requested\n",
+  num_workers, NUMBER_WORKERS);
+   }
+
+   /* generate a summary for the user */
+   (void)odp_cpumask_to_str(&cpu_mask, cpumaskstr, sizeof(cpumaskstr));
+   printf("default cpu mask:   %s\n", cpumaskstr);
+   printf("default num worker threads: %i\n", num_workers);
+
+   cpu = odp_cpumask_first(&cpu_mask);
+   printf("the first CPU:  %i\n", cpu);
+
+   /* reserve cpu 0 for the con

Re: [lng-odp] pktio optional parsing

We discussed this during today's ODP public call.  Petri has a proposed set
of API extensions to pktio to allow the application to tell the
implementation what it needs in terms of parsing.  While this sounds
reasonable, my concern is that the application may not know as much as it
things it knows, especially as it evolves.  Another approach is to use
"lazy evaluation" in the implementations so that packets are parsed on
demand when specific parse results are queried.  This can be done at
various levels of granularity and sophistication depending on how the
implementation is structured.  For linux-generic, it might be sufficient to
call _odp_packet_parse() on first call to an odp_packet_flags API. This
would seem to address OVS's immediate problem since it never calls these
routines since it does its own parsing and hence ODP wouldn't duplicate
this result.  Over time OVS could switch to using the ODP parse results and
take advantages of HW parsing on those platforms that provide it.

On Wed, Apr 15, 2015 at 9:40 AM, Zoltan Kiss  wrote:

>
>
> On 14/04/15 20:04, Ola Liljedahl wrote:
>
>> On 14 April 2015 at 19:21, Zoltan Kiss > > wrote:
>>
>>
>>
>> On 13/04/15 22:38, Ola Liljedahl wrote:
>>
>> On 8 April 2015 at 19:02, Zoltan Kiss > 
>> > __>> wrote:
>>
>>  Hi,
>>
>>  OVS has a major performance issue with pktio at the moment:
>> pktio
>>  always does parsing, but OVS does it for itself as well,
>> and it is
>>  quite deeply woven into its code, so we can't easily modify
>> it to
>>  use the ODP parsed data. Also, not every platform
>> accelerate that
>>  (e.g. DPDK), at the moment it would make more sense to make
>> parsing
>>  optional for pktio, so an application can opt not to do it.
>>  I can see two options now to define the API:
>>  - odp_pktio_open get a new bool parameter for this purpose
>>  - we create a new odp_pktio_enable/disable_parse function
>> pair for
>>  this purpose
>>
>> Is the result of the ODP packet parsing somehow used?
>>
>> No, but OVS might start use it in the future
>>
>> I wasn't thinking of whether some application is using the
>> classification functionality. Rather if no classification rules are
>> defined by the application, is the result of the parsing and
>> classification still somehow used internally?
>>
>
> Yes, in case of OVS probably we wouldn't need classification (at least not
> in the foreseeable future), but we would need parsing.
>
>  If not, why not just skip
>
>> performing the classification if the results are not used? (i.e. a lazy
>> evaluation scheme). There should be no need for any big on/off switch
>> for classification.
>>
>>
>>
>>   I would assume
>>
>> that OVS-ODP does not set up any classification rules so all
>> packets go
>> to some default destination anyway (some pktio input queue).
>>
>> OVS wouldn't just use the parsed data for QoS, but e.g. to create a
>> flow entry. I don't think the use of classification can decided
>> whether you need parsing or not.
>>
>>   Can't the
>>
>> ODP implementation then bypass the classification stage if it can
>> understand (and it should be able to) that classification does not
>> change the behavior?
>>
>> I would rather not invent explicit configurations when the
>> implementation should be able to deduce the best behavior based
>> on the
>> configuration provided by the user.
>>
>>
>>  Any opinions about these options?
>>
>>  Regards,
>>
>>  Zoli
>>  ___
>>  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 1/1 v1] examples: odp_ipsec: runtime select multiple vs single deq

Actually, checkpatch requires balanced braces.  If one arm of an if/else
requires braces, then checkpatch says the other should have braces even if
it's a single statement.

On Mon, Apr 13, 2015 at 4:18 PM, Ola Liljedahl 
wrote:

> On 9 April 2015 at 19:39, Robbie King (robking)  wrote:
>
>> One minor nit, see [rk] inline.  If tools won’t allow it, no problem.
>>
>> Reviewed-by: Robbie King 
>>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> alexandru.badici...@linaro.org
>> Sent: Wednesday, April 08, 2015 2:28 AM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH 1/1 v1] examples: odp_ipsec: runtime select
>> multiple vs single deq
>>
>> From: Alexandru Badicioiu 
>>
>> Signed-off-by: Alexandru Badicioiu 
>> ---
>>  example/ipsec/odp_ipsec.c|3 +++
>>  example/ipsec/odp_ipsec_stream.c |   27 +++
>>  2 files changed, 14 insertions(+), 16 deletions(-)
>>
>> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
>> index 9fb048a..cb8f535 100644
>> --- a/example/ipsec/odp_ipsec.c
>> +++ b/example/ipsec/odp_ipsec.c
>> @@ -1498,6 +1498,9 @@ static void usage(char *progname)
>>" can be used to advanced pkt I/O selection for
>> linux-generic\n"
>>"ODP_IPSEC_USE_POLL_QUEUES\n"
>>" to enable use of poll queues instead of scheduled
>> (default)\n"
>> +  "ODP_IPSEC_STREAM_VERIFY_MDEQ\n"
>> +  " to enable use of multiple dequeue for queue draining
>> during\n"
>> +  " stream verification instead of single dequeue
>> (default)\n"
>>"\n", NO_PATH(progname), NO_PATH(progname)
>> );
>>  }
>> diff --git a/example/ipsec/odp_ipsec_stream.c
>> b/example/ipsec/odp_ipsec_stream.c
>> index ed07355..86cfb7e 100644
>> --- a/example/ipsec/odp_ipsec_stream.c
>> +++ b/example/ipsec/odp_ipsec_stream.c
>> @@ -28,14 +28,6 @@
>>
>>  #define STREAM_MAGIC 0xBABE01234567CAFE
>>
>> -/**
>> - * Control use of odp_queue_deq versus odp_queue_deq_multi
>> - * when draining stream output queues
>> - *
>> - * @todo Make this command line driven versus compile time
>> - *   (see https://bugs.linaro.org/show_bug.cgi?id=626)
>> - */
>> -#define LOOP_DEQ_MULTIPLE 0 /**< enable multi packet dequeue */
>>  #define LOOP_DEQ_COUNT32/**< packets to dequeue at once */
>>
>>  /**
>> @@ -517,7 +509,9 @@ odp_bool_t verify_stream_db_outputs(void)
>>  {
>> odp_bool_t done = TRUE;
>> stream_db_entry_t *stream = NULL;
>> +   const char *env;
>>
>> +   env = getenv("ODP_IPSEC_STREAM_VERIFY_MDEQ");
>> /* For each stream look for output packets */
>> for (stream = stream_db->list; NULL != stream; stream =
>> stream->next) {
>> int idx;
>> @@ -531,14 +525,15 @@ odp_bool_t verify_stream_db_outputs(void)
>> continue;
>>
>> for (;;) {
>> -#if LOOP_DEQ_MULTIPLE
>> -   count = odp_queue_deq_multi(queue,
>> -   ev_tbl,
>> -   LOOP_DEQ_COUNT);
>> -#else
>> -   ev_tbl[0] = odp_queue_deq(queue);
>> -   count = (ev_tbl[0] != ODP_EVENT_INVALID) ? 1 : 0;
>> -#endif
>> +   if (env)
>> +   count = odp_queue_deq_multi(queue,
>> +   ev_tbl,
>> +
>>  LOOP_DEQ_COUNT);
>>
>> [rk] unbalanced "{}", much better in my opinion to have brackets on both
>>  "if" and "else" leg, but understand if the check scripts don't let
>> you
>>
> I agree with Robbie here. Not having the braces on the if-statement
> doesn't even save any vertical screen estate. If the tools don't like this,
> we have the wrong tools. But I do suspect having the same style on all legs
> *is* the recommended style.
>
>
>>
>> +   else {
>> +   ev_tbl[0] = odp_queue_deq(queue);
>> +   count = (ev_tbl[0] != ODP_EVENT_INVALID) ?
>> +   1 : 0;
>> +   }
>> if (!count)
>> break;
>> for (idx = 0; idx < count; idx++) {
>> --
>> 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
>
>
___
lng-odp mailing list
lng-

[lng-odp] [PATCH] validation: thread: add odp_thread sunnyday tests

Add test cases for APIs in the logical ODP THREAD grouping

Signed-off-by: Mike Holmes 
---
 test/validation/.gitignore   |  1 +
 test/validation/Makefile.am  |  4 +++-
 test/validation/odp_thread.c | 41 +
 3 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 test/validation/odp_thread.c

diff --git a/test/validation/.gitignore b/test/validation/.gitignore
index 01092d1..cd27c92 100644
--- a/test/validation/.gitignore
+++ b/test/validation/.gitignore
@@ -19,3 +19,4 @@ odp_synchronizers
 odp_system
 odp_time
 odp_timer
+odp_thread
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index 4c28325..6bac101 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -22,7 +22,8 @@ EXECUTABLES = odp_buffer \
  odp_synchronizers \
  odp_time \
  odp_timer \
- odp_errno
+ odp_errno \
+ odp_thread
 
 COMPILE_ONLY = odp_pktio
 
@@ -63,3 +64,4 @@ dist_odp_packet_SOURCES = odp_packet.c $(ODP_CU_COMMON)
 dist_odp_pool_SOURCES = odp_pool.c $(ODP_CU_COMMON)
 dist_odp_errno_SOURCES = odp_errno.c $(ODP_CU_COMMON)
 dist_odp_cpumask_SOURCES = odp_cpumask.c $(ODP_CU_COMMON)
+dist_odp_thread_SOURCES = odp_thread.c $(ODP_CU_COMMON)
diff --git a/test/validation/odp_thread.c b/test/validation/odp_thread.c
new file mode 100644
index 000..84db1e7
--- /dev/null
+++ b/test/validation/odp_thread.c
@@ -0,0 +1,41 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+
+/* Helper macro for CU_TestInfo initialization */
+#define _CU_TEST_INFO(test_func) {#test_func, test_func}
+
+static void test_odp_cpu_id(void)
+{
+   (void) odp_cpu_id();
+   CU_PASS();
+}
+
+static void test_odp_thread_id(void)
+{
+   (void) odp_thread_id();
+   CU_PASS();
+}
+
+static void test_odp_thread_count(void)
+{
+   (void) odp_thread_count();
+   CU_PASS();
+}
+
+CU_TestInfo test_odp_thread[] = {
+   _CU_TEST_INFO(test_odp_cpu_id),
+   _CU_TEST_INFO(test_odp_thread_id),
+   _CU_TEST_INFO(test_odp_thread_count),
+   CU_TEST_INFO_NULL,
+};
+
+CU_SuiteInfo odp_testsuites[] = {
+   {"thread", NULL, NULL, NULL, NULL, test_odp_thread},
+   CU_SUITE_INFO_NULL,
+};
-- 
2.1.0

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

Re: [lng-odp] [RFC API-NEXT PATCH] packet_io: add bitmap to specify what level of parsing needed

I think the point is that decoding what the application has specified
likely costs about as much as just doing the parse to begin with if you're
doing this in SW, and HW probably doesn't have anything like this sort of
control.  So what is the point here?

A "lazy parser" approach would seem to be both simpler for the application
and potentially faster for the implementation.  But some minimal level of
parsing is needed if only to identify the layer offsets.  The only
significant speedup you're going to see is if SW parsing (in ODP) is
bypassed entirely because the implementation is doing it all on its own.

On Tue, Apr 21, 2015 at 8:38 AM, Zoltan Kiss  wrote:

>
>
> On 20/04/15 10:36, Ola Liljedahl wrote:
>
>> On 20 April 2015 at 11:12, Maxim Uvarov > > wrote:
>>
>> How that supposed to increase performance?
>>
>> The code will be like:
>>
>> if (parse_vlan)
>>  do_parse_vlan
>> if (parse_ipv4)
>>  do_parse_ipv4
>>
>> and etc. I.e. You will add about 20-30 if branches.
>>
>> That's exactly how you are *not* supposed to implemented the parsing and
>> that is the coding I wanted to avoid with specifying the layer instead
>> of individual protocols. But as I then suggested, an implementation can
>> set the parsing levels based on the individual flags.
>>
>> if (pktio->parse_layer_2) {
>>  //Unconditional parsing of Ethernet/VLAN etc
>>  
>>  if (pkt->parse_layer_3) {
>>  //Unconditional parsing of IPv4/IPv6 headers
>>  
>>  if (pkt->parse_layer_4) {
>>   //Unconditional parsing of e.g. UDP/TCP/SCTP headers
>>  }
>>  }
>> }
>>
>>
> That would work with a more detailed parsing configuration as well:
>
>
> if (pktio->eth) &&
>((pktio->jumbo) || (frame_len < 1524)) &&
>((pktio->vlan) || (ethertype != 0x8100)) &&
> ...
>
> And the branch predictor can optimize this out as well.
>
> Zoli
>
> ___
> 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] api: classification: connect PMR on creation

The design doc says what I've been saying here. It's the application's
responsibility to ensure that the rule set specified is unambiguous.

On Tue, Apr 21, 2015 at 8:08 AM, Bala Manoharan 
wrote:

> On 21 April 2015 at 18:15, Ola Liljedahl  wrote:
> > On 21 April 2015 at 14:26, Maxim Uvarov  wrote:
> >>
> >> On 04/21/15 15:01, Bill Fischofer wrote:
> >>>
> >>> Behavior is undefined if rules are ambiguous. Consider the following
> >>> rules:
> >>>
> >>> protocol == UDP --> CoS A
> >>> port == 1234 --> CoS B
> >>>
> >>> What happens if a UDP packet for port 1234 arrives? Answer: undefined.
> >>
> >>
> >>
> >> Isn't pmr created one by one to the table? And first match will return
> Cos
> >> A in that case.
> >
> > Since we are having this discussion, it is obvious that we need a
> definition
> > of the ODP classification that cannot be misunderstood or misinterpreted.
> > Probably a formal definition. Or do everyone here agree that the
> (current)
> > linux-generic implementation can serve as *the* definition?
>
> Shouldn't we use the classification design document as the definition
> of classification and the linux-generic implementation can be used as
> a reference and not "the" definition.
>
> Regards,
> Bala
> >
> >
> >
> >>
> >>
> >> Maxim.
> >>
> >>> The result may be either CoS A or CoS B.
> >>>
> >>> A better rule set would be:
> >>>
> >>> protocol == UDP --> CoS A
> >>>
> >>> CoS A && port == 1234 --> CoS B
> >>>
> >>> Now this is unambiguous.  UDP packets go to CoS A unless they also
> >>> specify port 1234, in which case they go to CoS B.
> >>>
> >>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl <
> ola.liljed...@linaro.org
> >>> > wrote:
> >>>
> >>> On 20 April 2015 at 21:49, Bill Fischofer
> >>> mailto:bill.fischo...@linaro.org>>
> wrote:
> >>>
> >>> Classification is a collaboration between the implementation
> >>> and the application. It is the application's responsibility to
> >>> write unambiguous classification rules and it is the
> >>> implementation's job to perform the match as efficiently and
> >>> as specifically as possible.
> >>>
> >>> What should an implementation do if the classification rules are
> >>> ambiguous? E.g. if partial matches (of different partially
> >>> overlapping rules) use different CoS? Is this an error already
> >>> when creating the PMR rules?
> >>>
> >>> -- Ola
> >>>
> >>>
> >>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
> >>> mailto:ola.liljed...@linaro.org>>
> >>> wrote:
> >>>
> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid
> >>>  >>> > wrote:
> >>>
> >>>
> >>> Guys,
> >>>
> >>> There are several versions of the Classifier API
> >>> document floating in Google docs, here is one such
> copy:
> >>>
> >>>
> >>>
> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
> >>>
> >>> Here is a different perspective on what PMR and COS
> >>> mean,  perhaps in terms of an abstract hardware
> >>> implementation:
> >>>
> >>> CoS is a meta-data field assigned to each packet as it
> >>> traverses the classifier pipe-line.
> >>>
> >>> A packet is assigned an initial CoS by the pktio port
> >>> which received it.
> >>>
> >>> Then, the packet is compared multiple times against a
> >>> set of rules, and as it is common with TCAMs, each
> >>> comparisons happens against all rules in parallel.
> >>>
> >>> Each rule has two values to match: 1. the current CoS
> >>> meta-data field; and 2. a certain packet header field
> >>> (value with a mask).
> >>> If both these values match, the packet met-data CoS
> >>> field is changed (Action taken) with the destination
> >>> CoS of the matching rule.
> >>>
> >>> It is assumed that up to one such rule has matched.
> >>>
> >>> If a rule has matched, CoS has changed, the process
> >>> continues one more time.
> >>>
> >>> If NO MATCH occured, the classification process is
> >>> finished, and the packet is delivered in accordance to
> >>> the current CoS (i.e. the last matching rule or the
> >>> pktio default CoS if the first rule match failed).
> >>>
> >>> So partial matches are valid. Is this what we want, e.g.
> >>> from application point of view and from HW point of view?
> >>>
> >>> Is partial matches what is commonly supported by HW
> >>> classifiers?
> >>>
> >>> A classifier which supports these longest prefix matches
>

Re: [lng-odp] [PATCH] pool: Make sure all atomics are initialized before stored or incremented

The init calls should be moved to odp_pool_init_global() and the stores
should be left unchanged here.

On Tue, Apr 21, 2015 at 3:59 AM, Nicolas Morey-Chaisemartin <
nmo...@kalray.eu> wrote:

> Signed-off-by: Nicolas Morey-Chaisemartin 
> ---
>  platform/linux-generic/odp_pool.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/platform/linux-generic/odp_pool.c
> b/platform/linux-generic/odp_pool.c
> index bf49623..23cd503 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -342,13 +342,24 @@ odp_pool_t odp_pool_create(const char *name,
> pool->s.blk_freelist = NULL;
>
> /* Initialization will increment these to their target
> vals */
> -   odp_atomic_store_u32(&pool->s.bufcount, 0);
> -   odp_atomic_store_u32(&pool->s.blkcount, 0);
> +   odp_atomic_init_u32(&pool->s.bufcount, 0);
> +   odp_atomic_init_u32(&pool->s.blkcount, 0);
>
> uint8_t *buf = udata_base_addr - buf_stride;
> uint8_t *udat = udata_stride == 0 ? NULL :
> block_base_addr - udata_stride;
>
> +
> +   /* Initialize pool statistics counters */
> +   odp_atomic_init_u64(&pool->s.bufallocs, 0);
> +   odp_atomic_init_u64(&pool->s.buffrees, 0);
> +   odp_atomic_init_u64(&pool->s.blkallocs, 0);
> +   odp_atomic_init_u64(&pool->s.blkfrees, 0);
> +   odp_atomic_init_u64(&pool->s.bufempty, 0);
> +   odp_atomic_init_u64(&pool->s.blkempty, 0);
> +   odp_atomic_init_u64(&pool->s.high_wm_count, 0);
> +   odp_atomic_init_u64(&pool->s.low_wm_count, 0);
> +
> /* Init buffer common header and add to pool buffer
> freelist */
> do {
> odp_buffer_hdr_t *tmp =
> @@ -359,7 +370,7 @@ odp_pool_t odp_pool_create(const char *name,
> tmp->flags.all = 0;
> tmp->flags.zeroized = zeroized;
> tmp->size = 0;
> -   odp_atomic_store_u32(&tmp->ref_count, 0);
> +   odp_atomic_init_u32(&tmp->ref_count, 0);
> tmp->type = params->type;
> tmp->pool_hdl = pool->s.pool_hdl;
> tmp->udata_addr = (void *)udat;
> @@ -397,15 +408,10 @@ odp_pool_t odp_pool_create(const char *name,
> blk -= pool->s.seg_size;
> } while (blk >= block_base_addr);
>
> -   /* Initialize pool statistics counters */
> -   odp_atomic_store_u64(&pool->s.bufallocs, 0);
> +   /* Reset the statistics counters that might
> +* have been changed by ret_buf */
> odp_atomic_store_u64(&pool->s.buffrees, 0);
> -   odp_atomic_store_u64(&pool->s.blkallocs, 0);
> -   odp_atomic_store_u64(&pool->s.blkfrees, 0);
> -   odp_atomic_store_u64(&pool->s.bufempty, 0);
> -   odp_atomic_store_u64(&pool->s.blkempty, 0);
> odp_atomic_store_u64(&pool->s.high_wm_count, 0);
> -   odp_atomic_store_u64(&pool->s.low_wm_count, 0);
>
> /* Reset other pool globals to initial state */
> pool->s.low_wm_assert = 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] [API-NEXT PATCH] api: classification: connect PMR on creation

Code rules IMHO - the compiler will ensure we follow the rules.

Can we add test cases to prove the behavior across all platforms,
linux-generic being one of them, and thus the code is correct no matter
what is written anywhere else. Presumably the api documentation matches the
code but it should be updated and clarified to match the behavior proven by
the test cases.

I do not think referencing the classification design document has any value
any more it is no longer a maintained document, however I do recall as Bill
says that we decided it was the applications responsibility be unambiguous.

On 21 April 2015 at 17:33, Bill Fischofer  wrote:

> The design doc says what I've been saying here. It's the application's
> responsibility to ensure that the rule set specified is unambiguous.
>
> On Tue, Apr 21, 2015 at 8:08 AM, Bala Manoharan  > wrote:
>
>> On 21 April 2015 at 18:15, Ola Liljedahl 
>> wrote:
>> > On 21 April 2015 at 14:26, Maxim Uvarov 
>> wrote:
>> >>
>> >> On 04/21/15 15:01, Bill Fischofer wrote:
>> >>>
>> >>> Behavior is undefined if rules are ambiguous. Consider the following
>> >>> rules:
>> >>>
>> >>> protocol == UDP --> CoS A
>> >>> port == 1234 --> CoS B
>> >>>
>> >>> What happens if a UDP packet for port 1234 arrives? Answer: undefined.
>> >>
>> >>
>> >>
>> >> Isn't pmr created one by one to the table? And first match will return
>> Cos
>> >> A in that case.
>> >
>> > Since we are having this discussion, it is obvious that we need a
>> definition
>> > of the ODP classification that cannot be misunderstood or
>> misinterpreted.
>> > Probably a formal definition. Or do everyone here agree that the
>> (current)
>> > linux-generic implementation can serve as *the* definition?
>>
>> Shouldn't we use the classification design document as the definition
>> of classification and the linux-generic implementation can be used as
>> a reference and not "the" definition.
>>
>> Regards,
>> Bala
>> >
>> >
>> >
>> >>
>> >>
>> >> Maxim.
>> >>
>> >>> The result may be either CoS A or CoS B.
>> >>>
>> >>> A better rule set would be:
>> >>>
>> >>> protocol == UDP --> CoS A
>> >>>
>> >>> CoS A && port == 1234 --> CoS B
>> >>>
>> >>> Now this is unambiguous.  UDP packets go to CoS A unless they also
>> >>> specify port 1234, in which case they go to CoS B.
>> >>>
>> >>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl <
>> ola.liljed...@linaro.org
>> >>> > wrote:
>> >>>
>> >>> On 20 April 2015 at 21:49, Bill Fischofer
>> >>> mailto:bill.fischo...@linaro.org>>
>> wrote:
>> >>>
>> >>> Classification is a collaboration between the implementation
>> >>> and the application. It is the application's responsibility to
>> >>> write unambiguous classification rules and it is the
>> >>> implementation's job to perform the match as efficiently and
>> >>> as specifically as possible.
>> >>>
>> >>> What should an implementation do if the classification rules are
>> >>> ambiguous? E.g. if partial matches (of different partially
>> >>> overlapping rules) use different CoS? Is this an error already
>> >>> when creating the PMR rules?
>> >>>
>> >>> -- Ola
>> >>>
>> >>>
>> >>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl
>> >>> mailto:ola.liljed...@linaro.org>>
>> >>> wrote:
>> >>>
>> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid
>> >>> > >>> > wrote:
>> >>>
>> >>>
>> >>> Guys,
>> >>>
>> >>> There are several versions of the Classifier API
>> >>> document floating in Google docs, here is one such
>> copy:
>> >>>
>> >>>
>> >>>
>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing
>> >>>
>> >>> Here is a different perspective on what PMR and COS
>> >>> mean,  perhaps in terms of an abstract hardware
>> >>> implementation:
>> >>>
>> >>> CoS is a meta-data field assigned to each packet as it
>> >>> traverses the classifier pipe-line.
>> >>>
>> >>> A packet is assigned an initial CoS by the pktio port
>> >>> which received it.
>> >>>
>> >>> Then, the packet is compared multiple times against a
>> >>> set of rules, and as it is common with TCAMs, each
>> >>> comparisons happens against all rules in parallel.
>> >>>
>> >>> Each rule has two values to match: 1. the current CoS
>> >>> meta-data field; and 2. a certain packet header field
>> >>> (value with a mask).
>> >>> If both these values match, the packet met-data CoS
>> >>> field is changed (Action taken) with the destination
>> >>> CoS of the matching rule.
>> >>>
>> >>> It is assumed that up to one such rule has ma

Re: [lng-odp] odp_packet_add/rem_data question