Re: [lng-odp] [API-NEXT PATCH 0/6] Rename queue types

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

I have considered unsched also, but really don’t like that since it would 
define the queue type by what it is not (instead of what it is). It would be 
also problematic term, if we’d need to define a third type in the future (e.g. 
sorted queue, etc).

This queue type provides the basic (or plain) set of queue features. Also I’d 
not call it “normal queue”, since sched queue may be the norm for one 
application and this for another. Term “basic” could have the same problem: 
e.g. atomic queue maybe the basic queue type for an application. In RFC, I used 
term “direct queue”, but I’d want to reserve the term “direct” for e.g. “direct 
pktio” mode and other direct accesses APIs (to other ODP blocks). When these 
plain (or scheduled) queues are connected to pktio, it’s an in-direction 
compared to the direct access.

After these patches the (commonly spoken) terminology would be

· Plain queues

· Parallel queues

· Atomic queues

· Ordered queues

… and potentially in the future

· Sorted queues, etc (queues with advanced features) …


/**
* Queue create
*
* Create a queue according to the queue parameters. Queue type is specified by
* queue parameter 'type'. Use odp_queue_param_init() to initialize parameters
* into their default values. Default values are also used when 'param' pointer
* is NULL. The default queue type is ODP_QUEUE_TYPE_PLAIN.
*
* @param nameQueue name
* @param param   Queue parameters. Uses defaults if NULL.
*
* @return Queue handle
* @retval ODP_QUEUE_INVALID on failure
*/
odp_queue_t odp_queue_create(const char *name, const odp_queue_param_t *param);


The default type is already documented. If user sets param to NULL or passes an 
initialized param (without any changes), the result is the same - the default 
settings. The type would be PLAIN in both cases.

-Petri



From: EXT Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Friday, January 29, 2016 5:21 AM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [API-NEXT PATCH 0/6] Rename queue types

This looks good, however PLAIN doesn't seem very intuitive as it's not 
descriptive of how the queue behaves.  How about simply QUEUE_TYPE_UNSCHED to 
contrast with QUEUE_TYPE_SCHED?  The real distinction here is whether the ODP 
scheduler or the application is managing the queue, i.e., whether the queue is 
scheduled or unscheduled.  Encoding that in the name would make that 
distinction very clear.  With the move of the type parameter into the 
odp_queue_param_t struct, omitting this struct on odp_queue_create() would 
default to creating an unscheduled queue.

Other than that, for this series:

Reviewed-and-tested-by: Bill Fischofer 
mailto:bill.fischo...@linaro.org>>

On Thu, Jan 28, 2016 at 7:24 AM, Petri Savolainen 
mailto:petri.savolai...@nokia.com>> wrote:
This patch set renames queue types and pktio modes with commonly used and
descriptive terms. Type of odp_queue_type_t is defined as enum and included
into queue parameters. Queue type and defines parameter usage (which params are
considered e.g. in queue creation), and is inline with other create APIs (pool,
timer, tm, ...).

These modifications are preparation for removal of PKTIN and PKOUT queue types,
and the single queue pktio API (odp_pktio_inq_setdef(), etc).



Petri Savolainen (6):
  api: sched: rename SCHED_SYNC_NONE to _PARALLEL
  api: queue: rename QUEUE_TYPE_POLL to _PLAIN
  api: pktio: rename pktio modes
  api: queue: define queue type as enum
  api: queue: moved queue type into queue parameters
  linux-generic: use term plain queue instead of poll

 example/classifier/odp_classifier.c| 16 ++--
 example/generator/odp_generator.c  |  9 ++-
 example/ipsec/odp_ipsec.c  | 43 ++-
 example/packet/odp_pktio.c | 14 ++--
 example/time/time_global_test.c|  8 +-
 example/timer/odp_timer_test.c |  5 +-
 include/odp/api/packet_io.h| 26 +++
 include/odp/api/queue.h| 68 +---
 include/odp/api/schedule_types.h   | 12 +--
 .../linux-generic/include/odp/plat/queue_types.h   |  8 --
 .../include/odp/plat/schedule_types.h  |  2 +-
 platform/linux-generic/odp_packet_io.c | 37 +
 platform/linux-generic/odp_queue.c | 13 +++-
 platform/linux-generic/odp_schedule.c  |  5 +-
 platform/linux-generic/pktio/loop.c|  2 +-
 platform/linux-generic/pktio/netmap.c  |  3 +-
 test/performance/odp_l2fwd.c   | 54 ++---
 test/performance/odp_pktio_perf.c  | 32 
 test/performance/odp_scheduling.c  | 20 ++---
 .../classification/odp_classification_common.c | 11 +--
 .../classification/odp_classification_test_pmr.c   | 13 ++--
 .../classification/odp_classifi

Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

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

From: EXT Ola Liljedahl [mailto:ola.liljed...@linaro.org]
Sent: Thursday, January 28, 2016 4:39 PM
To: Elo, Matias (Nokia - FI/Espoo) 
Cc: EXT Zoltan Kiss ; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation



On 28 January 2016 at 15:14, Elo, Matias (Nokia - FI/Espoo) 
mailto:matias@nokia.com>> wrote:
> -Original Message-
> From: EXT Zoltan Kiss 
> [mailto:zoltan.k...@linaro.org]
> Sent: Thursday, January 28, 2016 3:21 PM
> To: Elo, Matias (Nokia - FI/Espoo) 
> mailto:matias@nokia.com>>; lng-
> o...@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation
>
> Hi,
>
> On 28/01/16 07:03, Matias Elo wrote:
> > The current unoptimized DPDK pktio implementation achieves forwarding rates
> > (odp_l2fwd), which are comparable to netmap pktio and scale better with
> larger
> > thread counts. Some initial benchmark results below
> > (odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).
> >
> > Threads
> > 1   2   4   6   8   10  12
> > DPDK6.7 12  25.337.247.647.346.8MPPS
> > Netmap  6.1 12.625.832.438.938.638.4
>
> My performance results for ODP-DPDK are unidirectional between two
> ports, where one thread does the actual work (the other is idling), in
> that case it can achieve 14 Mpps. Is your number 6.7 Mpps comparable
> with this?

These numbers are combined throughputs from all 4 ports. No "maintenance"
thread is needed. With two ports and unidirectional traffic a single thread is 
able
to handle about 7 MPPS.

> Your main source of optimization seems to be to do zerocopy on RX side,
> but it needs change in linux-generic buffer management:
> - allow allocating zero length buffers, so you can append the buffers
> from the mbuf there
> - release the mbufs during odp_packet_free(), that needs some DPDK
> specific code, a destructor which calls rte_pktmbuf_free() on the stored
> pointers.
>
> But even with that there will be a cost of wrapping the mbuf's into
> linux-generic buffers, and you can't avoid copy on TX side.

Yep, this is in my to-do list.
Perhaps ODP linux-generic should use mbufs? I think that would allow for the 
greatest amount of friction-less coexistence.

At first I’m going to try to use mbufs along ODP packets as Zoltan described. 
Moving to using only mbufs is a whole different conversation and may introduce 
a new set of problems. E.g. mbuf not supporting some features we require. 
Still, it’s an option we could think about.

P.S. Please reply to messages using plaintext as HTML makes replying inline a 
pain.

-Matias


-Matias

>
> Regards,
>
> Zoltan
___
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 v8 API-NEXT 00/12] Separate CPU info codes into their platform files

[Maxim Uvarov]

Merged,

api change reviewed by Petri,

other change for a long time in the list, all my comments fixed.

thank you,
Maxim.

On 01/27/2016 11:56, hongbo.zh...@linaro.org wrote:

From: Hongbo Zhang 

v7->v8 changes:
  - use file name odp_cpu_arch.c in this patch set instead of odp_cpu_cycles.c
since the top api-next tree did this change

v6->v7 changes:
  - update symlink in patch 7

v5->v6 changes:
  - eliminate checkpatch.pl warnings

v4->v5 changes:
  - rebase to latest api-next branch

v3->v4 changes:
  - update patch 9 of platform naming
  - add new patch 12 to rename cpu_hz to cpu_hz_max

v2->v3 changes:
use "api: cpu:" tag in patch 8/11 title instead of "linux-generic: sysinfo"

v1->v2 changes:
  - don't create arch/arm/ since there isn't implementation now, use arch/linux
as default choice
  - create symlink to arch/linux/odp_cpu_cycles.c for powerpc, if absent this
arch cannot be compiled
  - add some clean-ups patches 8~11, these patches are against the previous ones
so send them together for better review and merge.

v1 notes:
This patch set separates the CPU info codes into their own platform sepcific
files.
It is common sence that the top general layer call an uniform interface to
initialize some plarform specific data structures, and this uniform interface
is implemented in their own platform specific files.
This patch set makes it.

Hongbo Zhang (12):
   linux-generic: sysinfo: move cpu_arch_str to odp_system_info_t
   linux-generic: sysinfo: use uniform call odp_sysinfo_parser
   linux-generic: sysinfo: rename odp_cpu_hz_current with odp_ prefix
   linux-generic: sysinfo: move x86 system info codes to its plarform
 file
   linux-generic: sysinfo: move MIPS system info codes to its plarform
 file
   linux-generic: sysinfo: move ARM system info codes to default arch
 file
   linux-generic: sysinfo: move PowerPC system info codes to its plarform
 file
   api: cpu: make frequency API return 0 on failure
   linux-generic: sysinfo: set values for cpu_arch_str
   linux-generic: sysinfo: apply per-CPU implementation to MIPS
   linux-generic: sysinfo: apply per-CPU implementation to PowerPC
   linux-generic: sysinfo: rename variable cpu_hz to cpu_hz_max

  configure.ac   |   1 +
  include/odp/api/cpu.h  |   4 +
  platform/linux-generic/Makefile.am |  10 +-
  .../linux-generic/arch/linux/odp_sysinfo_parse.c   |  19 ++
  .../linux-generic/arch/mips64/odp_sysinfo_parse.c  |  64 ++
  platform/linux-generic/arch/powerpc/odp/cpu_arch.h |   1 +
  platform/linux-generic/arch/powerpc/odp_cpu_arch.c |   1 +
  .../linux-generic/arch/powerpc/odp_sysinfo_parse.c |  63 ++
  .../linux-generic/arch/x86/odp_sysinfo_parse.c |  73 +++
  platform/linux-generic/include/odp_internal.h  |   7 +-
  platform/linux-generic/odp_system_info.c   | 220 +
  11 files changed, 246 insertions(+), 217 deletions(-)
  create mode 100644 platform/linux-generic/arch/linux/odp_sysinfo_parse.c
  create mode 100644 platform/linux-generic/arch/mips64/odp_sysinfo_parse.c
  create mode 12 platform/linux-generic/arch/powerpc/odp/cpu_arch.h
  create mode 12 platform/linux-generic/arch/powerpc/odp_cpu_arch.c
  create mode 100644 platform/linux-generic/arch/powerpc/odp_sysinfo_parse.c
  create mode 100644 platform/linux-generic/arch/x86/odp_sysinfo_parse.c



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

Re: [lng-odp] Setting MTU

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

If two applications share a link (pktio), both can send up to MTU sized frames 
… and if one of them wants send less than MTU sized frames, it’s free to do 
that (without forcing the other app to the same limit). From ODP API point of 
view, MTU is the limit of the local transmit buffer. Whereas from IP stack 
point of view (to avoid fragmenting) it could be the minimum of: local tx buf 
(== ODP MTU), gateway rx/tx buf and destination rx buf sizes.

-Petri

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Bill 
Fischofer
Sent: Thursday, January 28, 2016 7:25 PM
To: Mike Holmes
Cc: lng-odp
Subject: Re: [lng-odp] Setting MTU

The short answer is that MTU is not an application parameter but a system 
configuration parameter.  As such it is the domain of the control/management 
plane rather than the data plane.  The data plane simply uses the MTU that has 
been configured elsewhere.  Applications use higher-level segmenting like the 
TCP MSS that is negotiated for each connection.

As a practical matter, at 10Gb and above link speeds (what ODP is designed 
for), all interfaces should be running with 9K jumbo frames anyway.  MTU is 
something of a legacy from the early days of networking where primitive 
low-speed devices had extremely limited buffering capacities, necessitating 
these tiny MTU values.  They are really not relevant to 21st-century data plane 
processing.

On Thu, Jan 28, 2016 at 9:06 AM, Mike Holmes 
mailto:mike.hol...@linaro.org>> wrote:

commit 45598fea1a8a64ab49e191224784188382fbd466
Author: Petri Savolainen 
mailto:petri.savolai...@nokia.com>>
Date:   Thu Jan 21 11:39:29 2016 +0200

api: pktio: remove odp_pktio_set_mtu

Not all hardware can change MTU size from ODP application.

Reviewed-by: Petri Savolainen 
mailto:petri.savolai...@linaro.org>>
Signed-off-by: Maxim Uvarov 
mailto:maxim.uva...@linaro.org>>


On 28 January 2016 at 08:30, Zoltan Kiss 
mailto:zoltan.k...@linaro.org>> wrote:
Hi,

Is there a specific reason why we don't have an MTU setting API, but only one 
to query it?

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



--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"


___
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 2/2 v2] validation: timer: handle early exhaustion of pool

[Maxim Uvarov]

Merged, both patches.

Maxim.

On 01/27/2016 20:36, Zoltan Kiss wrote:

As per-thread caches might retain some elements, no particular thread
should assume that a certain amount of elements are available at any
time.
Also, to make the high watermark test reliable we should avoid releasing
timers.

Signed-off-by: Zoltan Kiss 
---

v2:
- keep high watermark test by bookkeeping the exact amounts of allocation. It
   needs a change in order of allocation to make sure no timer is released,
   otherwise the watermark becomes unpredictable
- use Ola's subject recommendation

  test/validation/timer/timer.c | 38 +++---
  1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/test/validation/timer/timer.c b/test/validation/timer/timer.c
index 5d89700..8f00788 100644
--- a/test/validation/timer/timer.c
+++ b/test/validation/timer/timer.c
@@ -37,6 +37,10 @@ static odp_timer_pool_t tp;
  /** @private Count of timeouts delivered too late */
  static odp_atomic_u32_t ndelivtoolate;
  
+/** @private Sum of all allocated timers from all threads. Thread-local

+ * caches may make this number lower than the capacity of the pool  */
+static odp_atomic_u32_t timers_allocated;
+
  /** @private min() function */
  static int min(int a, int b)
  {
@@ -274,7 +278,7 @@ static void handle_tmo(odp_event_t ev, bool stale, uint64_t 
prev_tick)
  static void *worker_entrypoint(void *arg TEST_UNUSED)
  {
int thr = odp_thread_id();
-   uint32_t i;
+   uint32_t i, allocated;
unsigned seed = thr;
int rc;
  
@@ -290,21 +294,30 @@ static void *worker_entrypoint(void *arg TEST_UNUSED)
  
  	/* Prepare all timers */

for (i = 0; i < NTIMERS; i++) {
-   tt[i].tim = odp_timer_alloc(tp, queue, &tt[i]);
-   if (tt[i].tim == ODP_TIMER_INVALID)
-   CU_FAIL_FATAL("Failed to allocate timer");
tt[i].ev = odp_timeout_to_event(odp_timeout_alloc(tbp));
-   if (tt[i].ev == ODP_EVENT_INVALID)
-   CU_FAIL_FATAL("Failed to allocate timeout");
+   if (tt[i].ev == ODP_EVENT_INVALID) {
+   LOG_DBG("Failed to allocate timeout (%d/%d)\n",
+   i, NTIMERS);
+   break;
+   }
+   tt[i].tim = odp_timer_alloc(tp, queue, &tt[i]);
+   if (tt[i].tim == ODP_TIMER_INVALID) {
+   LOG_DBG("Failed to allocate timer (%d/%d)\n",
+   i, NTIMERS);
+   odp_timeout_free(tt[i].ev);
+   break;
+   }
tt[i].ev2 = tt[i].ev;
tt[i].tick = TICK_INVALID;
}
+   allocated = i;
+   odp_atomic_fetch_add_u32(&timers_allocated, allocated);
  
  	odp_barrier_wait(&test_barrier);
  
  	/* Initial set all timers with a random expiration time */

uint32_t nset = 0;
-   for (i = 0; i < NTIMERS; i++) {
+   for (i = 0; i < allocated; i++) {
uint64_t tck = odp_timer_current_tick(tp) + 1 +
   odp_timer_ns_to_tick(tp,
(rand_r(&seed) % RANGE_MS)
@@ -336,7 +349,7 @@ static void *worker_entrypoint(void *arg TEST_UNUSED)
nrcv++;
}
prev_tick = odp_timer_current_tick(tp);
-   i = rand_r(&seed) % NTIMERS;
+   i = rand_r(&seed) % allocated;
if (tt[i].ev == ODP_EVENT_INVALID &&
(rand_r(&seed) % 2 == 0)) {
/* Timer active, cancel it */
@@ -384,7 +397,7 @@ static void *worker_entrypoint(void *arg TEST_UNUSED)
  
  	/* Cancel and free all timers */

uint32_t nstale = 0;
-   for (i = 0; i < NTIMERS; i++) {
+   for (i = 0; i < allocated; i++) {
(void)odp_timer_cancel(tt[i].tim, &tt[i].ev);
tt[i].tick = TICK_INVALID;
if (tt[i].ev == ODP_EVENT_INVALID)
@@ -428,7 +441,7 @@ static void *worker_entrypoint(void *arg TEST_UNUSED)
  
  	rc = odp_queue_destroy(queue);

CU_ASSERT(rc == 0);
-   for (i = 0; i < NTIMERS; i++) {
+   for (i = 0; i < allocated; i++) {
if (tt[i].ev != ODP_EVENT_INVALID)
odp_event_free(tt[i].ev);
}
@@ -504,6 +517,9 @@ void timer_test_odp_timer_all(void)
/* Initialize the shared timeout counter */
odp_atomic_init_u32(&ndelivtoolate, 0);
  
+	/* Initialize the number of finally allocated elements */

+   odp_atomic_init_u32(&timers_allocated, 0);
+
/* Create and start worker threads */
pthrd_arg thrdarg;
thrdarg.testcase = 0;
@@ -520,7 +536,7 @@ void timer_test_odp_timer_all(void)
CU_FAIL("odp_timer_pool_info");
CU_ASSERT(tpinfo.param.num_timers == (unsigned)num_workers * NTIMERS);
CU_ASSERT(tpinfo.cur_timers == 0);
-   CU_ASSE

[lng-odp] [PATCH API-NEXT 0/4] separate ODP_CACHE_LINE_SIZE to arch files

[hongbo . zhang]

From: Hongbo Zhang 

This is for bug https://bugs.linaro.org/show_bug.cgi?id=1881

This is on top of latest api-next branch because the latest
platform/linux-generic/arch/ directory is needed, so I use "API-NEXT" tag

There should be some check patch warnings for patch 4, because when new
symlink is added in patch, there will be warnings like the following but
they should be acceptable:

WARNING: adding a line without newline at end of file
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c

CHECK: spaces preferred around that '/' (ctx:VxV)
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c
   ^

CHECK: spaces preferred around that '/' (ctx:VxV)
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c


Hongbo Zhang (4):
  linux-generic: separate x86 ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: separate PowerPC ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: create ARM files and move ARM ODP_CACHE_LINE_SIZE in it

 configure.ac   |  1 +
 platform/linux-generic/Makefile.am |  2 ++
 platform/linux-generic/arch/arm/odp/cpu_arch.h | 24 +
 platform/linux-generic/arch/arm/odp_cpu_arch.c |  1 +
 .../linux-generic/arch/arm/odp_sysinfo_parse.c |  1 +
 platform/linux-generic/arch/mips64/odp/cpu_arch.h  |  2 ++
 platform/linux-generic/arch/powerpc/odp/cpu_arch.h | 25 +-
 platform/linux-generic/arch/x86/odp/cpu_arch.h |  2 ++
 platform/linux-generic/include/odp/align.h | 20 -
 .../linux-generic/include/odp_align_internal.h |  1 +
 10 files changed, 58 insertions(+), 21 deletions(-)
 create mode 100644 platform/linux-generic/arch/arm/odp/cpu_arch.h
 create mode 12 platform/linux-generic/arch/arm/odp_cpu_arch.c
 create mode 12 platform/linux-generic/arch/arm/odp_sysinfo_parse.c
 mode change 12 => 100644 platform/linux-generic/arch/powerpc/odp/cpu_arch.h

-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for MIPS.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
 platform/linux-generic/include/odp/align.h| 4 
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h 
b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
index 3bfa0dc..3e4a1ed 100644
--- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
+++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
@@ -11,6 +11,8 @@
 extern "C" {
 #endif
 
+#define ODP_CACHE_LINE_SIZE 128
+
 static inline void odp_cpu_pause(void)
 {
__asm__ __volatile__ ("nop");
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 4e045c6..6aba925 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -35,10 +35,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#elif defined __OCTEON__
-
-#define ODP_CACHE_LINE_SIZE 128
-
 #elif defined __powerpc__
 
 #define ODP_CACHE_LINE_SIZE 64
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 1/4] linux-generic: separate x86 ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for x86.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/x86/odp/cpu_arch.h  | 2 ++
 platform/linux-generic/include/odp/align.h  | 8 +---
 platform/linux-generic/include/odp_align_internal.h | 1 +
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/platform/linux-generic/arch/x86/odp/cpu_arch.h 
b/platform/linux-generic/arch/x86/odp/cpu_arch.h
index 997a954..24903ac 100644
--- a/platform/linux-generic/arch/x86/odp/cpu_arch.h
+++ b/platform/linux-generic/arch/x86/odp/cpu_arch.h
@@ -11,6 +11,8 @@
 extern "C" {
 #endif
 
+#define ODP_CACHE_LINE_SIZE 64
+
 static inline void odp_cpu_pause(void)
 {
 #ifdef __SSE2__
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index be8c9ae..4e045c6 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -31,11 +31,7 @@ extern "C" {
 
 #define ODP_FIELD_SIZEOF(type, member) sizeof(((type *)0)->member)
 
-#if defined __x86_64__ || defined __i386__
-
-#define ODP_CACHE_LINE_SIZE 64
-
-#elif defined __arm__ || defined __aarch64__
+#if defined __arm__ || defined __aarch64__
 
 #define ODP_CACHE_LINE_SIZE 64
 
@@ -47,8 +43,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#else
-#error GCC target not found
 #endif
 
 #else
diff --git a/platform/linux-generic/include/odp_align_internal.h 
b/platform/linux-generic/include/odp_align_internal.h
index 4ca5ceb..99788e3 100644
--- a/platform/linux-generic/include/odp_align_internal.h
+++ b/platform/linux-generic/include/odp_align_internal.h
@@ -18,6 +18,7 @@ extern "C" {
 #endif
 
 #include 
+#include 
 
 /** @addtogroup odp_compiler_optim
  *  @{
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 3/4] linux-generic: separate PowerPC ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for PowerPC.
The previous arch/powerpc/odp/cpu_arch.h was a symlink to the generic
arch/linux/odp/cpu_arch.h, but now this PowerPC header file has more
specific content than the generic one, so a real file is created and the
ODP_CACHE_LINE_SIZE is added to it.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/powerpc/odp/cpu_arch.h | 25 +-
 platform/linux-generic/include/odp/align.h |  4 
 2 files changed, 24 insertions(+), 5 deletions(-)
 mode change 12 => 100644 platform/linux-generic/arch/powerpc/odp/cpu_arch.h

diff --git a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h 
b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
deleted file mode 12
index 0617d7f..000
--- a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
+++ /dev/null
@@ -1 +0,0 @@
-../../linux/odp/cpu_arch.h
\ No newline at end of file
diff --git a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h 
b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
new file mode 100644
index 000..e56523f
--- /dev/null
+++ b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
@@ -0,0 +1,24 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PLAT_CPU_ARCH_H_
+#define ODP_PLAT_CPU_ARCH_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define ODP_CACHE_LINE_SIZE 64
+
+static inline void odp_cpu_pause(void)
+{
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 6aba925..75c02ae 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -35,10 +35,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#elif defined __powerpc__
-
-#define ODP_CACHE_LINE_SIZE 64
-
 #endif
 
 #else
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 4/4] linux-generic: create ARM files and move ARM ODP_CACHE_LINE_SIZE in it

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
And in the legacy codes there was no ARM architecture directory, so this
patch create it, the odp_cpu_arch.c and odp_sysinfo_parse.c are still
symlink to the general default ones under arch/linux/, and a real file
arm/odp/cpu_arch.h is created from the linux/odp/cpu_arch.h, and then the
ODP_CACHE_LINE_SIZE for ARM is moved to this arch specific file.

Signed-off-by: Hongbo Zhang 
---
 configure.ac   |  1 +
 platform/linux-generic/Makefile.am |  2 ++
 platform/linux-generic/arch/arm/odp/cpu_arch.h | 24 ++
 platform/linux-generic/arch/arm/odp_cpu_arch.c |  1 +
 .../linux-generic/arch/arm/odp_sysinfo_parse.c |  1 +
 platform/linux-generic/include/odp/align.h |  6 --
 6 files changed, 29 insertions(+), 6 deletions(-)
 create mode 100644 platform/linux-generic/arch/arm/odp/cpu_arch.h
 create mode 12 platform/linux-generic/arch/arm/odp_cpu_arch.c
 create mode 12 platform/linux-generic/arch/arm/odp_sysinfo_parse.c

diff --git a/configure.ac b/configure.ac
index 14a025e..23f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,6 +54,7 @@ AX_VALGRIND_CHECK
 ##
 AS_CASE([$host],
   [x86*], [ARCH=x86],
+  [arm*], [ARCH=arm],
   [mips64*], [ARCH=mips64],
   [powerpc*], [ARCH=powerpc],
   [ARCH=linux]
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index fded462..435d776 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -167,6 +167,8 @@ __LIB__libodp_la_SOURCES = \
 EXTRA_DIST = \
 arch/linux/odp_cpu_arch.c \
 arch/linux/odp_sysinfo_parse.c \
+arch/arm/odp_cpu_arch.c \
+arch/arm/odp_sysinfo_parse.c \
 arch/mips64/odp_cpu_arch.c \
 arch/mips64/odp_sysinfo_parse.c \
 arch/powerpc/odp_cpu_arch.c \
diff --git a/platform/linux-generic/arch/arm/odp/cpu_arch.h 
b/platform/linux-generic/arch/arm/odp/cpu_arch.h
new file mode 100644
index 000..e56523f
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp/cpu_arch.h
@@ -0,0 +1,24 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PLAT_CPU_ARCH_H_
+#define ODP_PLAT_CPU_ARCH_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define ODP_CACHE_LINE_SIZE 64
+
+static inline void odp_cpu_pause(void)
+{
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c 
b/platform/linux-generic/arch/arm/odp_cpu_arch.c
new file mode 12
index 000..c5fe400
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c
@@ -0,0 +1 @@
+../linux/odp_cpu_arch.c
\ No newline at end of file
diff --git a/platform/linux-generic/arch/arm/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
new file mode 12
index 000..2f368af
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
@@ -0,0 +1 @@
+../linux/odp_sysinfo_parse.c
\ No newline at end of file
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 75c02ae..81ef20f 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -31,12 +31,6 @@ extern "C" {
 
 #define ODP_FIELD_SIZEOF(type, member) sizeof(((type *)0)->member)
 
-#if defined __arm__ || defined __aarch64__
-
-#define ODP_CACHE_LINE_SIZE 64
-
-#endif
-
 #else
 #error Non-gcc compatible compiler
 #endif
-- 
2.1.4

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

Re: [lng-odp] [PATCH] linux-generic: queue: check invalid handle in odp_queue_destroy

[Maxim Uvarov]

Merged,
Maxim.

On 01/26/2016 14:38, Maxim Uvarov wrote:

Avoid seg. fault if invalid handle provided to queue destroy.

Reviewed-by: Zoltan Kiss 
Signed-off-by: Maxim Uvarov 
---
  platform/linux-generic/odp_queue.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/platform/linux-generic/odp_queue.c 
b/platform/linux-generic/odp_queue.c
index e39176c..7f11478 100644
--- a/platform/linux-generic/odp_queue.c
+++ b/platform/linux-generic/odp_queue.c
@@ -308,6 +308,9 @@ int odp_queue_destroy(odp_queue_t handle)
queue_entry_t *queue;
queue = queue_to_qentry(handle);
  
+	if (handle == ODP_QUEUE_INVALID)

+   return -1;
+
LOCK(&queue->s.lock);
if (queue->s.status == QUEUE_STATUS_FREE) {
UNLOCK(&queue->s.lock);


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

[lng-odp] [Bug 1881] linux-generic/arch does not contain architectures

[bugzilla-daemon]

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

--- Comment #2 from Hongbo Zhang  ---
patches sent out:
https://patches.linaro.org/60241/
https://patches.linaro.org/60242/
https://patches.linaro.org/60243/
https://patches.linaro.org/60244/

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

[Bala Manoharan]

Okay. I will incorporate these changes in the next version.

Regards,
Bala


On 28 January 2016 at 20:31, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
> This is otherwise OK (and exactly the feature I was missing in the call 
> yesterday), but I'm wondering the benefit of having both odp_pmr_set_t and 
> odp_pmr_t types. API would be simpler with only one type.
>
> To me odp_pmr_t is a odp_pmr_set_t with only one matching rule in it, right? 
> We could get rid of odp_pmr_set_t (use only odp_pmr_t since it's a shorter 
> name) and define that a odp_pmr_t can be build from N cascaded match rules.
>
>
> odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t match[], unsigned num,
>  odp_cos_t src_cos, odp_cos_t dst_cos);
>
> Maximum 'num' value could be defined in a capability struct (a conservative 
> system could define 1), with potential other constrains on the tree 
> dimensions (max num pmr's per cos, etc).
>
>
> -Petri
>
>
>
>> -Original Message-
>> From: EXT Balasubramanian Manoharan [mailto:bala.manoha...@linaro.org]
>> Sent: Friday, January 22, 2016 1:54 PM
>> To: lng-odp@lists.linaro.org
>> Cc: Savolainen, Petri (Nokia - FI/Espoo); Balasubramanian Manoharan
>> Subject: [API-NEXT PATCHv1 1/4] api: classification: add pmr create api
>>
>> Packet match rule creation is modified to include source and destination
>> class of service. Removes the ability to add any class of service directly
>> with pktio. If a PMR needs to be applied at the pktio level the same
>> should be applied to default class of service.
>>
>> Packet match rule destroy function is updated to removes the link between
>> the source and destination class of service.
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  include/odp/api/classification.h | 74 +--
>> -
>>  1 file changed, 24 insertions(+), 50 deletions(-)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index f46912e..59bd01d 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -50,7 +50,7 @@ extern "C" {
>>  /**
>>   * @def ODP_PMR_INVAL
>>   * Invalid odp_pmr_t value.
>> - * This value is returned from odp_pmr_create()
>> + * This value is returned from odp_cls_pmr_create()
>>   * function on failure.
>>   */
>>
>> @@ -286,50 +286,33 @@ typedef struct odp_pmr_match_t {
>>  } odp_pmr_match_t;
>>
>>  /**
>> - * Create a packet match rule with mask and value
>> + * Create a packet match rule between source and destination class of
>> service.
>> + * This packet matching rule is applied on all packets arriving at the
>> source
>> + * class of service and packets satisfying this PMR are sent to the
>> destination
>> + * class of service.
>>   *
>>   * @param[in]match   packet matching rule definition
>> + * @param[in]src_cos source CoS handle
>> + * @param[in]dst_cos destination CoS handle
>>   *
>>   * @return   Handle of the matching rule
>>   * @retval   ODP_PMR_INVAL on failure
>>   */
>> -odp_pmr_t odp_pmr_create(const odp_pmr_match_t *match);
>> -
>> +odp_pmr_t odp_cls_pmr_create(const odp_pmr_match_t *match, odp_cos_t
>> src_cos,
>> +  odp_cos_t dst_cos);
>>  /**
>> - * Invalidate a packet match rule and vacate its resources
>> + * Function to destroy a packet match rule
>> + * Destroying a PMR removes the link between the source and destination
>> + * class of service and this PMR will no longer be applied for packets
>> arriving
>> + * at the source class of service. All the resource associated with the
>> PMR
>> + * be release but the class of service will remain intact.
>>   *
>>   * @param[in]pmr_id  Identifier of the PMR to be destroyed
>>   *
>>   * @retval   0 on success
>>   * @retval   <0 on failure
>>   */
>> -int odp_pmr_destroy(odp_pmr_t pmr_id);
>> -
>> -/**
>> - * Apply a PMR to a pktio to assign a CoS.
>> - *
>> - * @param[in]pmr_id  PMR to be activated
>> - * @param[in]src_pktio   pktio to which this PMR is to be 
>> applied
>> - * @param[in]dst_cos CoS to be assigned by this PMR
>> - *
>> - * @retval   0 on success
>> - * @retval   <0 on failure
>> - */
>> -int odp_pktio_pmr_cos(odp_pmr_t pmr_id,
>> -   odp_pktio_t src_pktio, odp_cos_t dst_cos);
>> -
>> -/**
>> - * Cascade a PMR to refine packets from one CoS to another.
>> - *
>> - * @param[in]pmr_id  PMR to be activated
>> - * @param[in]src_cos CoS to be filtered
>> - * @param[in]dst_cos CoS to be assigned to packets filtered
>> - *   from src_cos that match pmr_id.
>> - *
>> - * @retval   0 on success
>> - * @retval   <0 on failure
>> - */
>> -int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t src_cos, odp_cos_t
>> dst_cos);
>> +int odp_cls_pmr_destroy(odp_pmr_t pmr_id);
>>
>>  /**
>>   * Inqui

Re: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> hongbo.zh...@linaro.org
> Sent: Friday, January 29, 2016 10:50 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS
> ODP_CACHE_LINE_SIZE to its arch file
> 
> From: Hongbo Zhang 
> 
> Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
> held in one header file, they should be moved to their own arch file.
> This patch moves ODP_CACHE_LINE_SIZE for MIPS.
> 
> Signed-off-by: Hongbo Zhang 
> ---
>  platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
>  platform/linux-generic/include/odp/align.h| 4 
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
> b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
> index 3bfa0dc..3e4a1ed 100644
> --- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
> +++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
> @@ -11,6 +11,8 @@
>  extern "C" {
>  #endif
> 
> +#define ODP_CACHE_LINE_SIZE 128


This is actually specific to octeon. MIPS spec allow extensions and Octeon does 
that. MIPS64 arch file could have MIPS defaults and then use #ifdef __OCTEON__ 
to override those which are Octeon specific. Maybe Cavium guys could help and 
check these arch definitions.


-Petri



> +
>  static inline void odp_cpu_pause(void)
>  {
>   __asm__ __volatile__ ("nop");
> diff --git a/platform/linux-generic/include/odp/align.h b/platform/linux-
> generic/include/odp/align.h
> index 4e045c6..6aba925 100644
> --- a/platform/linux-generic/include/odp/align.h
> +++ b/platform/linux-generic/include/odp/align.h
> @@ -35,10 +35,6 @@ extern "C" {
> 
>  #define ODP_CACHE_LINE_SIZE 64
> 
> -#elif defined __OCTEON__
> -
> -#define ODP_CACHE_LINE_SIZE 128
> -
>  #elif defined __powerpc__
> 
>  #define ODP_CACHE_LINE_SIZE 64
> --
> 2.1.4
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] odp timer thoughts

[Ivan Khoronzhuk]

On 28.01.16 20:31, Maxim Uvarov wrote:

I have some thoughts and questions about timer implementation in linux-generic.

Current implementation:

 sigev.sigev_notify  = SIGEV_THREAD;
 sigev.sigev_notify_function = timer_notify;
 sigev.sigev_value.sival_ptr = tp;
timer_create(CLOCK_MONOTONIC, &sigev, &tp->timerid);

timer create is usually called when timer pool is created. That is mean on the 
main thread, or control thread.
So it can consume only time of a CPU allowed to be used by control thread.
The notify function aggregates all scheduled timers from all worker threads and 
if some is expired then handles it.
So, if main thread (control) is assigned only one CPU, the notify function can 
be run only on this one main thread CPU,
the timer_create is executed only in main thread. It's one of the reason I've 
sent patch series to show how it can be done.
See:
https://lists.linaro.org/pipermail/lng-odp/2016-January/019734.html

[lng-odp] [PATCH 0/2] linux-generic: main control thread on CPU0
[lng-odp] [PATCH 1/2] linux-generic: cpumask_task: use cpumask got at init
[lng-odp] [PATCH 2/2] linux-generic: init: assign affinity for main thread

The notify function cannot run as signal for each thread as it's handler of all 
timers in one pool and receives signals one by one.
It on system notify function doesn't have enough time to finish notify 
function, the resolution is set incorrectly.


then:
  timer_settime(tp->timerid, 0, &ispec, NULL);

where:
timer_notify(sigval_t sigval)
{
 uint64_t prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick);
 /* Attempt to acquire the lock, check if the old value was clear */
 if (odp_spinlock_trylock(&tp->itimer_running)) {
 /* Scan timer array, looking for timers to expire */
 (void)odp_timer_pool_expire(tp, prev_tick);
 odp_spinlock_unlock(&tp->itimer_running);
 }

}

Now what I see from our test case.
1. We have bunch of workers.
2. Each worker starts timer.
3. Because it's SIGEV_THREAD on timer action new thread for notifier function 
started.

Usually it works well. Until there is load on cpu. (something like busy loop 
app.) There a lot of threads
just created by kernel. I.e. execution clone() call.

Based that I have question I have questions which is not quite clear for me:
1. Why SIGEV_THREAD was used?

2. When each worker will run bunch of threads (timer handler), they will fight 
for cpu time for context
switches between all that threads. Is there significant slowdown compare to one 
thread or signal usage?

3. What is priority of timer handler against to worker? Cpu affinity of handler 
thread? Should it
be SHED_FIFO? I.e. do we need to specify that thread attrs?

I think that creation thread each time only for increasing atomic counter is 
very expensive. So we can
rewrite that code to use SIGEV_SIGNAL or start thread manually and 
SIGEV_THREAD_ID  + semaphore.

If we will think about core isolation, than probably we have to work with 
signals. Don't know if core isolation
supports several threads on one core. Or even move all timer actions to 
separate core to not disturb worker
cores.

Thank you,
Maxim.








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


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

Re: [lng-odp] odp timer thoughts

[Ivan Khoronzhuk]

On 28.01.16 20:31, Maxim Uvarov wrote:

I have some thoughts and questions about timer implementation in linux-generic.

Current implementation:

 sigev.sigev_notify  = SIGEV_THREAD;
 sigev.sigev_notify_function = timer_notify;
 sigev.sigev_value.sival_ptr = tp;
timer_create(CLOCK_MONOTONIC, &sigev, &tp->timerid);
then:
  timer_settime(tp->timerid, 0, &ispec, NULL);

where:
timer_notify(sigval_t sigval)
{
 uint64_t prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick);
 /* Attempt to acquire the lock, check if the old value was clear */
 if (odp_spinlock_trylock(&tp->itimer_running)) {
 /* Scan timer array, looking for timers to expire */
 (void)odp_timer_pool_expire(tp, prev_tick);
 odp_spinlock_unlock(&tp->itimer_running);
 }

}

Now what I see from our test case.
1. We have bunch of workers.
2. Each worker starts timer.

In case of linux-generic implementation it means simply add one more handler function for 
the "notify" routine,
that is periodically called with resolution rate set at init while timer pool 
creation.
It doesn't start timer. Timer is already running after creation of timer pool.


3. Because it's SIGEV_THREAD on timer action new thread for notifier function 
started.

Usually it works well. Until there is load on cpu. (something like busy loop 
app.) There a lot of threads
just created by kernel. I.e. execution clone() call.

Based that I have question I have questions which is not quite clear for me:
1. Why SIGEV_THREAD was used?

2. When each worker will run bunch of threads (timer handler), they will fight 
for cpu time for context
switches between all that threads. Is there significant slowdown compare to one 
thread or signal usage?

3. What is priority of timer handler against to worker? Cpu affinity of handler 
thread? Should it
be SHED_FIFO? I.e. do we need to specify that thread attrs?

I think that creation thread each time only for increasing atomic counter is 
very expensive. So we can
rewrite that code to use SIGEV_SIGNAL or start thread manually and 
SIGEV_THREAD_ID  + semaphore.

If we will think about core isolation, than probably we have to work with 
signals. Don't know if core isolation
supports several threads on one core. Or even move all timer actions to 
separate core to not disturb worker
cores.

Thank you,
Maxim.








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


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

Re: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

[Hongbo Zhang]

On 29 January 2016 at 17:10, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
>> hongbo.zh...@linaro.org
>> Sent: Friday, January 29, 2016 10:50 AM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS
>> ODP_CACHE_LINE_SIZE to its arch file
>>
>> From: Hongbo Zhang 
>>
>> Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
>> held in one header file, they should be moved to their own arch file.
>> This patch moves ODP_CACHE_LINE_SIZE for MIPS.
>>
>> Signed-off-by: Hongbo Zhang 
>> ---
>>  platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
>>  platform/linux-generic/include/odp/align.h| 4 
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>> b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>> index 3bfa0dc..3e4a1ed 100644
>> --- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>> +++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>> @@ -11,6 +11,8 @@
>>  extern "C" {
>>  #endif
>>
>> +#define ODP_CACHE_LINE_SIZE 128
>
>
> This is actually specific to octeon. MIPS spec allow extensions and Octeon 
> does that. MIPS64 arch file could have MIPS defaults and then use #ifdef 
> __OCTEON__ to override those which are Octeon specific. Maybe Cavium guys 
> could help and check these arch definitions.
>
Then in the arch/mips64/odp/cpu_arch.h

we do like this:

#if defined __OCTEON__
#define ODP_CACHE_LINE_SIZE 128
#endif

This should be OK?

>
> -Petri
>
>
>
>> +
>>  static inline void odp_cpu_pause(void)
>>  {
>>   __asm__ __volatile__ ("nop");
>> diff --git a/platform/linux-generic/include/odp/align.h b/platform/linux-
>> generic/include/odp/align.h
>> index 4e045c6..6aba925 100644
>> --- a/platform/linux-generic/include/odp/align.h
>> +++ b/platform/linux-generic/include/odp/align.h
>> @@ -35,10 +35,6 @@ extern "C" {
>>
>>  #define ODP_CACHE_LINE_SIZE 64
>>
>> -#elif defined __OCTEON__
>> -
>> -#define ODP_CACHE_LINE_SIZE 128
>> -
>>  #elif defined __powerpc__
>>
>>  #define ODP_CACHE_LINE_SIZE 64
>> --
>> 2.1.4
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] odp timer thoughts

[Ivan Khoronzhuk]

On 29.01.16 00:54, Bill Fischofer wrote:

This is how you implement timers in HW as well.

A separate HW block operates a scan loop that constantly searches for timers to 
expire and creates events for those who do.
The rest of the system operates undisturbed.  For a SW analog in manycore 
systems you'd have service thread(s) running on dedicated core(s) doing the 
same.

Actually it can be emulated for linux-generic, but instead of HW block the pool 
of timers should be handled on one of control CPUS.
Each timer pool, no matter, created on main thread or worker thread has to be 
created with CPU affinity according to control cpumask.
Question is only which one and who decides which one, on linux-generic, let it 
be always CPU0, but with warn that CPU0 can be
shared with a worker thread (or maybe exclude it? it was proposed several times 
already, but rejected).



On Thu, Jan 28, 2016 at 12:41 PM, Stuart Haslam mailto:stuart.has...@linaro.org>> wrote:

On Thu, Jan 28, 2016 at 09:31:52PM +0300, Maxim Uvarov wrote:
 > I have some thoughts and questions about timer implementation in
 > linux-generic.
 >
 > Current implementation:
 >
 > sigev.sigev_notify  = SIGEV_THREAD;
 > sigev.sigev_notify_function = timer_notify;
 > sigev.sigev_value.sival_ptr = tp;
 >timer_create(CLOCK_MONOTONIC, &sigev, &tp->timerid);
 > then:
 >  timer_settime(tp->timerid, 0, &ispec, NULL);
 >
 > where:
 > timer_notify(sigval_t sigval)
 > {
 > uint64_t prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick);
 > /* Attempt to acquire the lock, check if the old value was clear */
 > if (odp_spinlock_trylock(&tp->itimer_running)) {
 > /* Scan timer array, looking for timers to expire */
 > (void)odp_timer_pool_expire(tp, prev_tick);
 > odp_spinlock_unlock(&tp->itimer_running);
 > }
 >
 > }
 >
 > Now what I see from our test case.
 > 1. We have bunch of workers.
 > 2. Each worker starts timer.
 > 3. Because it's SIGEV_THREAD on timer action new thread for notifier
 > function started.
 >
 > Usually it works well. Until there is load on cpu. (something like
 > busy loop app.) There a lot of threads
 > just created by kernel. I.e. execution clone() call.
 >
 > Based that I have question I have questions which is not quite clear for 
me:
 > 1. Why SIGEV_THREAD was used?
 >
 > 2. When each worker will run bunch of threads (timer handler), they
 > will fight for cpu time for context
 > switches between all that threads. Is there significant slowdown
 > compare to one thread or signal usage?
 >
 > 3. What is priority of timer handler against to worker? Cpu affinity
 > of handler thread? Should it
 > be SHED_FIFO? I.e. do we need to specify that thread attrs?
 >
 > I think that creation thread each time only for increasing atomic
 > counter is very expensive. So we can
 > rewrite that code to use SIGEV_SIGNAL or start thread manually and
 > SIGEV_THREAD_ID  + semaphore.
 >
 > If we will think about core isolation, than probably we have to work
 > with signals. Don't know if core isolation
 > supports several threads on one core. Or even move all timer actions
 > to separate core to not disturb worker
 > cores.
 >
 > Thank you,
 > Maxim.

+1

This is basically what was suggested here:

https://bugs.linaro.org/show_bug.cgi?id=1615#c18

--
Stuart.
___
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



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

Re: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

[Bala Manoharan]

On 29 January 2016 at 15:40, Hongbo Zhang  wrote:
> On 29 January 2016 at 17:10, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
>>> hongbo.zh...@linaro.org
>>> Sent: Friday, January 29, 2016 10:50 AM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] [PATCH API-NEXT 2/4] linux-generic: separate MIPS
>>> ODP_CACHE_LINE_SIZE to its arch file
>>>
>>> From: Hongbo Zhang 
>>>
>>> Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
>>> held in one header file, they should be moved to their own arch file.
>>> This patch moves ODP_CACHE_LINE_SIZE for MIPS.
>>>
>>> Signed-off-by: Hongbo Zhang 
>>> ---
>>>  platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
>>>  platform/linux-generic/include/odp/align.h| 4 
>>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> index 3bfa0dc..3e4a1ed 100644
>>> --- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> +++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
>>> @@ -11,6 +11,8 @@
>>>  extern "C" {
>>>  #endif
>>>
>>> +#define ODP_CACHE_LINE_SIZE 128
>>
>>
>> This is actually specific to octeon. MIPS spec allow extensions and Octeon 
>> does that. MIPS64 arch file could have MIPS defaults and then use #ifdef 
>> __OCTEON__ to override those which are Octeon specific. Maybe Cavium guys 
>> could help and check these arch definitions.
>>
> Then in the arch/mips64/odp/cpu_arch.h
>
> we do like this:
>
> #if defined __OCTEON__
> #define ODP_CACHE_LINE_SIZE 128
> #endif
>
> This should be OK?

Yes. This should be okay and if any other MIPS hw join in the future
they can add their #defines

Regards,
Bala

>
>>
>> -Petri
>>
>>
>>
>>> +
>>>  static inline void odp_cpu_pause(void)
>>>  {
>>>   __asm__ __volatile__ ("nop");
>>> diff --git a/platform/linux-generic/include/odp/align.h b/platform/linux-
>>> generic/include/odp/align.h
>>> index 4e045c6..6aba925 100644
>>> --- a/platform/linux-generic/include/odp/align.h
>>> +++ b/platform/linux-generic/include/odp/align.h
>>> @@ -35,10 +35,6 @@ extern "C" {
>>>
>>>  #define ODP_CACHE_LINE_SIZE 64
>>>
>>> -#elif defined __OCTEON__
>>> -
>>> -#define ODP_CACHE_LINE_SIZE 128
>>> -
>>>  #elif defined __powerpc__
>>>
>>>  #define ODP_CACHE_LINE_SIZE 64
>>> --
>>> 2.1.4
>>>
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCH v2 00/11] DPDK pktio implementation

[Matias Elo]

V2:
- Check the number of mbuf segments in mbuf_to_pkt() (Zoltan Kiss)
- Copy DPDK RSS hash to ODP packet header in mbuf_to_pkt() (Zoltan Kiss)
- Compare packet length to MTU value in pkt_to_mbuf() and drop too long packets

This patch set implements new DPDK pktio type, which operates in the same manner
as the existing ODP interface types. DPDK mbuf packets are copied during
receive/send to maintain compatibility with the linux-generic pktio.

The current unoptimized DPDK pktio implementation achieves forwarding rates
(odp_l2fwd), which are comparable to netmap pktio and scale better with larger
thread counts. Some initial benchmark results below
(odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).

Threads
1   2   4   6   8   10  12
DPDK6.7 12  25.337.247.647.346.8MPPS
Netmap  6.1 12.625.832.438.938.638.4


From 8 threads and onwards the throughput is limited by the NICs (Intel 82599).

Build and usage information can be found from DEPENDENCIES. The DPDK
initialization code is copied from the odp-dpdk branch.

Matias Elo (11):
  linux-generic: pktio: add DPDK pktio build support
  linux-generic: pktio: initial DPDK pktio implementation
  linux-generic: dpdk: add get/set functions for mtu, promisc mode, and
capability
  linux-generic: dpdk: add rx/tx locking
  linux-generic: dpdk: add odp_pktio_link_status()
  linux-generic: dpdk: add dpdk_setup_port()
  linux-generic: dpdk: add functions for fetching packet input/output
queues
  linux-generic: dpdk: add odp_pktio_input_queues_config()
  linux-generic: dpdk: add odp_pktio_output_queues_config()
  linux-generic: dpdk: handle ixgbe_pmd minimum burst size
  linux-generic: dpdk: close resources in odp_pktio_close()

 DEPENDENCIES   |  54 ++
 platform/linux-generic/Makefile.am |   2 +
 platform/linux-generic/include/odp_internal.h  |   5 +
 platform/linux-generic/include/odp_packet_dpdk.h   |  69 ++
 .../linux-generic/include/odp_packet_io_internal.h |   3 +
 platform/linux-generic/m4/configure.m4 |   1 +
 platform/linux-generic/m4/odp_dpdk.m4  |  43 ++
 platform/linux-generic/odp_init.c  |  12 +
 platform/linux-generic/pktio/dpdk.c| 855 +
 platform/linux-generic/pktio/io_ops.c  |   3 +
 10 files changed, 1047 insertions(+)
 create mode 100644 platform/linux-generic/include/odp_packet_dpdk.h
 create mode 100644 platform/linux-generic/m4/odp_dpdk.m4
 create mode 100644 platform/linux-generic/pktio/dpdk.c

-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 03/11] linux-generic: dpdk: add get/set functions for mtu, promisc mode, and capability

[Matias Elo]

Add dpdk_mtu_get(), dpdk_promisc_mode_set(),
dpdk_promisc_mode_get(), and dpdk_capability() functions.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_dpdk.h |  1 +
 platform/linux-generic/pktio/dpdk.c  | 56 +---
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index 5676f4c..6ebcb3e 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -35,6 +35,7 @@ typedef struct {
struct rte_mempool *pkt_pool; /**< DPDK packet pool */
odp_pktio_capability_t  capa; /**< interface capabilities */
uint32_t data_room;   /**< maximum packet length */
+   uint16_t mtu; /**< maximum transmission unit */
/** DPDK packet pool name (pktpool_) */
char pool_name[IF_NAMESIZE + 8];
uint8_t port_id;  /**< DPDK port identifier */
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index d7f0d24..ccb659a 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -273,9 +273,11 @@ static int dpdk_open(odp_pktio_t id ODP_UNUSED,
 odp_pool_t pool)
 {
pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+   struct rte_eth_dev_info dev_info;
struct rte_mempool *pkt_pool;
odp_pool_info_t pool_info;
uint16_t data_room;
+   uint16_t mtu;
 
if (getenv("ODP_PKTIO_DISABLE_DPDK"))
return -1;
@@ -314,6 +316,17 @@ static int dpdk_open(odp_pktio_t id ODP_UNUSED,
return -1;
}
 
+   memset(&dev_info, 0, sizeof(struct rte_eth_dev_info));
+   rte_eth_dev_info_get(pkt_dpdk->port_id, &dev_info);
+   pkt_dpdk->capa.max_input_queues = dev_info.max_rx_queues;
+   pkt_dpdk->capa.max_output_queues = dev_info.max_tx_queues;
+
+   if (rte_eth_dev_get_mtu(pktio_entry->s.pkt_dpdk.port_id, &mtu) != 0) {
+   ODP_ERR("Failed to read interface MTU\n");
+   return -1;
+   }
+   pkt_dpdk->mtu = mtu;
+
/* Look for previously opened packet pool */
pkt_pool = rte_mempool_lookup(pkt_dpdk->pool_name);
if (pkt_pool == NULL)
@@ -483,6 +496,14 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
uint16_t pkt_len;
 
for (i = 0; i < num; i++) {
+   pkt_len = odp_packet_len(pkt_table[i]);
+
+   if (pkt_len > pkt_dpdk->mtu) {
+   if (i == 0)
+   __odp_errno = EMSGSIZE;
+   break;
+   }
+
mbuf_table[i] = rte_pktmbuf_alloc(pkt_dpdk->pkt_pool);
if (mbuf_table[i] == NULL) {
ODP_ERR("Failed to alloc mbuf\n");
@@ -490,7 +511,6 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
}
 
rte_pktmbuf_reset(mbuf_table[i]);
-   pkt_len = odp_packet_len(pkt_table[i]);
 
data = rte_pktmbuf_append(mbuf_table[i], pkt_len);
 
@@ -573,6 +593,32 @@ static int dpdk_mac_addr_get(pktio_entry_t *pktio_entry, 
void *mac_addr)
return ETH_ALEN;
 }
 
+static int dpdk_mtu_get(pktio_entry_t *pktio_entry)
+{
+   return pktio_entry->s.pkt_dpdk.mtu;
+}
+
+static int dpdk_promisc_mode_set(pktio_entry_t *pktio_entry, odp_bool_t enable)
+{
+   if (enable)
+   rte_eth_promiscuous_enable(pktio_entry->s.pkt_dpdk.port_id);
+   else
+   rte_eth_promiscuous_disable(pktio_entry->s.pkt_dpdk.port_id);
+   return 0;
+}
+
+static int dpdk_promisc_mode_get(pktio_entry_t *pktio_entry)
+{
+   return rte_eth_promiscuous_get(pktio_entry->s.pkt_dpdk.port_id);
+}
+
+static int dpdk_capability(pktio_entry_t *pktio_entry,
+  odp_pktio_capability_t *capa)
+{
+   *capa = pktio_entry->s.pkt_dpdk.capa;
+   return 0;
+}
+
 const pktio_if_ops_t dpdk_pktio_ops = {
.name = "dpdk",
.init = NULL,
@@ -586,11 +632,11 @@ const pktio_if_ops_t dpdk_pktio_ops = {
.recv_queue = dpdk_recv_queue,
.send_queue = dpdk_send_queue,
.link_status = NULL,
-   .mtu_get = NULL,
-   .promisc_mode_set = NULL,
-   .promisc_mode_get = NULL,
+   .mtu_get = dpdk_mtu_get,
+   .promisc_mode_set = dpdk_promisc_mode_set,
+   .promisc_mode_get = dpdk_promisc_mode_get,
.mac_get = dpdk_mac_addr_get,
-   .capability = NULL,
+   .capability = dpdk_capability,
.input_queues_config = NULL,
.output_queues_config = NULL,
.in_queues = NULL,
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 05/11] linux-generic: dpdk: add odp_pktio_link_status()

[Matias Elo]

Implement odp_pktio_link_status() for dpdk pktio.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/dpdk.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 3ddabbf..4b007bc 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -638,6 +638,17 @@ static int dpdk_capability(pktio_entry_t *pktio_entry,
return 0;
 }
 
+static int dpdk_link_status(pktio_entry_t *pktio_entry)
+{
+   struct rte_eth_link link;
+
+   memset(&link, 0, sizeof(struct rte_eth_link));
+
+   rte_eth_link_get_nowait(pktio_entry->s.pkt_dpdk.port_id, &link);
+
+   return link.link_status;
+}
+
 const pktio_if_ops_t dpdk_pktio_ops = {
.name = "dpdk",
.init = NULL,
@@ -650,7 +661,7 @@ const pktio_if_ops_t dpdk_pktio_ops = {
.send = dpdk_send,
.recv_queue = dpdk_recv_queue,
.send_queue = dpdk_send_queue,
-   .link_status = NULL,
+   .link_status = dpdk_link_status,
.mtu_get = dpdk_mtu_get,
.promisc_mode_set = dpdk_promisc_mode_set,
.promisc_mode_get = dpdk_promisc_mode_get,
-- 
1.9.1

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

Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

[Maxim Uvarov]

On 01/28/2016 17:24, Elo, Matias (Nokia - FI/Espoo) wrote:

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Maxim
Uvarov
Sent: Thursday, January 28, 2016 3:10 PM
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

Matias, can you please add validation test case to that series the same
thing which we use for odp-dpkd?
I.e. with PCAP PMD. to test functionality.

You can use normal pktio validation tests (e.g. sudo ODP_PKTIO_IF0=1 
ODP_PKTIO_IF1=3 ./test/validation/pktio/pktio_main).
Currently, most of the tests fails as  _pktio_wait_linkup() in called in 
invalid locations, but I'm sending a separate patch soon to fix this.

Or did you mean something else?

-Matias


Something else. DPDK has pcap PMD to run app without hardware on any 
device. We did that for make check on odp-dpdk to make

test pass on vethX devices. The same idea as we do for raw sockets.

file:
https://git.linaro.org/lng/odp-dpdk.git/blob/HEAD:/platform/linux-dpdk/test/pktio/pktio_run
line:
export ODP_PLATFORM_PARAMS="-n 4 --vdev eth_pcap0,iface=$IF0 --vdev 
eth_pcap1,iface=$IF1"


But I'm not sure if it's applicable to your patches. But if you can add 
some check to validation it without hardware

it will be very helpful to catch bugs as soon as possible.

Thanks,
Maxim.



Thanks,
Maxim.

On 01/28/2016 10:03, Matias Elo wrote:

Implements new DPDK pktio type, which operates in the same manner as the
existing ODP interface types. DPDK mbuf packets are copied during

receive/send

to maintain compatibility with the linux-generic pktio.

The current unoptimized DPDK pktio implementation achieves forwarding rates
(odp_l2fwd), which are comparable to netmap pktio and scale better with

larger

thread counts. Some initial benchmark results below
(odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).

Threads
1   2   4   6   8   10  12
DPDK6.7 12  25.337.247.647.346.8MPPS
Netmap  6.1 12.625.832.438.938.638.4


  From 8 threads and onwards the throughput is limited by the NICs (Intel

82599).

Build and usage information can be found from DEPENDENCIES. The DPDK
initialization code is copied from the odp-dpdk branch.

Matias Elo (11):
linux-generic: pktio: add DPDK pktio build support
linux-generic: pktio: initial DPDK pktio implementation
linux-generic: dpdk: add get/set functions for mtu, promisc mode, and
  capability
linux-generic: dpdk: add rx/tx locking
linux-generic: dpdk: add odp_pktio_link_status()
linux-generic: dpdk: add dpdk_setup_port()
linux-generic: dpdk: add functions for fetching packet input/output
  queues
linux-generic: dpdk: add odp_pktio_input_queues_config()
linux-generic: dpdk: add odp_pktio_output_queues_config()
linux-generic: dpdk: handle ixgbe_pmd minimum burst size
linux-generic: dpdk: close resources in odp_pktio_close()

   DEPENDENCIES   |  54 ++
   platform/linux-generic/Makefile.am |   2 +
   platform/linux-generic/include/odp_internal.h  |   5 +
   platform/linux-generic/include/odp_packet_dpdk.h   |  68 ++
   .../linux-generic/include/odp_packet_io_internal.h |   3 +
   platform/linux-generic/m4/configure.m4 |   1 +
   platform/linux-generic/m4/odp_dpdk.m4  |  43 ++
   platform/linux-generic/odp_init.c  |  12 +
   platform/linux-generic/pktio/dpdk.c| 826 
+
   platform/linux-generic/pktio/io_ops.c  |   3 +
   10 files changed, 1017 insertions(+)
   create mode 100644 platform/linux-generic/include/odp_packet_dpdk.h
   create mode 100644 platform/linux-generic/m4/odp_dpdk.m4
   create mode 100644 platform/linux-generic/pktio/dpdk.c


___
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] [API-NEXT PATCH v2 06/11] linux-generic: dpdk: add dpdk_setup_port()

[Matias Elo]

Add helper function dpdk_setup_port() for configuring
DPDK ports.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/dpdk.c | 62 -
 1 file changed, 41 insertions(+), 21 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 4b007bc..1df0e90 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -151,6 +151,43 @@ static int dpdk_netdev_is_valid(const char *s)
return 1;
 }
 
+static int dpdk_setup_port(pktio_entry_t *pktio_entry)
+{
+   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+   int ret;
+   struct rte_eth_conf port_conf = {
+   .rxmode = {
+   .mq_mode = ETH_MQ_RX_RSS,
+   .max_rx_pkt_len = pkt_dpdk->data_room,
+   .split_hdr_size = 0,
+   .header_split   = 0,
+   .hw_ip_checksum = 0,
+   .hw_vlan_filter = 0,
+   .jumbo_frame= 1,
+   .hw_strip_crc   = 0,
+   },
+   .rx_adv_conf = {
+   .rss_conf = {
+   .rss_key = NULL,
+   .rss_hf = ETH_RSS_IP,
+   },
+   },
+   .txmode = {
+   .mq_mode = ETH_MQ_TX_NONE,
+   },
+   };
+
+   ret = rte_eth_dev_configure(pkt_dpdk->port_id,
+   pktio_entry->s.num_in_queue,
+   pktio_entry->s.num_out_queue, &port_conf);
+   if (ret < 0) {
+   ODP_ERR("Failed to setup device: err=%d, port=%" PRIu8 "\n",
+   ret, pkt_dpdk->port_id);
+   return -1;
+   }
+   return 0;
+}
+
 static int dpdk_close(pktio_entry_t *pktio_entry ODP_UNUSED)
 {
return 0;
@@ -361,32 +398,15 @@ static int dpdk_start(pktio_entry_t *pktio_entry)
int ret;
unsigned i;
 
-   struct rte_eth_conf port_conf = {
-   .rxmode = {
-   .max_rx_pkt_len = pkt_dpdk->data_room,
-   .split_hdr_size = 0,
-   .header_split   = 0, /**< Header Split disabled */
-   .hw_ip_checksum = 0, /**< IP checksum offload disabled 
*/
-   .hw_vlan_filter = 0, /**< VLAN filtering disabled */
-   .jumbo_frame= 1, /**< Jumbo Frame Support enabled */
-   .hw_strip_crc   = 0, /**< CRC stripped by hardware */
-   },
-   .txmode = {
-   .mq_mode = ETH_MQ_TX_NONE,
-   },
-   };
-
/* DPDK doesn't support nb_rx_q/nb_tx_q being 0 */
if (!pktio_entry->s.num_in_queue)
pktio_entry->s.num_in_queue = 1;
if (!pktio_entry->s.num_out_queue)
pktio_entry->s.num_out_queue = 1;
-   ret = rte_eth_dev_configure(pkt_dpdk->port_id,
-   pktio_entry->s.num_in_queue,
-   pktio_entry->s.num_out_queue, &port_conf);
-   if (ret < 0) {
-   ODP_ERR("Cannot configure device: err=%d, port=%" PRIu8 "\n",
-   ret, pkt_dpdk->port_id);
+
+   /* init port */
+   if (dpdk_setup_port(pktio_entry)) {
+   ODP_ERR("Failed to configure device\n");
return -1;
}
/* Init TX queues */
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 01/11] linux-generic: pktio: add DPDK pktio build support

[Matias Elo]

Add initial support for building ODP with DPDK pktio.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 DEPENDENCIES   | 54 
 platform/linux-generic/Makefile.am |  2 +
 platform/linux-generic/include/odp_packet_dpdk.h   | 19 +
 .../linux-generic/include/odp_packet_io_internal.h |  3 +
 platform/linux-generic/m4/configure.m4 |  1 +
 platform/linux-generic/m4/odp_dpdk.m4  | 43 ++
 platform/linux-generic/pktio/dpdk.c| 96 ++
 platform/linux-generic/pktio/io_ops.c  |  3 +
 8 files changed, 221 insertions(+)
 create mode 100644 platform/linux-generic/include/odp_packet_dpdk.h
 create mode 100644 platform/linux-generic/m4/odp_dpdk.m4
 create mode 100644 platform/linux-generic/pktio/dpdk.c

diff --git a/DEPENDENCIES b/DEPENDENCIES
index c2711d5..fe7df40 100644
--- a/DEPENDENCIES
+++ b/DEPENDENCIES
@@ -154,6 +154,60 @@ Prerequisites for building the OpenDataPlane (ODP) API
netmap kernel module is loaded. If socket I/O is desired instead, it can be
activated by setting the environment variable ODP_PKTIO_DISABLE_NETMAP.
 
+3.4 DPDK (optional)
+
+   Use DPDK for ODP packet I/O.
+
+3.4.1 Building DPDK
+
+   DPDK packet I/O has been tested to work with DPDK v2.2.0.
+
+   # Checkout DPDK code
+   $ git clone http://dpdk.org/git/dpdk
+   $ cd dpdk
+   $ git checkout v2.2.0
+
+   # Make and edit DPDK configuration
+   $ make config T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc
+   $ cd x86_64-native-linuxapp-gcc
+   $ sed -ri 's,(CONFIG_RTE_BUILD_COMBINE_LIBS=).*,\1y,' .config
+   # To use I/O without DPDK supported NIC's enable pcap pmd:
+   $ sed -ri 's,(CONFIG_RTE_LIBRTE_PMD_PCAP=).*,\1y,' .config
+   $ cd ..
+
+   # Build DPDK
+   $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS="-fPIC"
+
+3.4.2 Setup system
+
+   # Load DPDK modules
+   $ sudo /sbin/modprobe uio
+   $ cd 
+   $ sudo insmod x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
+
+   Reserve and mount hugepages and bind supported interfaces to DPDK modules
+   following the DPDK documentation. ODP DPDK packet I/O has been tested with
+   512 x 2MB hugepages. All this can be done with the DPDK setup script
+   (/tools/setup.sh).
+
+3.4.3 Building ODP
+
+   $ cd 
+   $ ./bootstrap
+   $ ./configure --with-dpdk-path=/x86_64-native-linuxapp-gcc
+   $ make
+
+3.4.4 Running ODP with DPDK I/O
+
+   ODP applications will try use DPDK for packet I/O by default. If some other
+   I/O type is desired instead, DPDK I/O can be disabled by setting the
+   environment variable ODP_PKTIO_DISABLE_DPDK.
+
+   DPDK interfaces are accessed using indices. For example, two first DPDK
+   interfaces can be used with the odp_l2fwd example as follows:
+   $ cd 
+   $ sudo ./test/performance/odp_l2fwd -i 0,1 -c 2 -m 0
+
 4.0 Packages needed to build API tests
 
Cunit test framework version 2.1-3 is required
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 94f1408..9a57d95 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -103,6 +103,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_packet_io_internal.h \
  ${srcdir}/include/odp_packet_io_queue.h \
  ${srcdir}/include/odp_packet_netmap.h \
+ ${srcdir}/include/odp_packet_dpdk.h \
  ${srcdir}/include/odp_packet_socket.h \
  ${srcdir}/include/odp_packet_tap.h \
  ${srcdir}/include/odp_pkt_queue_internal.h \
@@ -139,6 +140,7 @@ __LIB__libodp_la_SOURCES = \
   pktio/pktio_common.c \
   pktio/loop.c \
   pktio/netmap.c \
+  pktio/dpdk.c \
   pktio/socket.c \
   pktio/socket_mmap.c \
   pktio/sysfs.c \
diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
new file mode 100644
index 000..af3a7c3
--- /dev/null
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -0,0 +1,19 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PACKET_DPDK_H
+#define ODP_PACKET_DPDK_H
+
+#include 
+#include 
+
+/** Packet IO using DPDK interface */
+typedef struct {
+   odp_pool_t pool;  /**< pool to alloc packets from */
+   odp_pktio_capability_t  capa; /**< interface capabilities */
+} pkt_dpdk_t;
+
+#endif
diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index a734877..e732b85 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -32,6 +32,7 @@ extern "C" {
 #include 
 #include 
 #incl

[lng-odp] [API-NEXT PATCH v2 07/11] linux-generic: dpdk: add functions for fetching packet input/output queues

[Matias Elo]

Implement odp_pktio_in_queues(), odp_pktio_pktin_queues(),
and odp_pktio_pktout_queues() functions.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/dpdk.c | 48 ++---
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 1df0e90..233c6f8 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -669,6 +669,48 @@ static int dpdk_link_status(pktio_entry_t *pktio_entry)
return link.link_status;
 }
 
+static int dpdk_in_queues(pktio_entry_t *pktio_entry, odp_queue_t queues[],
+ int num)
+{
+   int i;
+   int num_queues = pktio_entry->s.num_in_queue;
+
+   if (queues && num > 0) {
+   for (i = 0; i < num && i < num_queues; i++)
+   queues[i] = pktio_entry->s.in_queue[i].queue;
+   }
+
+   return num_queues;
+}
+
+static int dpdk_pktin_queues(pktio_entry_t *pktio_entry,
+odp_pktin_queue_t queues[], int num)
+{
+   int i;
+   int num_queues = pktio_entry->s.num_in_queue;
+
+   if (queues && num > 0) {
+   for (i = 0; i < num && i < num_queues; i++)
+   queues[i] = pktio_entry->s.in_queue[i].pktin;
+   }
+
+   return num_queues;
+}
+
+static int dpdk_pktout_queues(pktio_entry_t *pktio_entry,
+ odp_pktout_queue_t queues[], int num)
+{
+   int i;
+   int num_queues = pktio_entry->s.num_out_queue;
+
+   if (queues && num > 0) {
+   for (i = 0; i < num && i < num_queues; i++)
+   queues[i] = pktio_entry->s.out_queue[i].pktout;
+   }
+
+   return num_queues;
+}
+
 const pktio_if_ops_t dpdk_pktio_ops = {
.name = "dpdk",
.init = NULL,
@@ -689,9 +731,9 @@ const pktio_if_ops_t dpdk_pktio_ops = {
.capability = dpdk_capability,
.input_queues_config = NULL,
.output_queues_config = NULL,
-   .in_queues = NULL,
-   .pktin_queues = NULL,
-   .pktout_queues = NULL
+   .in_queues = dpdk_in_queues,
+   .pktin_queues = dpdk_pktin_queues,
+   .pktout_queues = dpdk_pktout_queues
 };
 
 #endif /* ODP_DPDK */
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 09/11] linux-generic: dpdk: add odp_pktio_output_queues_config()

[Matias Elo]

Implement odp_pktio_output_queues_config() function.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/dpdk.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 1ff0927..10600db 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -352,6 +352,16 @@ static int dpdk_input_queues_config(pktio_entry_t 
*pktio_entry,
return 0;
 }
 
+static int dpdk_output_queues_config(pktio_entry_t *pktio_entry,
+const odp_pktio_output_queue_param_t *p)
+{
+   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+
+   pkt_dpdk->lockless_tx = p->single_user;
+
+   return 0;
+}
+
 static int dpdk_open(odp_pktio_t id ODP_UNUSED,
 pktio_entry_t *pktio_entry,
 const char *netdev,
@@ -778,7 +788,7 @@ const pktio_if_ops_t dpdk_pktio_ops = {
.mac_get = dpdk_mac_addr_get,
.capability = dpdk_capability,
.input_queues_config = dpdk_input_queues_config,
-   .output_queues_config = NULL,
+   .output_queues_config = dpdk_output_queues_config,
.in_queues = dpdk_in_queues,
.pktin_queues = dpdk_pktin_queues,
.pktout_queues = dpdk_pktout_queues
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 04/11] linux-generic: dpdk: add rx/tx locking

[Matias Elo]

Add locking support to dpdk_recv_queue() and
dpdk_send_queue().

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_dpdk.h |  5 +
 platform/linux-generic/pktio/dpdk.c  | 19 +++
 2 files changed, 24 insertions(+)

diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index 6ebcb3e..f4a3e2c 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -39,6 +40,10 @@ typedef struct {
/** DPDK packet pool name (pktpool_) */
char pool_name[IF_NAMESIZE + 8];
uint8_t port_id;  /**< DPDK port identifier */
+   odp_bool_t lockless_rx;   /**< no locking for rx */
+   odp_bool_t lockless_tx;   /**< no locking for tx */
+   odp_ticketlock_t rx_lock[PKTIO_MAX_QUEUES];  /**< RX queue locks */
+   odp_ticketlock_t tx_lock[PKTIO_MAX_QUEUES];  /**< TX queue locks */
 } pkt_dpdk_t;
 
 #endif
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index ccb659a..3ddabbf 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -278,6 +278,7 @@ static int dpdk_open(odp_pktio_t id ODP_UNUSED,
odp_pool_info_t pool_info;
uint16_t data_room;
uint16_t mtu;
+   int i;
 
if (getenv("ODP_PKTIO_DISABLE_DPDK"))
return -1;
@@ -345,6 +346,11 @@ static int dpdk_open(odp_pktio_t id ODP_UNUSED,
RTE_PKTMBUF_HEADROOM;
pkt_dpdk->data_room = RTE_MIN(pool_info.params.pkt.len, data_room);
 
+   for (i = 0; i < PKTIO_MAX_QUEUES; i++) {
+   odp_ticketlock_init(&pkt_dpdk->rx_lock[i]);
+   odp_ticketlock_init(&pkt_dpdk->tx_lock[i]);
+   }
+
return 0;
 }
 
@@ -530,16 +536,23 @@ static int dpdk_recv_queue(pktio_entry_t *pktio_entry,
   odp_packet_t pkt_table[],
   int num)
 {
+   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
uint16_t nb_rx;
 
struct rte_mbuf *rx_mbufs[num];
 
+   if (!pkt_dpdk->lockless_rx)
+   odp_ticketlock_lock(&pkt_dpdk->rx_lock[index]);
+
nb_rx = rte_eth_rx_burst(pktio_entry->s.pkt_dpdk.port_id, index,
 rx_mbufs, num);
 
if (nb_rx > 0)
nb_rx = mbuf_to_pkt(pktio_entry, pkt_table, rx_mbufs, nb_rx);
 
+   if (!pktio_entry->s.pkt_dpdk.lockless_rx)
+   odp_ticketlock_unlock(&pkt_dpdk->rx_lock[index]);
+
return nb_rx;
 }
 
@@ -561,6 +574,9 @@ static int dpdk_send_queue(pktio_entry_t *pktio_entry,
int i;
int mbufs;
 
+   if (!pktio_entry->s.pkt_dpdk.lockless_tx)
+   odp_ticketlock_lock(&pkt_dpdk->tx_lock[index]);
+
mbufs = pkt_to_mbuf(pktio_entry, tx_mbufs, pkt_table, num);
 
tx_pkts = rte_eth_tx_burst(pkt_dpdk->port_id, index,
@@ -573,6 +589,9 @@ static int dpdk_send_queue(pktio_entry_t *pktio_entry,
 
odp_packet_free_multi(pkt_table, tx_pkts);
 
+   if (!pktio_entry->s.pkt_dpdk.lockless_tx)
+   odp_ticketlock_unlock(&pkt_dpdk->tx_lock[index]);
+
if (odp_unlikely(tx_pkts == 0 && __odp_errno != 0))
return -1;
 
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 10/11] linux-generic: dpdk: handle ixgbe_pmd minimum burst size

[Matias Elo]

ixgbe_pmd has a minimum supported RX burst size of 4. If
less than 4 packets are requested with
odp_pktio_recv_queue(),  rte_eth_rx_burst() is called with
nb_pkts=4 and the possibly received extra packets are cached
for the next dpdk_recv_queue() call to use.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_dpdk.h | 18 +
 platform/linux-generic/pktio/dpdk.c  | 47 ++--
 2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index 3244175..d1e152f 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -30,6 +30,21 @@ _ODP_STATIC_ASSERT(DPDK_NB_MBUF % DPDK_MEMPOOL_CACHE_SIZE == 
0 &&
   , "DPDK mempool cache size failure");
 #endif
 
+#define DPDK_IXGBE_MIN_RX_BURST 4
+
+/** Cache for storing packets */
+struct pkt_cache_t {
+   /** array for storing extra RX packets */
+   struct rte_mbuf *pkt[DPDK_IXGBE_MIN_RX_BURST];
+   unsigned idx; /**< head of cache */
+   unsigned count;   /**< packets in cache */
+};
+
+typedef union {
+   struct pkt_cache_t s;
+   uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(struct pkt_cache_t))];
+} pkt_cache_t ODP_ALIGNED_CACHE;
+
 /** Packet IO using DPDK interface */
 typedef struct {
odp_pool_t pool;  /**< pool to alloc packets from */
@@ -40,11 +55,14 @@ typedef struct {
/** DPDK packet pool name (pktpool_) */
char pool_name[IF_NAMESIZE + 8];
uint8_t port_id;  /**< DPDK port identifier */
+   unsigned min_rx_burst;/**< minimum RX burst size */
odp_pktin_hash_proto_t hash;  /**< Packet input hash protocol */
odp_bool_t lockless_rx;   /**< no locking for rx */
odp_bool_t lockless_tx;   /**< no locking for tx */
odp_ticketlock_t rx_lock[PKTIO_MAX_QUEUES];  /**< RX queue locks */
odp_ticketlock_t tx_lock[PKTIO_MAX_QUEUES];  /**< TX queue locks */
+   /** cache for storing extra RX packets */
+   pkt_cache_t rx_cache[PKTIO_MAX_QUEUES];
 } pkt_dpdk_t;
 
 #endif
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 10600db..d35896e 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -423,6 +423,11 @@ static int dpdk_open(odp_pktio_t id ODP_UNUSED,
}
pkt_dpdk->mtu = mtu;
 
+   if (!strcmp(dev_info.driver_name, "rte_ixgbe_pmd"))
+   pkt_dpdk->min_rx_burst = DPDK_IXGBE_MIN_RX_BURST;
+   else
+   pkt_dpdk->min_rx_burst = 0;
+
/* Look for previously opened packet pool */
pkt_pool = rte_mempool_lookup(pkt_dpdk->pool_name);
if (pkt_pool == NULL)
@@ -615,15 +620,51 @@ static int dpdk_recv_queue(pktio_entry_t *pktio_entry,
   int num)
 {
pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+   pkt_cache_t *rx_cache = &pkt_dpdk->rx_cache[index];
uint16_t nb_rx;
-
struct rte_mbuf *rx_mbufs[num];
+   int i;
+   unsigned cache_idx;
 
if (!pkt_dpdk->lockless_rx)
odp_ticketlock_lock(&pkt_dpdk->rx_lock[index]);
+   /**
+* ixgbe_pmd has a minimum supported RX burst size ('min_rx_burst'). If
+* 'num' < 'min_rx_burst', 'min_rx_burst' is used as rte_eth_rx_burst()
+* argument and the possibly received extra packets are cached for the
+* next dpdk_recv_queue() call to use.
+*
+* Either use cached packets or receive new ones. Not both during the
+* same call. */
+   if (rx_cache->s.count > 0) {
+   for (i = 0; i < num && rx_cache->s.count; i++) {
+   rx_mbufs[i] = rx_cache->s.pkt[rx_cache->s.idx];
+   rx_cache->s.idx++;
+   rx_cache->s.count--;
+   }
+   nb_rx = i;
+   } else if ((unsigned)num < pkt_dpdk->min_rx_burst) {
+   struct rte_mbuf *new_mbufs[pkt_dpdk->min_rx_burst];
 
-   nb_rx = rte_eth_rx_burst(pktio_entry->s.pkt_dpdk.port_id, index,
-rx_mbufs, num);
+   nb_rx = rte_eth_rx_burst(pktio_entry->s.pkt_dpdk.port_id, index,
+new_mbufs, pkt_dpdk->min_rx_burst);
+
+   rx_cache->s.idx = 0;
+   for (i = 0; i < nb_rx; i++) {
+   if (i < num) {
+   rx_mbufs[i] = new_mbufs[i];
+   } else {
+   cache_idx = rx_cache->s.count;
+   rx_cache->s.pkt[cache_idx] = new_mbufs[i];
+   rx_cache->s.count++;
+   }
+   }
+   nb_

[lng-odp] [API-NEXT PATCH v2 08/11] linux-generic: dpdk: add odp_pktio_input_queues_config()

[Matias Elo]

Implement odp_pktio_input_queues_config() function and add
helper rss_conf_to_hash_proto() for converting
odp_pktin_hash_proto_t to struct rte_eth_rss_conf.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_dpdk.h |  1 +
 platform/linux-generic/pktio/dpdk.c  | 60 +---
 2 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index f4a3e2c..3244175 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -40,6 +40,7 @@ typedef struct {
/** DPDK packet pool name (pktpool_) */
char pool_name[IF_NAMESIZE + 8];
uint8_t port_id;  /**< DPDK port identifier */
+   odp_pktin_hash_proto_t hash;  /**< Packet input hash protocol */
odp_bool_t lockless_rx;   /**< no locking for rx */
odp_bool_t lockless_tx;   /**< no locking for tx */
odp_ticketlock_t rx_lock[PKTIO_MAX_QUEUES];  /**< RX queue locks */
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 233c6f8..1ff0927 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -151,10 +151,39 @@ static int dpdk_netdev_is_valid(const char *s)
return 1;
 }
 
+static void rss_conf_to_hash_proto(struct rte_eth_rss_conf *rss_conf,
+  const odp_pktin_hash_proto_t *hash_proto)
+{
+   memset(rss_conf, 0, sizeof(struct rte_eth_rss_conf));
+
+   if (hash_proto->proto.ipv4_udp)
+   rss_conf->rss_hf |= ETH_RSS_NONFRAG_IPV4_UDP;
+   if (hash_proto->proto.ipv4_tcp)
+   rss_conf->rss_hf |= ETH_RSS_NONFRAG_IPV4_TCP;
+   if (hash_proto->proto.ipv4)
+   rss_conf->rss_hf |= ETH_RSS_IPV4 | ETH_RSS_FRAG_IPV4 |
+   ETH_RSS_NONFRAG_IPV4_OTHER;
+   if (hash_proto->proto.ipv6_udp)
+   rss_conf->rss_hf |= ETH_RSS_NONFRAG_IPV6_UDP |
+   ETH_RSS_IPV6_UDP_EX;
+   if (hash_proto->proto.ipv6_tcp)
+   rss_conf->rss_hf |= ETH_RSS_NONFRAG_IPV6_TCP |
+   ETH_RSS_IPV6_TCP_EX;
+   if (hash_proto->proto.ipv6)
+   rss_conf->rss_hf |= ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV6 |
+   ETH_RSS_NONFRAG_IPV6_OTHER |
+   ETH_RSS_IPV6_EX;
+   rss_conf->rss_key = NULL;
+}
+
 static int dpdk_setup_port(pktio_entry_t *pktio_entry)
 {
-   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
int ret;
+   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+   struct rte_eth_rss_conf rss_conf;
+
+   rss_conf_to_hash_proto(&rss_conf, &pkt_dpdk->hash);
+
struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode = ETH_MQ_RX_RSS,
@@ -167,10 +196,7 @@ static int dpdk_setup_port(pktio_entry_t *pktio_entry)
.hw_strip_crc   = 0,
},
.rx_adv_conf = {
-   .rss_conf = {
-   .rss_key = NULL,
-   .rss_hf = ETH_RSS_IP,
-   },
+   .rss_conf = rss_conf,
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
@@ -304,6 +330,28 @@ int odp_dpdk_pktio_init_local(void)
return 0;
 }
 
+static int dpdk_input_queues_config(pktio_entry_t *pktio_entry,
+   const odp_pktio_input_queue_param_t *p)
+{
+   odp_pktio_input_mode_t mode = pktio_entry->s.param.in_mode;
+   odp_bool_t single_user;
+
+   /**
+* Scheduler synchronizes input queue polls. Only single thread
+* at a time polls a queue */
+   if (mode == ODP_PKTIN_MODE_SCHED)
+   single_user = 1;
+   else
+   single_user = p->single_user;
+
+   if (p->hash_enable && p->num_queues > 1)
+   pktio_entry->s.pkt_dpdk.hash = p->hash_proto;
+
+   pktio_entry->s.pkt_dpdk.lockless_rx = single_user;
+
+   return 0;
+}
+
 static int dpdk_open(odp_pktio_t id ODP_UNUSED,
 pktio_entry_t *pktio_entry,
 const char *netdev,
@@ -729,7 +777,7 @@ const pktio_if_ops_t dpdk_pktio_ops = {
.promisc_mode_get = dpdk_promisc_mode_get,
.mac_get = dpdk_mac_addr_get,
.capability = dpdk_capability,
-   .input_queues_config = NULL,
+   .input_queues_config = dpdk_input_queues_config,
.output_queues_config = NULL,
.in_queues = dpdk_in_queues,
.pktin_queues = dpdk_pktin_queues,
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 11/11] linux-generic: dpdk: close resources in odp_pktio_close()

[Matias Elo]

Free/close open resources in odp_pktio_close().

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_dpdk.h |  1 +
 platform/linux-generic/pktio/dpdk.c  | 19 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index d1e152f..2dd66ca 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -54,6 +54,7 @@ typedef struct {
uint16_t mtu; /**< maximum transmission unit */
/** DPDK packet pool name (pktpool_) */
char pool_name[IF_NAMESIZE + 8];
+   odp_bool_t started;   /**< DPDK device has been started */
uint8_t port_id;  /**< DPDK port identifier */
unsigned min_rx_burst;/**< minimum RX burst size */
odp_pktin_hash_proto_t hash;  /**< Packet input hash protocol */
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index d35896e..5cd7b60 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -214,8 +214,23 @@ static int dpdk_setup_port(pktio_entry_t *pktio_entry)
return 0;
 }
 
-static int dpdk_close(pktio_entry_t *pktio_entry ODP_UNUSED)
+static int dpdk_close(pktio_entry_t *pktio_entry)
 {
+   pkt_dpdk_t *pkt_dpdk = &pktio_entry->s.pkt_dpdk;
+   unsigned idx;
+   unsigned i, j;
+
+   /* Free cache packets */
+   for (i = 0; i < PKTIO_MAX_QUEUES; i++) {
+   idx = pkt_dpdk->rx_cache[i].s.idx;
+
+   for (j = 0; j < pkt_dpdk->rx_cache[i].s.count; j++)
+   rte_pktmbuf_free(pkt_dpdk->rx_cache[i].s.pkt[idx++]);
+   }
+
+   if (pkt_dpdk->started)
+   rte_eth_dev_close(pkt_dpdk->port_id);
+
return 0;
 }
 
@@ -501,6 +516,8 @@ static int dpdk_start(pktio_entry_t *pktio_entry)
ret, port_id);
return -1;
}
+   pkt_dpdk->started = 1;
+
return 0;
 }
 
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH v2 02/11] linux-generic: pktio: initial DPDK pktio implementation

[Matias Elo]

Initial implementation of the DPDK pktio type.
Initialization code copied from the odp-dpdk branch.

Reviewed-by: Petri Savolainen 
Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_internal.h|   5 +
 platform/linux-generic/include/odp_packet_dpdk.h |  24 +
 platform/linux-generic/odp_init.c|  12 +
 platform/linux-generic/pktio/dpdk.c  | 553 ++-
 4 files changed, 570 insertions(+), 24 deletions(-)

diff --git a/platform/linux-generic/include/odp_internal.h 
b/platform/linux-generic/include/odp_internal.h
index aac2ba9..a23efe3 100644
--- a/platform/linux-generic/include/odp_internal.h
+++ b/platform/linux-generic/include/odp_internal.h
@@ -112,6 +112,11 @@ void _odp_flush_caches(void);
 int odp_cpuinfo_parser(FILE *file, odp_system_info_t *sysinfo);
 uint64_t odp_cpu_hz_current(int id);
 
+#ifdef ODP_DPDK
+int odp_dpdk_pktio_init_global(void);
+int odp_dpdk_pktio_init_local(void);
+#endif
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index af3a7c3..5676f4c 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++ b/platform/linux-generic/include/odp_packet_dpdk.h
@@ -10,10 +10,34 @@
 #include 
 #include 
 
+#include 
+
+#ifdef ODP_DPDK
+#include 
+#include 
+
+#define DPDK_MEMORY_MB 512
+#define DPDK_NB_MBUF 8192
+#define DPDK_MBUF_BUF_SIZE RTE_MBUF_DEFAULT_BUF_SIZE
+#define DPDK_MEMPOOL_CACHE_SIZE 32
+#define DPDK_NM_RX_DESC  128
+#define DPDK_NM_TX_DESC  512
+
+_ODP_STATIC_ASSERT(DPDK_NB_MBUF % DPDK_MEMPOOL_CACHE_SIZE == 0 &&
+  DPDK_MEMPOOL_CACHE_SIZE <= RTE_MEMPOOL_CACHE_MAX_SIZE &&
+  DPDK_MEMPOOL_CACHE_SIZE <= DPDK_MBUF_BUF_SIZE / 1.5
+  , "DPDK mempool cache size failure");
+#endif
+
 /** Packet IO using DPDK interface */
 typedef struct {
odp_pool_t pool;  /**< pool to alloc packets from */
+   struct rte_mempool *pkt_pool; /**< DPDK packet pool */
odp_pktio_capability_t  capa; /**< interface capabilities */
+   uint32_t data_room;   /**< maximum packet length */
+   /** DPDK packet pool name (pktpool_) */
+   char pool_name[IF_NAMESIZE + 8];
+   uint8_t port_id;  /**< DPDK port identifier */
 } pkt_dpdk_t;
 
 #endif
diff --git a/platform/linux-generic/odp_init.c 
b/platform/linux-generic/odp_init.c
index 6ad3320..584e659 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -37,6 +37,12 @@ int odp_init_global(const odp_init_t *params,
}
stage = SYSINFO_INIT;
 
+#ifdef ODP_DPDK
+   if (odp_dpdk_pktio_init_global() < 0) {
+   ODP_ERR("ODP dpdk pktio init failed.\n");
+   return -1;
+   }
+#endif
if (odp_shm_init_global()) {
ODP_ERR("ODP shm init failed.\n");
goto init_failed;
@@ -215,6 +221,12 @@ int odp_init_local(odp_thread_type_t thr_type)
}
stage = THREAD_INIT;
 
+#ifdef ODP_DPDK
+   if (odp_dpdk_pktio_init_local()) {
+   ODP_ERR("ODP dpdk pktio local init failed.\n");
+   return -1;
+   }
+#endif
if (odp_pktio_init_local()) {
ODP_ERR("ODP packet io local init failed.\n");
goto init_fail;
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 31fe9ae..d7f0d24 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -8,64 +8,569 @@
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+#include 
+
+/* Has dpdk_pktio_init() been called */
+static odp_bool_t dpdk_initialized;
+
+#define PMD_EXT(drv) \
+extern void devinitfn_##drv(void)
+
+PMD_EXT(cryptodev_aesni_mb_pmd_drv);
+PMD_EXT(pmd_qat_drv);
+PMD_EXT(pmd_af_packet_drv);
+PMD_EXT(rte_bnx2x_driver);
+PMD_EXT(rte_bnx2xvf_driver);
+PMD_EXT(bond_drv);
+PMD_EXT(rte_cxgbe_driver);
+PMD_EXT(em_pmd_drv);
+PMD_EXT(pmd_igb_drv);
+PMD_EXT(pmd_igbvf_drv);
+PMD_EXT(rte_enic_driver);
+PMD_EXT(rte_fm10k_driver);
+PMD_EXT(rte_i40e_driver);
+PMD_EXT(rte_i40evf_driver);
+PMD_EXT(rte_ixgbe_driver);
+PMD_EXT(rte_ixgbevf_driver);
+PMD_EXT(rte_mlx4_driver);
+PMD_EXT(rte_mlx5_driver);
+PMD_EXT(pmd_mpipe_xgbe_drv);
+PMD_EXT(pmd_mpipe_gbe_drv);
+PMD_EXT(rte_nfp_net_driver);
+PMD_EXT(pmd_null_drv);
+PMD_EXT(pmd_pcap_drv);
+PMD_EXT(pmd_ring_drv);
+PMD_EXT(pmd_szedata2_drv);
+PMD_EXT(rte_virtio_driver);
+PMD_EXT(rte_vmxnet3_driver);
+PMD_EXT(pmd_xenvirt_drv);
+
+/*
+ * This function is not called from anywhere, it's only purpose is to make sure
+ * that if ODP and DPDK are statically linked to an application, the GCC
+ * constuctors of the PMDs are linked as well. Otherwise the linker would omit
+ * them. It's not an issue with dynamic linking. */
+void refer_constructors(void);
+void refer_constructors(void)
+{
+#ifd

[lng-odp] [API-NEXT PATCH 3/3] validation: atomic: added lock free op test

[Petri Savolainen]

Test atomic_op bit fields and odp_atomic_lock_free_u64().

Signed-off-by: Petri Savolainen 
---
 test/validation/atomic/atomic.c | 107 
 test/validation/atomic/atomic.h |   1 +
 2 files changed, 108 insertions(+)

diff --git a/test/validation/atomic/atomic.c b/test/validation/atomic/atomic.c
index 1a46774..24c0de7 100644
--- a/test/validation/atomic/atomic.c
+++ b/test/validation/atomic/atomic.c
@@ -741,6 +741,112 @@ void atomic_test_atomic_non_relaxed(void)
   CHECK_MAX_MIN | CHECK_XCHG);
 }
 
+void atomic_test_atomic_op_lock_free(void)
+{
+   odp_atomic_op_t atomic_op;
+   int ret_null, ret;
+
+   memset(&atomic_op, 0xff, sizeof(odp_atomic_op_t));
+   atomic_op.all_bits = 0;
+
+   CU_ASSERT(atomic_op.all_bits == 0);
+   CU_ASSERT(atomic_op.op.init  == 0);
+   CU_ASSERT(atomic_op.op.load  == 0);
+   CU_ASSERT(atomic_op.op.store == 0);
+   CU_ASSERT(atomic_op.op.fetch_add == 0);
+   CU_ASSERT(atomic_op.op.add   == 0);
+   CU_ASSERT(atomic_op.op.fetch_sub == 0);
+   CU_ASSERT(atomic_op.op.sub   == 0);
+   CU_ASSERT(atomic_op.op.fetch_inc == 0);
+   CU_ASSERT(atomic_op.op.inc   == 0);
+   CU_ASSERT(atomic_op.op.fetch_dec == 0);
+   CU_ASSERT(atomic_op.op.dec   == 0);
+   CU_ASSERT(atomic_op.op.min   == 0);
+   CU_ASSERT(atomic_op.op.max   == 0);
+   CU_ASSERT(atomic_op.op.cas   == 0);
+   CU_ASSERT(atomic_op.op.xchg  == 0);
+
+   /* Test setting first, last and couple of other bits */
+   atomic_op.op.init = 1;
+   CU_ASSERT(atomic_op.op.init  == 1);
+   CU_ASSERT(atomic_op.all_bits != 0);
+   atomic_op.op.init = 0;
+   CU_ASSERT(atomic_op.all_bits == 0);
+
+   atomic_op.op.xchg = 1;
+   CU_ASSERT(atomic_op.op.xchg  == 1);
+   CU_ASSERT(atomic_op.all_bits != 0);
+   atomic_op.op.xchg = 0;
+   CU_ASSERT(atomic_op.all_bits == 0);
+
+   atomic_op.op.add = 1;
+   CU_ASSERT(atomic_op.op.add   == 1);
+   CU_ASSERT(atomic_op.all_bits != 0);
+   atomic_op.op.add = 0;
+   CU_ASSERT(atomic_op.all_bits == 0);
+
+   atomic_op.op.dec = 1;
+   CU_ASSERT(atomic_op.op.dec   == 1);
+   CU_ASSERT(atomic_op.all_bits != 0);
+   atomic_op.op.dec = 0;
+   CU_ASSERT(atomic_op.all_bits == 0);
+
+   memset(&atomic_op, 0xff, sizeof(odp_atomic_op_t));
+   ret  = odp_atomic_lock_free_u64(&atomic_op);
+   ret_null = odp_atomic_lock_free_u64(NULL);
+
+   CU_ASSERT(ret == ret_null);
+
+   /* Init operation is not atomic by the spec. Call to
+* odp_atomic_lock_free_u64() zeros it but never sets it. */
+
+   if (ret == 0) {
+   /* none are lock free */
+   CU_ASSERT(atomic_op.all_bits == 0);
+   CU_ASSERT(atomic_op.op.init  == 0);
+   CU_ASSERT(atomic_op.op.load  == 0);
+   CU_ASSERT(atomic_op.op.store == 0);
+   CU_ASSERT(atomic_op.op.fetch_add == 0);
+   CU_ASSERT(atomic_op.op.add   == 0);
+   CU_ASSERT(atomic_op.op.fetch_sub == 0);
+   CU_ASSERT(atomic_op.op.sub   == 0);
+   CU_ASSERT(atomic_op.op.fetch_inc == 0);
+   CU_ASSERT(atomic_op.op.inc   == 0);
+   CU_ASSERT(atomic_op.op.fetch_dec == 0);
+   CU_ASSERT(atomic_op.op.dec   == 0);
+   CU_ASSERT(atomic_op.op.min   == 0);
+   CU_ASSERT(atomic_op.op.max   == 0);
+   CU_ASSERT(atomic_op.op.cas   == 0);
+   CU_ASSERT(atomic_op.op.xchg  == 0);
+   }
+
+   if (ret == 1) {
+   /* some are lock free */
+   CU_ASSERT(atomic_op.all_bits != 0);
+   CU_ASSERT(atomic_op.op.init  == 0);
+   }
+
+   if (ret == 2) {
+   /* all are lock free */
+   CU_ASSERT(atomic_op.all_bits != 0);
+   CU_ASSERT(atomic_op.op.init  == 0);
+   CU_ASSERT(atomic_op.op.load  == 1);
+   CU_ASSERT(atomic_op.op.store == 1);
+   CU_ASSERT(atomic_op.op.fetch_add == 1);
+   CU_ASSERT(atomic_op.op.add   == 1);
+   CU_ASSERT(atomic_op.op.fetch_sub == 1);
+   CU_ASSERT(atomic_op.op.sub   == 1);
+   CU_ASSERT(atomic_op.op.fetch_inc == 1);
+   CU_ASSERT(atomic_op.op.inc   == 1);
+   CU_ASSERT(atomic_op.op.fetch_dec == 1);
+   CU_ASSERT(atomic_op.op.dec   == 1);
+   CU_ASSERT(atomic_op.op.min   == 1);
+   CU_ASSERT(atomic_op.op.max   == 1);
+   CU_ASSERT(atomic_op.op.cas   == 1);
+   CU_ASSERT(atomic_op.op.xchg  == 1);
+   }
+}
+
 odp_testinfo_t atomic_suite_atomic[] = {
ODP_TEST_INFO(atomic_test_atomic_inc_de

[lng-odp] [API-NEXT PATCH 2/3] validation: remove remaining references synchronizers

[Petri Savolainen]

Synchronizers suite was split into atomic, lock and barrier
suites.

Signed-off-by: Petri Savolainen 
---
 test/validation/atomic/atomic.c   | 16 
 test/validation/atomic/atomic.h   | 12 ++--
 test/validation/barrier/barrier.h |  4 ++--
 test/validation/lock/lock.h   |  4 ++--
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/test/validation/atomic/atomic.c b/test/validation/atomic/atomic.c
index 78b9ffd..1a46774 100644
--- a/test/validation/atomic/atomic.c
+++ b/test/validation/atomic/atomic.c
@@ -720,22 +720,22 @@ void atomic_test_atomic_fetch_add_sub(void)
test_atomic_functional(test_atomic_fetch_add_sub_thread, 0);
 }
 
-void synchronizers_test_atomic_max_min(void)
+void atomic_test_atomic_max_min(void)
 {
test_atomic_functional(test_atomic_max_min_thread, CHECK_MAX_MIN);
 }
 
-void synchronizers_test_atomic_cas_inc_dec(void)
+void atomic_test_atomic_cas_inc_dec(void)
 {
test_atomic_functional(test_atomic_cas_inc_dec_thread, 0);
 }
 
-void synchronizers_test_atomic_xchg(void)
+void atomic_test_atomic_xchg(void)
 {
test_atomic_functional(test_atomic_xchg_thread, CHECK_XCHG);
 }
 
-void synchronizers_test_atomic_non_relaxed(void)
+void atomic_test_atomic_non_relaxed(void)
 {
test_atomic_functional(test_atomic_non_relaxed_thread,
   CHECK_MAX_MIN | CHECK_XCHG);
@@ -746,10 +746,10 @@ odp_testinfo_t atomic_suite_atomic[] = {
ODP_TEST_INFO(atomic_test_atomic_add_sub),
ODP_TEST_INFO(atomic_test_atomic_fetch_inc_dec),
ODP_TEST_INFO(atomic_test_atomic_fetch_add_sub),
-   ODP_TEST_INFO(synchronizers_test_atomic_max_min),
-   ODP_TEST_INFO(synchronizers_test_atomic_cas_inc_dec),
-   ODP_TEST_INFO(synchronizers_test_atomic_xchg),
-   ODP_TEST_INFO(synchronizers_test_atomic_non_relaxed),
+   ODP_TEST_INFO(atomic_test_atomic_max_min),
+   ODP_TEST_INFO(atomic_test_atomic_cas_inc_dec),
+   ODP_TEST_INFO(atomic_test_atomic_xchg),
+   ODP_TEST_INFO(atomic_test_atomic_non_relaxed),
ODP_TEST_INFO_NULL,
 };
 
diff --git a/test/validation/atomic/atomic.h b/test/validation/atomic/atomic.h
index 44d0833..8c65581 100644
--- a/test/validation/atomic/atomic.h
+++ b/test/validation/atomic/atomic.h
@@ -4,8 +4,8 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-#ifndef _ODP_TEST_SYNCHRONIZERS_H_
-#define _ODP_TEST_SYNCHRONIZERS_H_
+#ifndef _ODP_TEST_ATOMIC_H_
+#define _ODP_TEST_ATOMIC_H_
 
 #include 
 
@@ -14,10 +14,10 @@ void atomic_test_atomic_inc_dec(void);
 void atomic_test_atomic_add_sub(void);
 void atomic_test_atomic_fetch_inc_dec(void);
 void atomic_test_atomic_fetch_add_sub(void);
-void synchronizers_test_atomic_max_min(void);
-void synchronizers_test_atomic_cas_inc_dec(void);
-void synchronizers_test_atomic_xchg(void);
-void synchronizers_test_atomic_non_relaxed(void);
+void atomic_test_atomic_max_min(void);
+void atomic_test_atomic_cas_inc_dec(void);
+void atomic_test_atomic_xchg(void);
+void atomic_test_atomic_non_relaxed(void);
 
 /* test arrays: */
 extern odp_testinfo_t atomic_suite_atomic[];
diff --git a/test/validation/barrier/barrier.h 
b/test/validation/barrier/barrier.h
index 15fa7b2..3cddfc4 100644
--- a/test/validation/barrier/barrier.h
+++ b/test/validation/barrier/barrier.h
@@ -4,8 +4,8 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-#ifndef _ODP_TEST_SYNCHRONIZERS_H_
-#define _ODP_TEST_SYNCHRONIZERS_H_
+#ifndef _ODP_TEST_BARRIER_H_
+#define _ODP_TEST_BARRIER_H_
 
 #include 
 
diff --git a/test/validation/lock/lock.h b/test/validation/lock/lock.h
index d41123f..d90cdbc 100644
--- a/test/validation/lock/lock.h
+++ b/test/validation/lock/lock.h
@@ -4,8 +4,8 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-#ifndef _ODP_TEST_SYNCHRONIZERS_H_
-#define _ODP_TEST_SYNCHRONIZERS_H_
+#ifndef _ODP_TEST_LOCK_H_
+#define _ODP_TEST_LOCK_H_
 
 #include 
 
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 1/3] api: atomic: init functions are not atomic

[Petri Savolainen]

Highlight that application must ensure that there's no
race while calling init functions. Also lock free call
will never set op.init flag, since init call will not need
to implement locking or other (lock free) synchronization.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/atomic.h| 11 +++
 platform/linux-generic/odp_atomic.c |  4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/atomic.h b/include/odp/api/atomic.h
index 8626495..a16d90b 100644
--- a/include/odp/api/atomic.h
+++ b/include/odp/api/atomic.h
@@ -67,6 +67,10 @@ extern "C" {
 /**
  * Initialize atomic uint32 variable
  *
+ * Initializes the atomic variable with 'val'. This operation is not atomic.
+ * Application must ensure that there's no race condition while initializing
+ * the variable.
+ *
  * @param atomPointer to atomic variable
  * @param val Value to initialize the variable with
  */
@@ -219,6 +223,10 @@ uint32_t odp_atomic_xchg_u32(odp_atomic_u32_t *atom, 
uint32_t new_val);
 /**
  * Initialize atomic uint64 variable
  *
+ * Initializes the atomic variable with 'val'. This operation is not atomic.
+ * Application must ensure that there's no race condition while initializing
+ * the variable.
+ *
  * @param atomPointer to atomic variable
  * @param val Value to initialize the variable with
  */
@@ -600,6 +608,9 @@ typedef union odp_atomic_op_t {
  * variables instead of uint64 to optimize performance on platforms that
  * implement a performance critical operation using locks.
  *
+ * Init operations (e.g. odp_atomic_init_64()) are not atomic. This function
+ * clears the op.init bit but will never set it to one.
+ *
  * @param atomic_op  Pointer to atomic operation structure for storing
  *   operation flags. All bits are initialized to zero during
  *   the operation. The parameter is ignored when NULL.
diff --git a/platform/linux-generic/odp_atomic.c 
b/platform/linux-generic/odp_atomic.c
index 996d09a..5b71ecf 100644
--- a/platform/linux-generic/odp_atomic.c
+++ b/platform/linux-generic/odp_atomic.c
@@ -16,8 +16,10 @@ int odp_atomic_lock_free_u64(odp_atomic_op_t *atomic_op)
return 0;
 #else
/* All operations are lock-free */
-   if (atomic_op)
+   if (atomic_op) {
atomic_op->all_bits = ~((uint32_t)0);
+   atomic_op->op.init  = 0;
+   }
 
return 2;
 #endif
-- 
2.6.3

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

Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

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

> -Original Message-
> From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Friday, January 29, 2016 1:15 PM
> To: Elo, Matias (Nokia - FI/Espoo) ; lng-
> o...@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation
> 
> On 01/28/2016 17:24, Elo, Matias (Nokia - FI/Espoo) wrote:
> >> -Original Message-
> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Maxim
> >> Uvarov
> >> Sent: Thursday, January 28, 2016 3:10 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation
> >>
> >> Matias, can you please add validation test case to that series the same
> >> thing which we use for odp-dpkd?
> >> I.e. with PCAP PMD. to test functionality.
> > You can use normal pktio validation tests (e.g. sudo ODP_PKTIO_IF0=1
> ODP_PKTIO_IF1=3 ./test/validation/pktio/pktio_main).
> > Currently, most of the tests fails as  _pktio_wait_linkup() in called in 
> > invalid
> locations, but I'm sending a separate patch soon to fix this.
> >
> > Or did you mean something else?
> >
> > -Matias
> 
> Something else. DPDK has pcap PMD to run app without hardware on any
> device. We did that for make check on odp-dpdk to make
> test pass on vethX devices. The same idea as we do for raw sockets.
> 
> file:
> https://git.linaro.org/lng/odp-dpdk.git/blob/HEAD:/platform/linux-
> dpdk/test/pktio/pktio_run
> line:
> export ODP_PLATFORM_PARAMS="-n 4 --vdev eth_pcap0,iface=$IF0 --vdev
> eth_pcap1,iface=$IF1"
> 
> But I'm not sure if it's applicable to your patches. But if you can add
> some check to validation it without hardware
> it will be very helpful to catch bugs as soon as possible.
> 

OK, I'll look into this. It's probably best to submit that in a separate patch 
as it is a new feature.

-Matias

> Thanks,
> Maxim.
> 
> 
> >> Thanks,
> >> Maxim.
> >>
> >> On 01/28/2016 10:03, Matias Elo wrote:
> >>> Implements new DPDK pktio type, which operates in the same manner as
> the
> >>> existing ODP interface types. DPDK mbuf packets are copied during
> >> receive/send
> >>> to maintain compatibility with the linux-generic pktio.
> >>>
> >>> The current unoptimized DPDK pktio implementation achieves forwarding
> rates
> >>> (odp_l2fwd), which are comparable to netmap pktio and scale better with
> >> larger
> >>> thread counts. Some initial benchmark results below
> >>> (odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).
> >>>
> >>>   Threads
> >>>   1   2   4   6   8   10  12
> >>> DPDK  6.7 12  25.337.247.647.346.8MPPS
> >>> Netmap6.1 12.625.832.438.938.638.4
> >>>
> >>>
> >>>   From 8 threads and onwards the throughput is limited by the NICs (Intel
> >> 82599).
> >>> Build and usage information can be found from DEPENDENCIES. The DPDK
> >>> initialization code is copied from the odp-dpdk branch.
> >>>
> >>> Matias Elo (11):
> >>> linux-generic: pktio: add DPDK pktio build support
> >>> linux-generic: pktio: initial DPDK pktio implementation
> >>> linux-generic: dpdk: add get/set functions for mtu, promisc mode, and
> >>>   capability
> >>> linux-generic: dpdk: add rx/tx locking
> >>> linux-generic: dpdk: add odp_pktio_link_status()
> >>> linux-generic: dpdk: add dpdk_setup_port()
> >>> linux-generic: dpdk: add functions for fetching packet input/output
> >>>   queues
> >>> linux-generic: dpdk: add odp_pktio_input_queues_config()
> >>> linux-generic: dpdk: add odp_pktio_output_queues_config()
> >>> linux-generic: dpdk: handle ixgbe_pmd minimum burst size
> >>> linux-generic: dpdk: close resources in odp_pktio_close()
> >>>
> >>>DEPENDENCIES   |  54 ++
> >>>platform/linux-generic/Makefile.am |   2 +
> >>>platform/linux-generic/include/odp_internal.h  |   5 +
> >>>platform/linux-generic/include/odp_packet_dpdk.h   |  68 ++
> >>>.../linux-generic/include/odp_packet_io_internal.h |   3 +
> >>>platform/linux-generic/m4/configure.m4 |   1 +
> >>>platform/linux-generic/m4/odp_dpdk.m4  |  43 ++
> >>>platform/linux-generic/odp_init.c  |  12 +
> >>>platform/linux-generic/pktio/dpdk.c| 826
> +
> >>>platform/linux-generic/pktio/io_ops.c  |   3 +
> >>>10 files changed, 1017 insertions(+)
> >>>create mode 100644 platform/linux-generic/include/odp_packet_dpdk.h
> >>>create mode 100644 platform/linux-generic/m4/odp_dpdk.m4
> >>>create mode 100644 platform/linux-generic/pktio/dpdk.c
> >>>
> >> ___
> >> 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.linar

[lng-odp] [PATCH v2 API-NEXT 0/4] separate ODP_CACHE_LINE_SIZE to arch files

[hongbo . zhang]

From: Hongbo Zhang 

v1-v2 change:

Add macro __OCTEON for patch 2.

v1 notes:

This is for bug https://bugs.linaro.org/show_bug.cgi?id=1881

This is on top of latest api-next branch because the latest
platform/linux-generic/arch/ directory is needed, so I use "API-NEXT" tag

There should be some check patch warnings for patch 4, because when new
symlink is added in patch, there will be warnings like the following but
they should be acceptable:

WARNING: adding a line without newline at end of file
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c

CHECK: spaces preferred around that '/' (ctx:VxV)
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c
   ^

CHECK: spaces preferred around that '/' (ctx:VxV)
#89: FILE: platform/linux-generic/arch/arm/odp_cpu_arch.c:1:
+../linux/odp_cpu_arch.c

Hongbo Zhang (4):
  linux-generic: separate x86 ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: separate PowerPC ODP_CACHE_LINE_SIZE to its arch file
  linux-generic: create ARM files and move ARM ODP_CACHE_LINE_SIZE in it

 configure.ac   |  1 +
 platform/linux-generic/Makefile.am |  2 ++
 platform/linux-generic/arch/arm/odp/cpu_arch.h | 24 +
 platform/linux-generic/arch/arm/odp_cpu_arch.c |  1 +
 .../linux-generic/arch/arm/odp_sysinfo_parse.c |  1 +
 platform/linux-generic/arch/mips64/odp/cpu_arch.h  |  2 ++
 platform/linux-generic/arch/powerpc/odp/cpu_arch.h | 25 +-
 platform/linux-generic/arch/x86/odp/cpu_arch.h |  2 ++
 platform/linux-generic/include/odp/align.h | 20 -
 .../linux-generic/include/odp_align_internal.h |  1 +
 10 files changed, 58 insertions(+), 21 deletions(-)
 create mode 100644 platform/linux-generic/arch/arm/odp/cpu_arch.h
 create mode 12 platform/linux-generic/arch/arm/odp_cpu_arch.c
 create mode 12 platform/linux-generic/arch/arm/odp_sysinfo_parse.c
 mode change 12 => 100644 platform/linux-generic/arch/powerpc/odp/cpu_arch.h

-- 
2.1.4

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

[lng-odp] [PATCH v2 API-NEXT 1/4] linux-generic: separate x86 ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for x86.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/x86/odp/cpu_arch.h  | 2 ++
 platform/linux-generic/include/odp/align.h  | 8 +---
 platform/linux-generic/include/odp_align_internal.h | 1 +
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/platform/linux-generic/arch/x86/odp/cpu_arch.h 
b/platform/linux-generic/arch/x86/odp/cpu_arch.h
index 997a954..24903ac 100644
--- a/platform/linux-generic/arch/x86/odp/cpu_arch.h
+++ b/platform/linux-generic/arch/x86/odp/cpu_arch.h
@@ -11,6 +11,8 @@
 extern "C" {
 #endif
 
+#define ODP_CACHE_LINE_SIZE 64
+
 static inline void odp_cpu_pause(void)
 {
 #ifdef __SSE2__
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index be8c9ae..4e045c6 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -31,11 +31,7 @@ extern "C" {
 
 #define ODP_FIELD_SIZEOF(type, member) sizeof(((type *)0)->member)
 
-#if defined __x86_64__ || defined __i386__
-
-#define ODP_CACHE_LINE_SIZE 64
-
-#elif defined __arm__ || defined __aarch64__
+#if defined __arm__ || defined __aarch64__
 
 #define ODP_CACHE_LINE_SIZE 64
 
@@ -47,8 +43,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#else
-#error GCC target not found
 #endif
 
 #else
diff --git a/platform/linux-generic/include/odp_align_internal.h 
b/platform/linux-generic/include/odp_align_internal.h
index 4ca5ceb..99788e3 100644
--- a/platform/linux-generic/include/odp_align_internal.h
+++ b/platform/linux-generic/include/odp_align_internal.h
@@ -18,6 +18,7 @@ extern "C" {
 #endif
 
 #include 
+#include 
 
 /** @addtogroup odp_compiler_optim
  *  @{
-- 
2.1.4

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

[lng-odp] [PATCH v2 API-NEXT 2/4] linux-generic: separate MIPS ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for MIPS.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/mips64/odp/cpu_arch.h | 2 ++
 platform/linux-generic/include/odp/align.h| 4 
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/arch/mips64/odp/cpu_arch.h 
b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
index 3bfa0dc..3e4a1ed 100644
--- a/platform/linux-generic/arch/mips64/odp/cpu_arch.h
+++ b/platform/linux-generic/arch/mips64/odp/cpu_arch.h
@@ -11,6 +11,8 @@
 extern "C" {
 #endif
 
+#define ODP_CACHE_LINE_SIZE 128
+
 static inline void odp_cpu_pause(void)
 {
__asm__ __volatile__ ("nop");
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 4e045c6..6aba925 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -35,10 +35,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#elif defined __OCTEON__
-
-#define ODP_CACHE_LINE_SIZE 128
-
 #elif defined __powerpc__
 
 #define ODP_CACHE_LINE_SIZE 64
-- 
2.1.4

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

[lng-odp] [PATCH v2 API-NEXT 3/4] linux-generic: separate PowerPC ODP_CACHE_LINE_SIZE to its arch file

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
This patch moves ODP_CACHE_LINE_SIZE for PowerPC.
The previous arch/powerpc/odp/cpu_arch.h was a symlink to the generic
arch/linux/odp/cpu_arch.h, but now this PowerPC header file has more
specific content than the generic one, so a real file is created and the
ODP_CACHE_LINE_SIZE is added to it.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/powerpc/odp/cpu_arch.h | 25 +-
 platform/linux-generic/include/odp/align.h |  4 
 2 files changed, 24 insertions(+), 5 deletions(-)
 mode change 12 => 100644 platform/linux-generic/arch/powerpc/odp/cpu_arch.h

diff --git a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h 
b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
deleted file mode 12
index 0617d7f..000
--- a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
+++ /dev/null
@@ -1 +0,0 @@
-../../linux/odp/cpu_arch.h
\ No newline at end of file
diff --git a/platform/linux-generic/arch/powerpc/odp/cpu_arch.h 
b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
new file mode 100644
index 000..e56523f
--- /dev/null
+++ b/platform/linux-generic/arch/powerpc/odp/cpu_arch.h
@@ -0,0 +1,24 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PLAT_CPU_ARCH_H_
+#define ODP_PLAT_CPU_ARCH_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define ODP_CACHE_LINE_SIZE 64
+
+static inline void odp_cpu_pause(void)
+{
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 6aba925..75c02ae 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -35,10 +35,6 @@ extern "C" {
 
 #define ODP_CACHE_LINE_SIZE 64
 
-#elif defined __powerpc__
-
-#define ODP_CACHE_LINE_SIZE 64
-
 #endif
 
 #else
-- 
2.1.4

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

[lng-odp] [PATCH v2 API-NEXT 4/4] linux-generic: create ARM files and move ARM ODP_CACHE_LINE_SIZE in it

[hongbo . zhang]

From: Hongbo Zhang 

Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
held in one header file, they should be moved to their own arch file.
And in the legacy codes there was no ARM architecture directory, so this
patch create it, the odp_cpu_arch.c and odp_sysinfo_parse.c are still
symlink to the general default ones under arch/linux/, and a real file
arm/odp/cpu_arch.h is created from the linux/odp/cpu_arch.h, and then the
ODP_CACHE_LINE_SIZE for ARM is moved to this arch specific file.

Signed-off-by: Hongbo Zhang 
---
 configure.ac   |  1 +
 platform/linux-generic/Makefile.am |  2 ++
 platform/linux-generic/arch/arm/odp/cpu_arch.h | 24 ++
 platform/linux-generic/arch/arm/odp_cpu_arch.c |  1 +
 .../linux-generic/arch/arm/odp_sysinfo_parse.c |  1 +
 platform/linux-generic/include/odp/align.h |  6 --
 6 files changed, 29 insertions(+), 6 deletions(-)
 create mode 100644 platform/linux-generic/arch/arm/odp/cpu_arch.h
 create mode 12 platform/linux-generic/arch/arm/odp_cpu_arch.c
 create mode 12 platform/linux-generic/arch/arm/odp_sysinfo_parse.c

diff --git a/configure.ac b/configure.ac
index 14a025e..23f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,6 +54,7 @@ AX_VALGRIND_CHECK
 ##
 AS_CASE([$host],
   [x86*], [ARCH=x86],
+  [arm*], [ARCH=arm],
   [mips64*], [ARCH=mips64],
   [powerpc*], [ARCH=powerpc],
   [ARCH=linux]
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index fded462..435d776 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -167,6 +167,8 @@ __LIB__libodp_la_SOURCES = \
 EXTRA_DIST = \
 arch/linux/odp_cpu_arch.c \
 arch/linux/odp_sysinfo_parse.c \
+arch/arm/odp_cpu_arch.c \
+arch/arm/odp_sysinfo_parse.c \
 arch/mips64/odp_cpu_arch.c \
 arch/mips64/odp_sysinfo_parse.c \
 arch/powerpc/odp_cpu_arch.c \
diff --git a/platform/linux-generic/arch/arm/odp/cpu_arch.h 
b/platform/linux-generic/arch/arm/odp/cpu_arch.h
new file mode 100644
index 000..e56523f
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp/cpu_arch.h
@@ -0,0 +1,24 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PLAT_CPU_ARCH_H_
+#define ODP_PLAT_CPU_ARCH_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define ODP_CACHE_LINE_SIZE 64
+
+static inline void odp_cpu_pause(void)
+{
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c 
b/platform/linux-generic/arch/arm/odp_cpu_arch.c
new file mode 12
index 000..c5fe400
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c
@@ -0,0 +1 @@
+../linux/odp_cpu_arch.c
\ No newline at end of file
diff --git a/platform/linux-generic/arch/arm/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
new file mode 12
index 000..2f368af
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
@@ -0,0 +1 @@
+../linux/odp_sysinfo_parse.c
\ No newline at end of file
diff --git a/platform/linux-generic/include/odp/align.h 
b/platform/linux-generic/include/odp/align.h
index 75c02ae..81ef20f 100644
--- a/platform/linux-generic/include/odp/align.h
+++ b/platform/linux-generic/include/odp/align.h
@@ -31,12 +31,6 @@ extern "C" {
 
 #define ODP_FIELD_SIZEOF(type, member) sizeof(((type *)0)->member)
 
-#if defined __arm__ || defined __aarch64__
-
-#define ODP_CACHE_LINE_SIZE 64
-
-#endif
-
 #else
 #error Non-gcc compatible compiler
 #endif
-- 
2.1.4

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

Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

[Maxim Uvarov]

On 29 January 2016 at 14:28, Elo, Matias (Nokia - FI/Espoo) <
matias@nokia.com> wrote:

> > -Original Message-
> > From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> > Sent: Friday, January 29, 2016 1:15 PM
> > To: Elo, Matias (Nokia - FI/Espoo) ; lng-
> > o...@lists.linaro.org
> > Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation
> >
> > On 01/28/2016 17:24, Elo, Matias (Nokia - FI/Espoo) wrote:
> > >> -Original Message-
> > >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> EXT
> > Maxim
> > >> Uvarov
> > >> Sent: Thursday, January 28, 2016 3:10 PM
> > >> To: lng-odp@lists.linaro.org
> > >> Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio
> implementation
> > >>
> > >> Matias, can you please add validation test case to that series the
> same
> > >> thing which we use for odp-dpkd?
> > >> I.e. with PCAP PMD. to test functionality.
> > > You can use normal pktio validation tests (e.g. sudo ODP_PKTIO_IF0=1
> > ODP_PKTIO_IF1=3 ./test/validation/pktio/pktio_main).
> > > Currently, most of the tests fails as  _pktio_wait_linkup() in called
> in invalid
> > locations, but I'm sending a separate patch soon to fix this.
> > >
> > > Or did you mean something else?
> > >
> > > -Matias
> >
> > Something else. DPDK has pcap PMD to run app without hardware on any
> > device. We did that for make check on odp-dpdk to make
> > test pass on vethX devices. The same idea as we do for raw sockets.
> >
> > file:
> > https://git.linaro.org/lng/odp-dpdk.git/blob/HEAD:/platform/linux-
> > dpdk/test/pktio/pktio_run
> > line:
> > export ODP_PLATFORM_PARAMS="-n 4 --vdev eth_pcap0,iface=$IF0 --vdev
> > eth_pcap1,iface=$IF1"
> >
> > But I'm not sure if it's applicable to your patches. But if you can add
> > some check to validation it without hardware
> > it will be very helpful to catch bugs as soon as possible.
> >
>
> OK, I'll look into this. It's probably best to submit that in a separate
> patch as it is a new feature.
>
> -Matias
>


Right, we can stage all that in api-next, then merge to 1.8 when everything
will be ready.

Maxim.



>
> > Thanks,
> > Maxim.
> >
> >
> > >> Thanks,
> > >> Maxim.
> > >>
> > >> On 01/28/2016 10:03, Matias Elo wrote:
> > >>> Implements new DPDK pktio type, which operates in the same manner as
> > the
> > >>> existing ODP interface types. DPDK mbuf packets are copied during
> > >> receive/send
> > >>> to maintain compatibility with the linux-generic pktio.
> > >>>
> > >>> The current unoptimized DPDK pktio implementation achieves forwarding
> > rates
> > >>> (odp_l2fwd), which are comparable to netmap pktio and scale better
> with
> > >> larger
> > >>> thread counts. Some initial benchmark results below
> > >>> (odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).
> > >>>
> > >>>   Threads
> > >>>   1   2   4   6   8   10  12
> > >>> DPDK  6.7 12  25.337.247.647.346.8
> MPPS
> > >>> Netmap6.1 12.625.832.438.938.638.4
> > >>>
> > >>>
> > >>>   From 8 threads and onwards the throughput is limited by the NICs
> (Intel
> > >> 82599).
> > >>> Build and usage information can be found from DEPENDENCIES. The DPDK
> > >>> initialization code is copied from the odp-dpdk branch.
> > >>>
> > >>> Matias Elo (11):
> > >>> linux-generic: pktio: add DPDK pktio build support
> > >>> linux-generic: pktio: initial DPDK pktio implementation
> > >>> linux-generic: dpdk: add get/set functions for mtu, promisc
> mode, and
> > >>>   capability
> > >>> linux-generic: dpdk: add rx/tx locking
> > >>> linux-generic: dpdk: add odp_pktio_link_status()
> > >>> linux-generic: dpdk: add dpdk_setup_port()
> > >>> linux-generic: dpdk: add functions for fetching packet
> input/output
> > >>>   queues
> > >>> linux-generic: dpdk: add odp_pktio_input_queues_config()
> > >>> linux-generic: dpdk: add odp_pktio_output_queues_config()
> > >>> linux-generic: dpdk: handle ixgbe_pmd minimum burst size
> > >>> linux-generic: dpdk: close resources in odp_pktio_close()
> > >>>
> > >>>DEPENDENCIES   |  54 ++
> > >>>platform/linux-generic/Makefile.am |   2 +
> > >>>platform/linux-generic/include/odp_internal.h  |   5 +
> > >>>platform/linux-generic/include/odp_packet_dpdk.h   |  68 ++
> > >>>.../linux-generic/include/odp_packet_io_internal.h |   3 +
> > >>>platform/linux-generic/m4/configure.m4 |   1 +
> > >>>platform/linux-generic/m4/odp_dpdk.m4  |  43 ++
> > >>>platform/linux-generic/odp_init.c  |  12 +
> > >>>platform/linux-generic/pktio/dpdk.c| 826
> > +
> > >>>platform/linux-generic/pktio/io_ops.c  |   3 +
> > >>>10 files changed, 1017 insertions(+)
> > >>>create mode 100644
> platform/linux-generic/include/odp_packet_dpdk

[lng-odp] [PATCH API-NEXT 0/4] linux-generic sysinfo codes clean-ups

[hongbo . zhang]

From: Hongbo Zhang 

This patch set does some architecture clean-ups for linux-generic
sysinfo codes.

This patch set is based on my previous patch set
"separate ODP_CACHE_LINE_SIZE to arch files", so "API-NEXT" is uesed
although no API is touched.

Hongbo Zhang (4):
  linux-generic: move CPU info dummy data to generic default file
  linux-generic: systemcpu(): use input parameter instead of global data
  linux-generic: use one uniform call systemcpu()
  linux-generic: sysinfo clean up for ARM

 .../linux-generic/arch/arm/odp_sysinfo_parse.c | 29 -
 .../linux-generic/arch/linux/odp_sysinfo_parse.c   | 12 +-
 platform/linux-generic/odp_system_info.c   | 47 +-
 3 files changed, 47 insertions(+), 41 deletions(-)
 mode change 12 => 100644 
platform/linux-generic/arch/arm/odp_sysinfo_parse.c

-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 1/4] linux-generic: move CPU info dummy data to generic default file

[hongbo . zhang]

From: Hongbo Zhang 

The dummy data of cpu_hz_max and model_str are used when platform is
unknown or data cannot be acquired, but these variables should be set
in function odp_cpuinfo_parser() instead of the systemcpu() which should
cover only the cpu_count, huge_page_size and cache_line_size.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/arch/linux/odp_sysinfo_parse.c | 13 +++--
 platform/linux-generic/odp_system_info.c  |  9 +
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/platform/linux-generic/arch/linux/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
index 8ff6f48..4a22a61 100644
--- a/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
+++ b/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
@@ -5,11 +5,20 @@
  */
 
 #include 
+#include 
 #include 
 
-int odp_cpuinfo_parser(FILE *file ODP_UNUSED,
-  odp_system_info_t *sysinfo ODP_UNUSED)
+int odp_cpuinfo_parser(FILE *file ODP_UNUSED, odp_system_info_t *sysinfo)
 {
+   int i;
+
+   ODP_DBG("Warning: use dummy values for freq and model string\n");
+   ODP_DBG("Refer to https://bugs.linaro.org/show_bug.cgi?id=1870\n";);
+   for (i = 0; i < MAX_CPU_NUMBER; i++) {
+   sysinfo->cpu_hz_max[i] = 14;
+   strcpy(sysinfo->model_str[i], "UNKNOWN");
+   }
+
return 0;
 }
 
diff --git a/platform/linux-generic/odp_system_info.c 
b/platform/linux-generic/odp_system_info.c
index 42aef8a..bedbbc8 100644
--- a/platform/linux-generic/odp_system_info.c
+++ b/platform/linux-generic/odp_system_info.c
@@ -151,7 +151,7 @@ static int systemcpu(odp_system_info_t *sysinfo)
 
 static int systemcpu(odp_system_info_t *sysinfo)
 {
-   int ret, i;
+   int ret;
 
ret = sysconf_cpu_count();
if (ret == 0) {
@@ -166,13 +166,6 @@ static int systemcpu(odp_system_info_t *sysinfo)
/* Dummy values */
sysinfo->cache_line_size = 64;
 
-   ODP_DBG("Warning: use dummy values for freq and model string\n");
-   ODP_DBG("Refer to https://bugs.linaro.org/show_bug.cgi?id=1870\n";);
-   for (i = 0; i < MAX_CPU_NUMBER; i++) {
-   sysinfo->cpu_hz_max[i] = 14;
-   strcpy(sysinfo->model_str[i], "UNKNOWN");
-   }
-
return 0;
 }
 
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 2/4] linux-generic: systemcpu(): use input parameter instead of global data

[hongbo . zhang]

From: Hongbo Zhang 

In the systemcpu() function, odp_global_data.system_info.huge_page_size
should be sysinfo->huge_page_size instead, because when systemcpu() is
called, the &odp_global_data.system_info is passed as parameter, we should
operate the parameter instead of the global data directly, what's more,
in function systemcpu(), sysinfo->cpu_count and sysinfo->cache_line_size
are used, we should follow same pattern for sysinfo->huge_page_size.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/odp_system_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/platform/linux-generic/odp_system_info.c 
b/platform/linux-generic/odp_system_info.c
index bedbbc8..2d202a0 100644
--- a/platform/linux-generic/odp_system_info.c
+++ b/platform/linux-generic/odp_system_info.c
@@ -137,7 +137,7 @@ static int systemcpu(odp_system_info_t *sysinfo)
return -1;
}
 
-   odp_global_data.system_info.huge_page_size = huge_page_size();
+   sysinfo->huge_page_size = huge_page_size();
 
return 0;
 }
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 3/4] linux-generic: use one uniform call systemcpu()

[hongbo . zhang]

From: Hongbo Zhang 

Currently there are two systemcpu() functions, one is for some specific
platforms and the other is for default dummy, but most of the contents
are same except for sysinfo->cache_line_size: one is true data from
calling systemcpu_cache_line_size() and another is dummy data.
In such a situation we can create another systemcpu_cache_line_size() to
return dummy data for platforms which are lack of it, then only one
function systemcpu() is enough.

Signed-off-by: Hongbo Zhang 
---
 platform/linux-generic/odp_system_info.c | 40 +++-
 1 file changed, 9 insertions(+), 31 deletions(-)

diff --git a/platform/linux-generic/odp_system_info.c 
b/platform/linux-generic/odp_system_info.c
index 2d202a0..6f9fb6e 100644
--- a/platform/linux-generic/odp_system_info.c
+++ b/platform/linux-generic/odp_system_info.c
@@ -73,6 +73,15 @@ static int systemcpu_cache_line_size(void)
 
return size;
 }
+
+#else
+/*
+ * Use dummy data if not available from /sys/devices/system/cpu/
+ */
+static int systemcpu_cache_line_size(void)
+{
+   return 64;
+}
 #endif
 
 
@@ -105,9 +114,6 @@ static int huge_page_size(void)
 }
 
 
-#if defined __x86_64__ || defined __i386__ || defined __OCTEON__ || \
-defined __powerpc__
-
 /*
  * Analysis of /sys/devices/system/cpu/ files
  */
@@ -142,34 +148,6 @@ static int systemcpu(odp_system_info_t *sysinfo)
return 0;
 }
 
-#else
-
-/*
- * Use sysconf and dummy values in generic case
- */
-
-
-static int systemcpu(odp_system_info_t *sysinfo)
-{
-   int ret;
-
-   ret = sysconf_cpu_count();
-   if (ret == 0) {
-   ODP_ERR("sysconf_cpu_count failed.\n");
-   return -1;
-   }
-
-   sysinfo->cpu_count = ret;
-
-   sysinfo->huge_page_size = huge_page_size();
-
-   /* Dummy values */
-   sysinfo->cache_line_size = 64;
-
-   return 0;
-}
-
-#endif
 
 /*
  * System info initialisation
-- 
2.1.4

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

[lng-odp] [PATCH API-NEXT 4/4] linux-generic: sysinfo clean up for ARM

[hongbo . zhang]

From: Hongbo Zhang 

The arch/arm/odp_sysinfo_parse.c is currently a symlink to
arch/linux/odp_sysinfo_parse.c, but in fact there should be defferences
between them.

A separated real arch/arm/odp_sysinfo_parse.c is created for ARM, and
the model_str is set to a general "ARM", which is much better then the
general defaul "UNKNOWN" although not so accurate in detailed ARM CPU
model string.

ODP_DBG("TODO: true values should be implemented when possible\n") is
added for ARM too, this means when possible true values can be implemented
for ARM, and only ARM odp_cpuinfo_parser() is updated, while the general
defaul odp_cpuinfo_parser() should be leave there unchanged. In other
words the current implementation for ARM is a temporary work around, but
for the generic default dummy data has to be accepted.

ODP_DBG("Refer to https://bugs.linaro.org/show_bug.cgi?id=1870\n";) is
deleted, because this bug describes another thing, eg in previous code,
only cpu_hz_max[0] and model_str[0] were set, the others such as
cpu_hz_max[1...n-1] and model_str[1...n-1] were missing, it isn't related
with the value itself is dummy or not, and this bug was already fixed.

Signed-off-by: Hongbo Zhang 
---
 .../linux-generic/arch/arm/odp_sysinfo_parse.c | 29 +-
 .../linux-generic/arch/linux/odp_sysinfo_parse.c   |  1 -
 2 files changed, 28 insertions(+), 2 deletions(-)
 mode change 12 => 100644 
platform/linux-generic/arch/arm/odp_sysinfo_parse.c

diff --git a/platform/linux-generic/arch/arm/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
deleted file mode 12
index 2f368af..000
--- a/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
+++ /dev/null
@@ -1 +0,0 @@
-../linux/odp_sysinfo_parse.c
\ No newline at end of file
diff --git a/platform/linux-generic/arch/arm/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
new file mode 100644
index 000..b141168
--- /dev/null
+++ b/platform/linux-generic/arch/arm/odp_sysinfo_parse.c
@@ -0,0 +1,28 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+
+int odp_cpuinfo_parser(FILE *file ODP_UNUSED, odp_system_info_t *sysinfo)
+{
+   int i;
+
+   ODP_DBG("Warning: use dummy values for freq and model string\n");
+   ODP_DBG("TODO: true values should be implemented when possible\n");
+   for (i = 0; i < MAX_CPU_NUMBER; i++) {
+   sysinfo->cpu_hz_max[i] = 14;
+   strcpy(sysinfo->model_str[i], "ARM");
+   }
+
+   return 0;
+}
+
+uint64_t odp_cpu_hz_current(int id ODP_UNUSED)
+{
+   return 0;
+}
diff --git a/platform/linux-generic/arch/linux/odp_sysinfo_parse.c 
b/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
index 4a22a61..4dcd6d1 100644
--- a/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
+++ b/platform/linux-generic/arch/linux/odp_sysinfo_parse.c
@@ -13,7 +13,6 @@ int odp_cpuinfo_parser(FILE *file ODP_UNUSED, 
odp_system_info_t *sysinfo)
int i;
 
ODP_DBG("Warning: use dummy values for freq and model string\n");
-   ODP_DBG("Refer to https://bugs.linaro.org/show_bug.cgi?id=1870\n";);
for (i = 0; i < MAX_CPU_NUMBER; i++) {
sysinfo->cpu_hz_max[i] = 14;
strcpy(sysinfo->model_str[i], "UNKNOWN");
-- 
2.1.4

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

Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

[Zoltan Kiss]

On 29/01/16 08:19, Elo, Matias (Nokia - FI/Espoo) wrote:

*From:*EXT Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Thursday, January 28, 2016 4:39 PM
*To:* Elo, Matias (Nokia - FI/Espoo) 
*Cc:* EXT Zoltan Kiss ; lng-odp@lists.linaro.org
*Subject:* Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation

On 28 January 2016 at 15:14, Elo, Matias (Nokia - FI/Espoo)
mailto:matias@nokia.com>> wrote:

 > -Original Message-
 > From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org
]
 > Sent: Thursday, January 28, 2016 3:21 PM
 > To: Elo, Matias (Nokia - FI/Espoo) mailto:matias@nokia.com>>; lng-
 > o...@lists.linaro.org 
 > Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio
implementation
 >
 > Hi,
 >
 > On 28/01/16 07:03, Matias Elo wrote:
 > > The current unoptimized DPDK pktio implementation achieves
forwarding rates
 > > (odp_l2fwd), which are comparable to netmap pktio and scale
better with
 > larger
 > > thread counts. Some initial benchmark results below
 > > (odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).
 > >
 > > Threads
 > > 1   2   4   6   8   10  12
 > > DPDK6.7 12  25.337.247.647.3
46.8MPPS
 > > Netmap  6.1 12.625.832.438.938.638.4
 >
 > My performance results for ODP-DPDK are unidirectional between two
 > ports, where one thread does the actual work (the other is
idling), in
 > that case it can achieve 14 Mpps. Is your number 6.7 Mpps comparable
 > with this?

These numbers are combined throughputs from all 4 ports. No
"maintenance"
thread is needed. With two ports and unidirectional traffic a single
thread is able
to handle about 7 MPPS.

 > Your main source of optimization seems to be to do zerocopy on RX
side,
 > but it needs change in linux-generic buffer management:
 > - allow allocating zero length buffers, so you can append the buffers
 > from the mbuf there
 > - release the mbufs during odp_packet_free(), that needs some DPDK
 > specific code, a destructor which calls rte_pktmbuf_free() on the
stored
 > pointers.
 >
 > But even with that there will be a cost of wrapping the mbuf's into
 > linux-generic buffers, and you can't avoid copy on TX side.

Yep, this is in my to-do list.

Perhaps ODP linux-generic should use mbufs? I think that would allow for
the greatest amount of friction-less coexistence.

At first I’m going to try to use mbufs along ODP packets as Zoltan
described. Moving to using only mbufs is a whole different conversation
and may introduce a new set of problems. E.g. mbuf not supporting some
features we require. Still, it’s an option we could think about.


Using mbuf's is the key difference between this approach and ODP-DPDK. 
The latter reuses most of the linux-generic code (including pktio now as 
well), but it has its own buffer, packet(_flags) and pool implementation 
which builds on DPDK mbuf's and mempool's. The linux-generic 
implementation files are only kept there to make seamless git repo sync 
possible.
If we plan to ditch the linux-generic implementations and use DPDK I'm 
OK with that, but it would be good to know where should I put my efforts.





P.S. Please reply to messages using plaintext as HTML makes replying
inline a pain.

-Matias


-Matias


 >
 > Regards,
 >
 > Zoltan
___
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 00/11] DPDK pktio implementation

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Zoltan Kiss
> Sent: Friday, January 29, 2016 2:13 PM
> To: Elo, Matias (Nokia - FI/Espoo); EXT Ola Liljedahl
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio implementation
> 
> 
> 
> On 29/01/16 08:19, Elo, Matias (Nokia - FI/Espoo) wrote:
> > *From:*EXT Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> > *Sent:* Thursday, January 28, 2016 4:39 PM
> > *To:* Elo, Matias (Nokia - FI/Espoo) 
> > *Cc:* EXT Zoltan Kiss ; lng-odp@lists.linaro.org
> > *Subject:* Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio
> implementation
> >
> > On 28 January 2016 at 15:14, Elo, Matias (Nokia - FI/Espoo)
> > mailto:matias@nokia.com>> wrote:
> >
> >  > -Original Message-
> >  > From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org
> > ]
> >  > Sent: Thursday, January 28, 2016 3:21 PM
> >  > To: Elo, Matias (Nokia - FI/Espoo)  > >; lng-
> >  > o...@lists.linaro.org 
> >  > Subject: Re: [lng-odp] [API-NEXT PATCH 00/11] DPDK pktio
> > implementation
> >  >
> >  > Hi,
> >  >
> >  > On 28/01/16 07:03, Matias Elo wrote:
> >  > > The current unoptimized DPDK pktio implementation achieves
> > forwarding rates
> >  > > (odp_l2fwd), which are comparable to netmap pktio and scale
> > better with
> >  > larger
> >  > > thread counts. Some initial benchmark results below
> >  > > (odp_l2fwd  4 x 10 Gbps - 64B, Intel Xeon E5-2697v3).
> >  > >
> >  > > Threads
> >  > > 1   2   4   6   8   10  12
> >  > > DPDK6.7 12  25.337.247.647.3
> > 46.8MPPS
> >  > > Netmap  6.1 12.625.832.438.938.6
> 38.4
> >  >
> >  > My performance results for ODP-DPDK are unidirectional between
> two
> >  > ports, where one thread does the actual work (the other is
> > idling), in
> >  > that case it can achieve 14 Mpps. Is your number 6.7 Mpps
> comparable
> >  > with this?
> >
> > These numbers are combined throughputs from all 4 ports. No
> > "maintenance"
> > thread is needed. With two ports and unidirectional traffic a single
> > thread is able
> > to handle about 7 MPPS.
> >
> >  > Your main source of optimization seems to be to do zerocopy on RX
> > side,
> >  > but it needs change in linux-generic buffer management:
> >  > - allow allocating zero length buffers, so you can append the
> buffers
> >  > from the mbuf there
> >  > - release the mbufs during odp_packet_free(), that needs some
> DPDK
> >  > specific code, a destructor which calls rte_pktmbuf_free() on the
> > stored
> >  > pointers.
> >  >
> >  > But even with that there will be a cost of wrapping the mbuf's
> into
> >  > linux-generic buffers, and you can't avoid copy on TX side.
> >
> > Yep, this is in my to-do list.
> >
> > Perhaps ODP linux-generic should use mbufs? I think that would allow for
> > the greatest amount of friction-less coexistence.
> >
> > At first I’m going to try to use mbufs along ODP packets as Zoltan
> > described. Moving to using only mbufs is a whole different conversation
> > and may introduce a new set of problems. E.g. mbuf not supporting some
> > features we require. Still, it’s an option we could think about.
> 
> Using mbuf's is the key difference between this approach and ODP-DPDK.
> The latter reuses most of the linux-generic code (including pktio now as
> well), but it has its own buffer, packet(_flags) and pool implementation
> which builds on DPDK mbuf's and mempool's. The linux-generic
> implementation files are only kept there to make seamless git repo sync
> possible.
> If we plan to ditch the linux-generic implementations and use DPDK I'm
> OK with that, but it would be good to know where should I put my efforts.
> 

There's lots of DPDK libraries to be utilized (e.g. rte_sched for TM, etc) by 
the odp-dpdk implementation. Odp-dpdk should utilize over time more dpdk libs 
and less linux-generic code.

Linux-generic (I'd prefer odp-linux) will use DPDK only as another pktio. This 
is to ensure that we maintain low dependency to any external library (which is 
not part linux).

Packet buffer format of odp-linux (when configured with --with-dpdk-path) could 
include storage space for mbuf and set pointers accordingly. So, that DPDK code 
would see mbufs and ODP code (other than the pktio) would see ODP packets. And 
both would access the data with zero copy.

-Petri

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

Re: [lng-odp] odp timer thoughts

[Mike Holmes]

On 29 January 2016 at 05:16, Ivan Khoronzhuk 
wrote:

>
>
> On 29.01.16 00:54, Bill Fischofer wrote:
>
>> This is how you implement timers in HW as well.
>>
> A separate HW block operates a scan loop that constantly searches for
> timers to expire and creates events for those who do.
> The rest of the system operates undisturbed.  For a SW analog in manycore
> systems you'd have service thread(s) running on dedicated core(s) doing the
> same.
>
> Actually it can be emulated for linux-generic, but instead of HW block the
> pool of timers should be handled on one of control CPUS.
> Each timer pool, no matter, created on main thread or worker thread has to
> be created with CPU affinity according to control cpumask.
> Question is only which one and who decides which one, on linux-generic,
> let it be always CPU0, but with warn that CPU0 can be
> shared with a worker thread (or maybe exclude it? it was proposed several
> times already, but rejected).
>

The choice of which cores etc to run the tests on should maybe come from
the platform side and for the validation tests etc be a possibly generated
file mapping the cores to Linux, workers and control so that it is easy to
change the mapping used.

For linux generic we could even map it out at configure time to generate
that definition file based on the number of cores found as some sort of
default.


>
>
>> On Thu, Jan 28, 2016 at 12:41 PM, Stuart Haslam > > wrote:
>>
>> On Thu, Jan 28, 2016 at 09:31:52PM +0300, Maxim Uvarov wrote:
>>  > I have some thoughts and questions about timer implementation in
>>  > linux-generic.
>>  >
>>  > Current implementation:
>>  >
>>  > sigev.sigev_notify  = SIGEV_THREAD;
>>  > sigev.sigev_notify_function = timer_notify;
>>  > sigev.sigev_value.sival_ptr = tp;
>>  >timer_create(CLOCK_MONOTONIC, &sigev, &tp->timerid);
>>  > then:
>>  >  timer_settime(tp->timerid, 0, &ispec, NULL);
>>  >
>>  > where:
>>  > timer_notify(sigval_t sigval)
>>  > {
>>  > uint64_t prev_tick = odp_atomic_fetch_inc_u64(&tp->cur_tick);
>>  > /* Attempt to acquire the lock, check if the old value was
>> clear */
>>  > if (odp_spinlock_trylock(&tp->itimer_running)) {
>>  > /* Scan timer array, looking for timers to expire */
>>  > (void)odp_timer_pool_expire(tp, prev_tick);
>>  > odp_spinlock_unlock(&tp->itimer_running);
>>  > }
>>  >
>>  > }
>>  >
>>  > Now what I see from our test case.
>>  > 1. We have bunch of workers.
>>  > 2. Each worker starts timer.
>>  > 3. Because it's SIGEV_THREAD on timer action new thread for
>> notifier
>>  > function started.
>>  >
>>  > Usually it works well. Until there is load on cpu. (something like
>>  > busy loop app.) There a lot of threads
>>  > just created by kernel. I.e. execution clone() call.
>>  >
>>  > Based that I have question I have questions which is not quite
>> clear for me:
>>  > 1. Why SIGEV_THREAD was used?
>>  >
>>  > 2. When each worker will run bunch of threads (timer handler), they
>>  > will fight for cpu time for context
>>  > switches between all that threads. Is there significant slowdown
>>  > compare to one thread or signal usage?
>>  >
>>  > 3. What is priority of timer handler against to worker? Cpu
>> affinity
>>  > of handler thread? Should it
>>  > be SHED_FIFO? I.e. do we need to specify that thread attrs?
>>  >
>>  > I think that creation thread each time only for increasing atomic
>>  > counter is very expensive. So we can
>>  > rewrite that code to use SIGEV_SIGNAL or start thread manually and
>>  > SIGEV_THREAD_ID  + semaphore.
>>  >
>>  > If we will think about core isolation, than probably we have to
>> work
>>  > with signals. Don't know if core isolation
>>  > supports several threads on one core. Or even move all timer
>> actions
>>  > to separate core to not disturb worker
>>  > cores.
>>  >
>>  > Thank you,
>>  > Maxim.
>>
>> +1
>>
>> This is basically what was suggested here:
>>
>> https://bugs.linaro.org/show_bug.cgi?id=1615#c18
>>
>> --
>> Stuart.
>> ___
>> 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
>>
>>
> --
> Regards,
> Ivan Khoronzhuk
>
> ___
> 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

[lng-odp] [API-NEXT PATCH 1/2] api: stdlib: added odp_memcmp

[Petri Savolainen]

Memory compare is a commonly used C library function on
data plane applications. This enables using HW offload
(e.g. vector unit) for compare operations.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/std_clib.h| 18 ++
 platform/linux-generic/include/odp/std_clib.h |  5 +
 2 files changed, 23 insertions(+)

diff --git a/include/odp/api/std_clib.h b/include/odp/api/std_clib.h
index 2119ec4..791b72f 100644
--- a/include/odp/api/std_clib.h
+++ b/include/odp/api/std_clib.h
@@ -54,6 +54,24 @@ void *odp_memcpy(void *dst, const void *src, size_t num);
 void *odp_memset(void *ptr, int value, size_t num);
 
 /**
+ * Memcmp
+ *
+ * ODP version of C library memcmp function. It compares first 'num' bytes of
+ * memory blocks pointed by 'ptr1' and 'ptr2'.
+ *
+ * @param ptr1   Pointer to a memory block
+ * @param ptr2   Pointer to a memory block
+ * @param numNumber of bytes to compare
+ *
+ * @retval 0  when the contents of memory blocks match
+ * @retval <0 when the contents of memory blocks do not match, and
+ *block 'ptr1' is less than block 'ptr2'
+ * @retval >0 when the contents of memory blocks do not match, and
+ *block 'ptr1' is greater than block 'ptr2'
+ */
+int odp_memcmp(const void *ptr1, const void *ptr2, size_t num);
+
+/**
  * @}
  */
 
diff --git a/platform/linux-generic/include/odp/std_clib.h 
b/platform/linux-generic/include/odp/std_clib.h
index c939c48..11c59be 100644
--- a/platform/linux-generic/include/odp/std_clib.h
+++ b/platform/linux-generic/include/odp/std_clib.h
@@ -23,6 +23,11 @@ static inline void *odp_memset(void *ptr, int value, size_t 
num)
return memset(ptr, value, num);
 }
 
+static inline int odp_memcmp(const void *ptr1, const void *ptr2, size_t num)
+{
+   return memcmp(ptr1, ptr2, num);
+}
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 2/2] validation: stdlib: add odp_memcmp test

[Petri Savolainen]

Added test for memory compare.

Signed-off-by: Petri Savolainen 
---
 test/validation/std_clib/std_clib.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/test/validation/std_clib/std_clib.c 
b/test/validation/std_clib/std_clib.c
index e53ad39..e69bc39 100644
--- a/test/validation/std_clib/std_clib.c
+++ b/test/validation/std_clib/std_clib.c
@@ -44,9 +44,47 @@ static void std_clib_test_memset(void)
CU_ASSERT(ret == 0);
 }
 
+static void std_clib_test_memcmp(void)
+{
+   uint8_t data[]   = {1,  2,  3,  4,  5,  6,  7,  8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+   uint8_t equal[]  = {1,  2,  3,  4,  5,  6,  7,  8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+   uint8_t greater_11[] = {1,  2,  3,  4,  5,  6,  7,  8,
+   9, 10, 99, 12, 13, 14, 15, 16};
+   uint8_t less_6[] = {1,  2,  3,  4,  5,  2,  7,  8,
+   9, 10, 11, 12, 13, 14, 15, 16};
+   size_t i;
+
+   CU_ASSERT(odp_memcmp(data, equal, 0) == 0);
+   CU_ASSERT(odp_memcmp(data, equal, sizeof(data)) == 0);
+   CU_ASSERT(odp_memcmp(data, equal, sizeof(data) - 3) == 0);
+
+   CU_ASSERT(odp_memcmp(greater_11, data, sizeof(data)) > 0);
+   CU_ASSERT(odp_memcmp(greater_11, data, 11) > 0);
+   CU_ASSERT(odp_memcmp(greater_11, data, 10) == 0);
+
+   CU_ASSERT(odp_memcmp(less_6, data, sizeof(data)) < 0);
+   CU_ASSERT(odp_memcmp(less_6, data, 6) < 0);
+   CU_ASSERT(odp_memcmp(less_6, data, 5) == 0);
+
+   for (i = 0; i < sizeof(data); i++) {
+   uint8_t tmp;
+
+   CU_ASSERT(odp_memcmp(data, equal, i + 1) == 0);
+   tmp  = equal[i];
+   equal[i] = 88;
+   CU_ASSERT(odp_memcmp(data, equal, i + 1) < 0);
+   equal[i] = 0;
+   CU_ASSERT(odp_memcmp(data, equal, i + 1) > 0);
+   equal[i] = tmp;
+   }
+}
+
 odp_testinfo_t std_clib_suite[] = {
ODP_TEST_INFO(std_clib_test_memcpy),
ODP_TEST_INFO(std_clib_test_memset),
+   ODP_TEST_INFO(std_clib_test_memcmp),
ODP_TEST_INFO_NULL,
 };
 
-- 
2.6.3

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

Re: [lng-odp] [API-NEXT PATCH 0/6] Rename queue types

[Bill Fischofer]

Thanks for the further explanation.  Yes, UNSCHED implies a dichotomy that
may be limiting.  I guess the real distinction is that certain queues are
managed by ODP while others are managed by the application itself
(alternately, queues are either system managed, with various ODP-defined
attributes, or user managed).  I don't suppose either
ODP_QUEUE_TYPE_APPLICATION or ODP_QUEUE_TYPE_USER appeals?

On Fri, Jan 29, 2016 at 2:12 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> I have considered unsched also, but really don’t like that since it would
> define the queue type by what it is not (instead of what it is). It would
> be also problematic term, if we’d need to define a third type in the future
> (e.g. sorted queue, etc).
>
>
>
> This queue type provides the basic (or plain) set of queue features. Also
> I’d not call it “normal queue”, since sched queue may be the norm for one
> application and this for another. Term “basic” could have the same problem:
> e.g. atomic queue maybe the basic queue type for an application. In RFC, I
> used term “direct queue”, but I’d want to reserve the term “direct” for
> e.g. “direct pktio” mode and other direct accesses APIs (to other ODP
> blocks). When these plain (or scheduled) queues are connected to pktio,
> it’s an in-direction compared to the direct access.
>
>
>
> After these patches the (commonly spoken) terminology would be
>
> · Plain queues
>
> · Parallel queues
>
> · Atomic queues
>
> · Ordered queues
>
>
>
> … and potentially in the future
>
> · Sorted queues, etc (queues with advanced features) …
>
>
>
>
>
> /**
>
> * Queue create
>
> *
>
> * Create a queue according to the queue parameters. Queue type is
> specified by
>
> * queue parameter 'type'. Use odp_queue_param_init() to initialize
> parameters
>
> * into their default values. *Default values are also used when 'param'
> pointer*
>
> ** is NULL. The default queue type is ODP_QUEUE_TYPE_PLAIN.*
>
> *
>
> * @param nameQueue name
>
> * @param param   Queue parameters. Uses defaults if NULL.
>
> *
>
> * @return Queue handle
>
> * @retval ODP_QUEUE_INVALID on failure
>
> */
>
> odp_queue_t odp_queue_create(const char *name, const odp_queue_param_t
> *param);
>
>
>
>
>
> The default type is already documented. If user sets param to NULL or
> passes an initialized param (without any changes), the result is the same -
> the default settings. The type would be PLAIN in both cases.
>
>
>
> -Petri
>
>
>
>
>
>
>
> *From:* EXT Bill Fischofer [mailto:bill.fischo...@linaro.org]
> *Sent:* Friday, January 29, 2016 5:21 AM
> *To:* Savolainen, Petri (Nokia - FI/Espoo)
> *Cc:* LNG ODP Mailman List
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 0/6] Rename queue types
>
>
>
> This looks good, however PLAIN doesn't seem very intuitive as it's not
> descriptive of how the queue behaves.  How about simply QUEUE_TYPE_UNSCHED
> to contrast with QUEUE_TYPE_SCHED?  The real distinction here is whether
> the ODP scheduler or the application is managing the queue, i.e., whether
> the queue is scheduled or unscheduled.  Encoding that in the name would
> make that distinction very clear.  With the move of the type parameter into
> the odp_queue_param_t struct, omitting this struct on odp_queue_create()
> would default to creating an unscheduled queue.
>
>
>
> Other than that, for this series:
>
>
>
> Reviewed-and-tested-by: Bill Fischofer 
>
>
>
> On Thu, Jan 28, 2016 at 7:24 AM, Petri Savolainen <
> petri.savolai...@nokia.com> wrote:
>
> This patch set renames queue types and pktio modes with commonly used and
> descriptive terms. Type of odp_queue_type_t is defined as enum and included
> into queue parameters. Queue type and defines parameter usage (which
> params are
> considered e.g. in queue creation), and is inline with other create APIs
> (pool,
> timer, tm, ...).
>
> These modifications are preparation for removal of PKTIN and PKOUT queue
> types,
> and the single queue pktio API (odp_pktio_inq_setdef(), etc).
>
>
>
> Petri Savolainen (6):
>   api: sched: rename SCHED_SYNC_NONE to _PARALLEL
>   api: queue: rename QUEUE_TYPE_POLL to _PLAIN
>   api: pktio: rename pktio modes
>   api: queue: define queue type as enum
>   api: queue: moved queue type into queue parameters
>   linux-generic: use term plain queue instead of poll
>
>  example/classifier/odp_classifier.c| 16 ++--
>  example/generator/odp_generator.c  |  9 ++-
>  example/ipsec/odp_ipsec.c  | 43 ++-
>  example/packet/odp_pktio.c | 14 ++--
>  example/time/time_global_test.c|  8 +-
>  example/timer/odp_timer_test.c |  5 +-
>  include/odp/api/packet_io.h| 26 +++
>  include/odp/api/queue.h| 68 +---
>  include/odp/api/schedule_types.h   | 12 +--
>  .../linux-generic/include/odp/plat/queue_

Re: [lng-odp] [RFC API-NEXT PATCH 2/2] api: cpu: add routines for obtaining socket ids

[Zoltan Kiss]

On 29/01/16 02:44, Bill Fischofer wrote:

Add odp_cpu_socket_id() and odp_cpu_socket_id_cpu() routines

Signed-off-by: Bill Fischofer 
---
  include/odp/api/cpu.h | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/include/odp/api/cpu.h b/include/odp/api/cpu.h
index 4cbaf58..fe74825 100644
--- a/include/odp/api/cpu.h
+++ b/include/odp/api/cpu.h
@@ -36,6 +36,29 @@ extern "C" {
  int odp_cpu_id(void);

  /**
+ * CPU socket id
+ *
+ * Returns the socket id associated with the calling CPU on NUMA systems.
+ * Socket ID numbering is system specific.
+ *
+ * @return Socket ID of the calling CPU
+ * @retval ODP_SOCKET_ID_ANY  If the caller is not running on a NUMA system.
+ */
+uint32_t odp_cpu_socket_id(void);
+
+/**
+ * CPU socket id of designated CPU
+ *
+ * Returns the socket id associated with a specified CPU on NUMA systems.
+ * Socket ID numbering is system specific.
+ *
+ * @return Socket ID of the designated CPU
+ * @retval ODP_SOCKET_ID_ANY If the specified CPU is unknown or caller is
+ * not running on a NUMA system.


Maybe worth to differentiate between the two scenario with different 
return value? To query for an invalid CPU sounds like a serious problem 
in the application while the other is part of normal operation.



+ */
+uint32_t odp_cpu_socket_id_cpu(int cpu_id);
+
+/**
   * CPU count
   *
   * Report the number of CPU's available to this ODP program.


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

Re: [lng-odp] Setting MTU

[Zoltan Kiss]

On 29/01/16 08:26, Savolainen, Petri (Nokia - FI/Espoo) wrote:

If two applications share a link (pktio),


A diverging question, but: how does that work? Who calls 
odp_init_global()? Who calls pktio_open? And how do they share the same 
pktio?



 both can send up to MTU sized

frames … and if one of them wants send less than MTU sized frames, it’s
free to do that (without forcing the other app to the same limit). From
ODP API point of view, MTU is the limit of the local transmit buffer.
Whereas from IP stack point of view (to avoid fragmenting) it could be
the minimum of: local tx buf (== ODP MTU), gateway rx/tx buf and
destination rx buf sizes.


The reason I asked because although OVS follows the idea Bill explained, 
and handles the MTU as a read-only information (with the kernel module 
datapath you can send it with ifconfig), but there is an upcoming patch 
to implement a dpdk-mtu parameter, because in case of DPDK you can only 
set that through the application (except I think if you use KNI)


Regards,

Zoli



-Petri

*From:*lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of
*EXT Bill Fischofer
*Sent:* Thursday, January 28, 2016 7:25 PM
*To:* Mike Holmes
*Cc:* lng-odp
*Subject:* Re: [lng-odp] Setting MTU

The short answer is that MTU is not an application parameter but a
system configuration parameter.  As such it is the domain of the
control/management plane rather than the data plane.  The data plane
simply uses the MTU that has been configured elsewhere.  Applications
use higher-level segmenting like the TCP MSS that is negotiated for each
connection.

As a practical matter, at 10Gb and above link speeds (what ODP is
designed for), all interfaces should be running with 9K jumbo frames
anyway.  MTU is something of a legacy from the early days of networking
where primitive low-speed devices had extremely limited buffering
capacities, necessitating these tiny MTU values.  They are really not
relevant to 21st-century data plane processing.

On Thu, Jan 28, 2016 at 9:06 AM, Mike Holmes mailto:mike.hol...@linaro.org>> wrote:

commit 45598fea1a8a64ab49e191224784188382fbd466

Author: Petri Savolainen mailto:petri.savolai...@nokia.com>>

Date:   Thu Jan 21 11:39:29 2016 +0200

 api: pktio: remove odp_pktio_set_mtu

 Not all hardware can change MTU size from ODP application.

 Reviewed-by: Petri Savolainen mailto:petri.savolai...@linaro.org>>

 Signed-off-by: Maxim Uvarov mailto:maxim.uva...@linaro.org>>

On 28 January 2016 at 08:30, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:

Hi,

Is there a specific reason why we don't have an MTU setting API,
but only one to query it?

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



--

Mike Holmes

Technical Manager - Linaro Networking Group

Linaro.org ***│ *Open source software for
ARM SoCs

"Work should be fun and collborative, the rest follows"


___
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] [API-NEXT PATCHv5 6/6] documentation: userguide: add packet processing description

[Mike Holmes]

On 28 January 2016 at 10:05, Bill Fischofer 
wrote:

> Signed-off-by: Bill Fischofer 
>

Reviewed-by Mike Holmes 


> ---
>  doc/users-guide/users-guide.adoc | 121
> +++
>  1 file changed, 121 insertions(+)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index b3c08a1..b31e381 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -768,6 +768,127 @@ NOTE: Both ordered and parallel queues improve
> throughput over atomic queues
>  due to parallel event processing, but require that the application take
>  steps to ensure context data synchronization if needed.
>
> +== Packet Processing
> +ODP applications are designed to process packets, which are the basic
> unit of
> +data of interest in the data plane. To assist in processing packets, ODP
> +provides a set of APIs that enable applications to examine and manipulate
> +packet data and metadata. Packets are referenced by an abstract
> *odp_packet_t*
> +handle defined by each implementation.
> +
> +Packet objects are normally created at ingress when they arrive at a
> source
> +*odp_pktio_t* and are received by an application either directly or (more
> +typically) for a scheduled receive queue. They MAY be implicitly freed
> when
> +they are transmitted to an output *odp_pktio_t* via an associated transmit
> +queue, or freed directly via the +odp_packet_free()+ API.
> +
> +Occasionally an application may originate a packet itself, either _de
> novo_ or
> +by deriving it from an existing packet, and APIs are provided to assist in
> +these cases as well. Application-created packets can be recycled back
> through
> +a _loopback interface_ to reparse and reclassify them, or the application
> can
> +do its own parsing as desired.
> +
> +Various attributes associated with a packet, such as parse results, are
> +stored as metadata and APIs are provided to permit applications to examine
> +and/or modify this information.
> +
> +=== Packet Structure and Concepts
> +A _packet_ consists of a sequence of octets conforming to an architected
> +format, such as Ethernet, that can be received and transmitted via the ODP
> +*pktio* abstraction. Packets of a _length_, which is the number of bytes
> in
> +the packet. Packet data in ODP is referenced via _offsets_ since these
> reflect
> +the logical contents and structure of a packet independent of how
> particular
> +ODP implementations store that data.
> +
> +These concepts are shown in the following diagram:
> +
> +.ODP Packet Structure
> +image::../images/packet.svg[align="center"]
> +
> +Packet data consists of zero or more _headers_ followed by 0 or more
> bytes of
> +_payload_, followed by zero or more _trailers_.  Shown here are various
> APIs
> +that permit applications to examine and navigate various parts of a
> packet and
> +to manipulate its structure.
> +
> +To support packet manipulation, predefined _headroom_ and _tailroom_
> +areas are logically associated with a packet. Packets can be adjusted by
> +_pulling_ and _pushing_ these areas. Typical packet processing might
> consist
> +of stripping headers from a packet via +odp_pull_head()+ calls as part of
> +receive processing and then replacing them with new headers via
> ++odp_push_head()+ calls as the packet is being prepared for transmit.
> +
> +=== Packet Segments and Addressing
> +ODP platforms use various methods and techniques to store and process
> packets
> +efficiently. These vary considerably from platform to platform, so to
> ensure
> +portability across them ODP adopts certain conventions for referencing
> +packets.
> +
> +ODP APIs use a handle of type *odp_packet_t* to refer to packet objects.
> +Associated with packets are various bits of system metadata that describe
> the
> +packet. By referring to the metadata, ODP applications accelerate packet
> +processing by minimizing the need to examine packet data. This is because
> the
> +metadata is populated by parsing and classification functions that are
> coupled
> +to ingress processing that occur prior to a packet being presented to the
> +application via the ODP scheduler.
> +
> +When an ODP application needs to examine the contents of a packet, it
> requests
> +addressability to it via an API call that makes the packet (or a
> contiguously
> +addressable _segment_ of it) available for coherent access by the
> application.
> +To ensure portability, ODP applications assume that the underlying
> +implementation stores packets in _segments_ of implementation-defined
> +and managed size. These represent the contiguously addressable portions
> of a
> +packet that the application may refer to via normal memory accesses. ODP
> +provides APIs that allow applications to operate on packet segments in an
> +efficient and portable manner as needed. By combining these with the
> metadata
> +provided by packets, ODP applications can operate in a fully
> +platform-independent manner while still a

Re: [lng-odp] Setting MTU

[Bill Fischofer]

You can always pretend the MTU is smaller than it actually is and do
segmenting yourself, however this defeats the purpose of Large Segment
Offload (LSO), which is a key HW offload capability of most modern I/O
interfaces.  With LSO the application can send arbitrary sized packets (up
to at least 64KB) and the HW divides them into MTU-sized segments with
appropriate headers for each segment (e.g., ensuring IPv4 ID uniqueness,
proper TCP seq numbers, etc.) as part of TX processing.

On the RX side, Large Receive Offload (LRO) does the inverse, taking an
oversized arriving packet and chopping it up into MTU-sized packets, often
doing other things like header splitting for better cache utilization
(packet headers have their own separate receive buffers that are physically
disjoint from packet payload) since the network stacks are often most
concerned with headers rather than payload.

Do we know what the DPDK use case is for introducing this API?

On Fri, Jan 29, 2016 at 10:28 AM, Zoltan Kiss 
wrote:

>
>
> On 29/01/16 08:26, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>
>> If two applications share a link (pktio),
>>
>
> A diverging question, but: how does that work? Who calls
> odp_init_global()? Who calls pktio_open? And how do they share the same
> pktio?
>
>
>  both can send up to MTU sized
>
>> frames … and if one of them wants send less than MTU sized frames, it’s
>> free to do that (without forcing the other app to the same limit). From
>> ODP API point of view, MTU is the limit of the local transmit buffer.
>> Whereas from IP stack point of view (to avoid fragmenting) it could be
>> the minimum of: local tx buf (== ODP MTU), gateway rx/tx buf and
>> destination rx buf sizes.
>>
>
> The reason I asked because although OVS follows the idea Bill explained,
> and handles the MTU as a read-only information (with the kernel module
> datapath you can send it with ifconfig), but there is an upcoming patch to
> implement a dpdk-mtu parameter, because in case of DPDK you can only set
> that through the application (except I think if you use KNI)
>
> Regards,
>
> Zoli
>
>
>> -Petri
>>
>> *From:*lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of
>> *EXT Bill Fischofer
>> *Sent:* Thursday, January 28, 2016 7:25 PM
>> *To:* Mike Holmes
>> *Cc:* lng-odp
>> *Subject:* Re: [lng-odp] Setting MTU
>>
>> The short answer is that MTU is not an application parameter but a
>> system configuration parameter.  As such it is the domain of the
>> control/management plane rather than the data plane.  The data plane
>> simply uses the MTU that has been configured elsewhere.  Applications
>> use higher-level segmenting like the TCP MSS that is negotiated for each
>> connection.
>>
>> As a practical matter, at 10Gb and above link speeds (what ODP is
>> designed for), all interfaces should be running with 9K jumbo frames
>> anyway.  MTU is something of a legacy from the early days of networking
>> where primitive low-speed devices had extremely limited buffering
>> capacities, necessitating these tiny MTU values.  They are really not
>> relevant to 21st-century data plane processing.
>>
>> On Thu, Jan 28, 2016 at 9:06 AM, Mike Holmes > > wrote:
>>
>> commit 45598fea1a8a64ab49e191224784188382fbd466
>>
>> Author: Petri Savolainen > >
>>
>> Date:   Thu Jan 21 11:39:29 2016 +0200
>>
>>  api: pktio: remove odp_pktio_set_mtu
>>
>>  Not all hardware can change MTU size from ODP application.
>>
>>  Reviewed-by: Petri Savolainen > >
>>
>>  Signed-off-by: Maxim Uvarov > >
>>
>> On 28 January 2016 at 08:30, Zoltan Kiss > > wrote:
>>
>> Hi,
>>
>> Is there a specific reason why we don't have an MTU setting API,
>> but only one to query it?
>>
>> Zoli
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org 
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>> --
>>
>> Mike Holmes
>>
>> Technical Manager - Linaro Networking Group
>>
>> Linaro.org ***│ *Open source software for
>> ARM SoCs
>>
>> "Work should be fun and collborative, the rest follows"
>>
>>
>> ___
>> 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] [RFC API-NEXT PATCH 2/2] api: cpu: add routines for obtaining socket ids

[Bill Fischofer]

We'll be discussing this RFC on Monday's ARCH call.  I'm certainly open to
adding this if it's deemed useful.  I do note that DPDK defines SOCK_ID_ANY
to be -1 so I'd like to minimize translation overhead for odp-dpdk in this
area as well.

On Fri, Jan 29, 2016 at 10:27 AM, Zoltan Kiss 
wrote:

>
>
> On 29/01/16 02:44, Bill Fischofer wrote:
>
>> Add odp_cpu_socket_id() and odp_cpu_socket_id_cpu() routines
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>>   include/odp/api/cpu.h | 23 +++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/include/odp/api/cpu.h b/include/odp/api/cpu.h
>> index 4cbaf58..fe74825 100644
>> --- a/include/odp/api/cpu.h
>> +++ b/include/odp/api/cpu.h
>> @@ -36,6 +36,29 @@ extern "C" {
>>   int odp_cpu_id(void);
>>
>>   /**
>> + * CPU socket id
>> + *
>> + * Returns the socket id associated with the calling CPU on NUMA systems.
>> + * Socket ID numbering is system specific.
>> + *
>> + * @return Socket ID of the calling CPU
>> + * @retval ODP_SOCKET_ID_ANY  If the caller is not running on a NUMA
>> system.
>> + */
>> +uint32_t odp_cpu_socket_id(void);
>> +
>> +/**
>> + * CPU socket id of designated CPU
>> + *
>> + * Returns the socket id associated with a specified CPU on NUMA systems.
>> + * Socket ID numbering is system specific.
>> + *
>> + * @return Socket ID of the designated CPU
>> + * @retval ODP_SOCKET_ID_ANY If the specified CPU is unknown or caller is
>> + * not running on a NUMA system.
>>
>
> Maybe worth to differentiate between the two scenario with different
> return value? To query for an invalid CPU sounds like a serious problem in
> the application while the other is part of normal operation.
>
>
> + */
>> +uint32_t odp_cpu_socket_id_cpu(int cpu_id);
>> +
>> +/**
>>* CPU count
>>*
>>* Report the number of CPU's available to this ODP program.
>>
>>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp