Re: [lng-odp] odp dpdk

[Bogdan Pricope]

On RX side is kind-of expected result since it uses scheduler mode.

On TX side there is this drop from 10 mpps to 7.69 mpps that is unexpected.

So Petri, when you said:
"DPDK uses less optimized driver code (on Intel NICs at least) when
any of the L4 checksum offloads is enabled."

you were referring to this kind of drop in performance?

There is that 'folklore' that SW csum is faster on small packets while
HW csum is faster on bigger packets. Do you have this kind of data?

Anyway, for this particular case (odp_generator), since UDP
header/payload is not changing during the test (for now), csum is
calculated only once at the beginning of the test: so we are comparing
HW IPv4 + HW UDP csum vs. SW IPv4 csum yet, the differences in
performance is huge...


On 4 December 2017 at 20:37, Maxim Uvarov  wrote:
> I added isocpus and mounted huge page TX became more stable at 7.6M. But
> anyway it's better to test performance for this PR because previous
> speed was 10M.
>
> Maxim.
>
> On 12/04/17 19:42, Honnappa Nagarahalli wrote:
>> Can you run with Linux-DPDK in ODP 2.0?
>>
>> On 4 December 2017 at 09:54, Maxim Uvarov  wrote:
>>> after clean patches apply and fix in run scripts I made it run.
>>>
>>> But results is really bad. --enable-dpdk-zero-copy
>>>
>>> TX rate is:
>>> 7673155 pps
>>>
>>> RX rate is:
>>> 5989846 pps
>>>
>>>
>>> Before patch PR 313 TX was 10M pps.
>>>
>>> I re run task and TX is 3.3M pps. All tests are single core. So
>>> something strange happens in lava or this PR.
>>>
>>> Maxim.
>>>
>>>
>>> On 12/04/17 17:03, Bogdan Pricope wrote:
 On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:

 ODP_REPO='https://github.com/muvarov/odp'
 ODP_BRANCH='api-next'


 On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:

 ODP_REPO='https://github.com/muvarov/odp'
 ODP_BRANCH='devel/api-next_shsum'


 or are you referring to other test?


 On 4 December 2017 at 15:53, Maxim Uvarov  wrote:
>
>
> On 4 December 2017 at 15:11, Bogdan Pricope 
> wrote:
>>
>> You need to put 313 on TX side (not RX).
>
>
>
> both rx and tx have patches from 313. l2fwd works on recv side. Generator
> does not work.
>
> Maxim.
>
>
>>
>>
>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>>> Is the DPDK version 17.08 ? Other versions might not work properly.
>>>
>>>
>>>
>>> -Petri
>>>
>>>
>>>
>>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>>> Sent: Monday, December 04, 2017 1:10 PM
>>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>>> Cc: Bogdan Pricope ; lng-odp-forward
>>> 
>>>
>>>
>>> Subject: Re: [lng-odp] odp dpdk
>>>
>>>
>>>
>>> 313 does not work also:
>>>
>>> https://lng.validation.linaro.org/scheduler/job/23242.1
>>>
>>> I will replace RX side to l2fwd and see that will be there.
>>>
>>> Maxim.
>>>
>>>
>>>
>>>
>>>
>>> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>>>  wrote:
>>>
>>> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
>>> fix
>>> checksum insert for 10/40GE Intel NICs.
>>>
>>> -Petri
>>>
>>>
 -Original Message-
 From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
 Bogdan Pricope
 Sent: Monday, December 04, 2017 12:21 PM
 To: Maxim Uvarov 
 Cc: lng-odp-forward 
 Subject: Re: [lng-odp] odp dpdk

 I suspect this is actually caused by csum issue in TX side: on RX,
 socket pktio does not validate csum (and accept the packets) but on
 dpdk pktio the csum is validated and packets are dropped.

 I am not seeing this in my setup because default txq_flags for igb
 driver (1G interface) is

 .txq_flags = 0

 while for ixgbe (10G interface) is:

 .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
 ETH_TXQ_FLAGS_NOOFFLOADS,


 /B




 On 1 December 2017 at 23:47, Maxim Uvarov 
 wrote:
>
> Looking to dpdk pktio support and generator. It looks like receive
> part
> is broken. If for receive I use sockets it works well but receive
> with
> dpdk does not get any packets. For both master and api-next. Can
> somebody confirm please that it's so. Lava is not supper friendly to
> 

[lng-odp] Planning for 2.0 work items

[Honnappa Nagarahalli]

Hi,
   As discussed in the ODP 2.0 call (11/30/2017), we identified the
following areas of work. The idea is to have few demos with net-mdev
and user-space drivers for HKG18. The goal is to have all this
upstreamed by HKG18. I have mentioned a partial list of owners, please
feel free to add yourself to the list. Can the respective owners get
with Darcy, identify the scope and work items.

1) Upstreaming net-mdev (Ilias, Mykyta, Francois)

a) Upstreaming to ODP 2.0

b) Upstreaming to Linux Kernel

2) Performance benchmarking (need owners)

a) Need to have a framework which allows for instrumenting
the code and logging the time stamp. This will allow for identifying
the number of cycles spent in various parts of the code. Need to
identify tools that can be used to plot the collected data.

   b) Need to have a benchmarking application which runs
packets through the typical path with dummy packet I/O - could be run
on any machine - loopback pkt I/O could be used.

3) Directory structure

  a) Changes required to provide clarity of design.

4) Upstream user space drivers (Jianbo, Yi, Josep)

Please let me know if you have any questions.

Thank you,
Honnappa

[lng-odp] [Linaro/odp] 811281: travis: add enable-deprecated test configuration

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 811281a22b6274b7f41b926a9cfbe09e48a366bd
  
https://github.com/Linaro/odp/commit/811281a22b6274b7f41b926a9cfbe09e48a366bd
  Author: Matias Elo 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M .travis.yml

  Log Message:
  ---
  travis: add enable-deprecated test configuration

Test ODP build with 'enable-deprecated' flag set.

Signed-off-by: Matias Elo 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 

[lng-odp] [Linaro/odp] 7c027d: api: pool: relax packet pool param num

[GitHub]

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 7c027d493295ba07fd27697827300e4c8e15475d
  
https://github.com/Linaro/odp/commit/7c027d493295ba07fd27697827300e4c8e15475d
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M include/odp/api/spec/pool.h

  Log Message:
  ---
  api: pool: relax packet pool param num

Added packet pool parameter 'max_num', so that 'num' parameter
can be round up by the implementation. Most implementations have
a fixed segment size, and need this flexibility. For example,
when 'len' is larger than the pool segment size, there may be
e.g. 2 x 'num' segments in the poool, and thus it would be
able to allocate 2 x 'num' small packets. When application
needs to limit maximum number of packets on a pool, it can
use the new max_num param for that. Otherwise, it would leave
'max_num' to zero (== no limit).

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 1e41d8bb45ccc1d7f5b7340742d8c9f85eb9660c
  
https://github.com/Linaro/odp/commit/1e41d8bb45ccc1d7f5b7340742d8c9f85eb9660c
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M include/odp/api/spec/pool.h

  Log Message:
  ---
  api: pool: add packet pool subparameters

Additional packet length and number specification gives
more information to implementation about intended packet
length distribution in the pool. This enables e.g. correct
initialization when pool implementation is based on multiple
fixed packet / segment sizes (subpools). The specification
does require subpool implementation but allows it.

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 52b07a3ffadeb7f653b1a3a1a129402e3becd027
  
https://github.com/Linaro/odp/commit/52b07a3ffadeb7f653b1a3a1a129402e3becd027
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M test/validation/api/pool/pool.c
M test/validation/api/pool/pool.h

  Log Message:
  ---
  validation: pool: add subparam test

Test packet pool subparameters when those are supported.

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: ea8e4fff42411c5534ba7fbeeefd8fec4c1ac8be
  
https://github.com/Linaro/odp/commit/ea8e4fff42411c5534ba7fbeeefd8fec4c1ac8be
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M test/validation/api/pool/pool.c

  Log Message:
  ---
  validation: pool: initialize params correctly

Use odp_pool_param_init() to initialize pool parameters.

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: a65377ad173426db06b023764703f158e88565e2
  
https://github.com/Linaro/odp/commit/a65377ad173426db06b023764703f158e88565e2
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M include/odp/api/spec/pool.h

  Log Message:
  ---
  api: pool: add max packet num info

Packet pool parameters does not require application to specify
the maximum number of packet. Application is more portable, if
it does not restrict max_num, but instead uses this info field
after pool creation.

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 94530b3d56086e446fe056098fa37da048efd1b6
  
https://github.com/Linaro/odp/commit/94530b3d56086e446fe056098fa37da048efd1b6
  Author: Petri Savolainen 
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
M platform/linux-generic/odp_pool.c

  Log Message:
  ---
  linux-gen: pool: implement max_num info

Implemented max_num info for packet pools.

Signed-off-by: Petri Savolainen 
Reviewed-by: Balasubramanian Manoharan 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
This is interesting. I manually added the braces to push forward and now I see 
this:
```
  CC   pktio/dpdk.lo
In file included from ./pktio/dpdk.h:46:0,
 from pktio/dpdk.c:35:
/home/bill/linaro/dpdk/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h: In 
function ‘rte_hash_crc_set_alg’:
/home/bill/linaro/dpdk/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:477:6: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
   if (! rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T))
  ^
/home/bill/linaro/dpdk/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:479:2: 
note: here
  case CRC32_SSE42:
  ^~~~
/home/bill/linaro/dpdk/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:480:6: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
   if (! rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_2))
  ^
/home/bill/linaro/dpdk/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:483:2: 
note: here
  case CRC32_SW:
  ^~~~
cc1: all warnings being treated as errors
Makefile:1417: recipe for target 'pktio/dpdk.lo' failed
make[1]: *** [pktio/dpdk.lo] Error 1
```
I still have DPDK 17.02 installed but that clearly isn't compatible with GCC 7 
either. These sort of errors suggest that PR #321  posted by @lumag may also 
have some compiler-level sensitivities.

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> OK, I'm unable to verify that given this other issue. I've verified I see the 
> same error on the current 2.0 branch without any `--enable-schedule-xxx` 
> options.
> 
> @muvarov Any ideas why Travis isn't seeing this? This clearly is an error in 
> the code:
> ```
>   /* Setup session */
>   session = rte_cryptodev_sym_session_create(cdev_id, first_xform);
> 
>   if (session == NULL)
>   /* remove the crypto_session_entry_t */
>   memset(entry, 0, sizeof(*entry));
>   free_session(entry);
>   return -1;
> 
>   entry->rte_session  = (intptr_t)session;
> ```
> That `if` statement should be in braces.


>> nagarahalli wrote
>> This make file change is for not compiling default queue when scalable queue 
>> is enabled. This is required since the meta data fields required for default 
>> queue are not available when scalable queue is enabled.


>>> nagarahalli wrote
>>> I am using GCC 5.4.0


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Hmmm, with that combo I'm seeing a different issue:
 ```
   CC   odp_crypto.lo
 odp_crypto.c: In function ‘odp_crypto_session_create’:
 odp_crypto.c:901:2: error: this ‘if’ clause does not guard... 
 [-Werror=misleading-indentation]
   if (session == NULL)
   ^~
 odp_crypto.c:904:3: note: ...this statement, but the latter is 
 misleadingly indented as if it were guarded by the ‘if’
free_session(entry);
^~~~
 cc1: all warnings being treated as errors
 Makefile:1417: recipe for target 'odp_crypto.lo' failed
 ```
 
 This looks like the base code is having problem with GCC 7? I'm running 
 Ubundu 17.10 which uses GCC 7.2.


> nagarahalli wrote
> Without these changes, try the compilation for the following 
> configuration:
> ./configure --with-platform=linux-dpdk --enable-schedule-scalable  
> --with-sdk-install-path=


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> I did some experimenting with this and this seems to compile and run 
>> just fine without these Makefile.am changes. Am I missing something?


>>> nagarahalli wrote
>>> As we discussed in the call today, this is temporary. Once the changes, 
>>> not to use packet meta data, to default queue implementation is done, 
>>> these can go away.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Is this intended to be a temporary change? The problem with 
 conditional compilation is that it's very easy to make changes that 
 break another file that isn't compiled unless some special config 
 option is used. That's why in today's config-based scheduler selection 
 we compile all modules and the only thing that's actually conditional 
 is which entry points are plugged into the scheduler interface table.
 
 For 2.0 we want to eliminate config-time selections like this, so all 
 variants will necessarily have to be compiled to be included in the 
 single binary and selected dynamically at runtime. So I'm not sure 
 

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
OK, I'm unable to verify that given this other issue. I've verified I see the 
same error on the current 2.0 branch without any `--enable-schedule-xxx` 
options.

@muvarov Any ideas why Travis isn't seeing this? This clearly is an error in 
the code:
```
/* Setup session */
session = rte_cryptodev_sym_session_create(cdev_id, first_xform);

if (session == NULL)
/* remove the crypto_session_entry_t */
memset(entry, 0, sizeof(*entry));
free_session(entry);
return -1;

entry->rte_session  = (intptr_t)session;
```
That `if` statement should be in braces.

> nagarahalli wrote
> This make file change is for not compiling default queue when scalable queue 
> is enabled. This is required since the meta data fields required for default 
> queue are not available when scalable queue is enabled.


>> nagarahalli wrote
>> I am using GCC 5.4.0


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Hmmm, with that combo I'm seeing a different issue:
>>> ```
>>>   CC   odp_crypto.lo
>>> odp_crypto.c: In function ‘odp_crypto_session_create’:
>>> odp_crypto.c:901:2: error: this ‘if’ clause does not guard... 
>>> [-Werror=misleading-indentation]
>>>   if (session == NULL)
>>>   ^~
>>> odp_crypto.c:904:3: note: ...this statement, but the latter is misleadingly 
>>> indented as if it were guarded by the ‘if’
>>>free_session(entry);
>>>^~~~
>>> cc1: all warnings being treated as errors
>>> Makefile:1417: recipe for target 'odp_crypto.lo' failed
>>> ```
>>> 
>>> This looks like the base code is having problem with GCC 7? I'm running 
>>> Ubundu 17.10 which uses GCC 7.2.


 nagarahalli wrote
 Without these changes, try the compilation for the following configuration:
 ./configure --with-platform=linux-dpdk --enable-schedule-scalable  
 --with-sdk-install-path=


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I did some experimenting with this and this seems to compile and run just 
> fine without these Makefile.am changes. Am I missing something?


>> nagarahalli wrote
>> As we discussed in the call today, this is temporary. Once the changes, 
>> not to use packet meta data, to default queue implementation is done, 
>> these can go away.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Is this intended to be a temporary change? The problem with conditional 
>>> compilation is that it's very easy to make changes that break another 
>>> file that isn't compiled unless some special config option is used. 
>>> That's why in today's config-based scheduler selection we compile all 
>>> modules and the only thing that's actually conditional is which entry 
>>> points are plugged into the scheduler interface table.
>>> 
>>> For 2.0 we want to eliminate config-time selections like this, so all 
>>> variants will necessarily have to be compiled to be included in the 
>>> single binary and selected dynamically at runtime. So I'm not sure this 
>>> sort of change is consistent with that goal. This seems to need more 
>>> discussion as to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154742704
updated_at 2017-12-04 18:59:38

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

nagarahalli replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
This make file change is for not compiling default queue when scalable queue is 
enabled. This is required since the meta data fields required for default queue 
are not available when scalable queue is enabled.

> nagarahalli wrote
> I am using GCC 5.4.0


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Hmmm, with that combo I'm seeing a different issue:
>> ```
>>   CC   odp_crypto.lo
>> odp_crypto.c: In function ‘odp_crypto_session_create’:
>> odp_crypto.c:901:2: error: this ‘if’ clause does not guard... 
>> [-Werror=misleading-indentation]
>>   if (session == NULL)
>>   ^~
>> odp_crypto.c:904:3: note: ...this statement, but the latter is misleadingly 
>> indented as if it were guarded by the ‘if’
>>free_session(entry);
>>^~~~
>> cc1: all warnings being treated as errors
>> Makefile:1417: recipe for target 'odp_crypto.lo' failed
>> ```
>> 
>> This looks like the base code is having problem with GCC 7? I'm running 
>> Ubundu 17.10 which uses GCC 7.2.


>>> nagarahalli wrote
>>> Without these changes, try the compilation for the following configuration:
>>> ./configure --with-platform=linux-dpdk --enable-schedule-scalable  
>>> --with-sdk-install-path=


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 I did some experimenting with this and this seems to compile and run just 
 fine without these Makefile.am changes. Am I missing something?


> nagarahalli wrote
> As we discussed in the call today, this is temporary. Once the changes, 
> not to use packet meta data, to default queue implementation is done, 
> these can go away.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Is this intended to be a temporary change? The problem with conditional 
>> compilation is that it's very easy to make changes that break another 
>> file that isn't compiled unless some special config option is used. 
>> That's why in today's config-based scheduler selection we compile all 
>> modules and the only thing that's actually conditional is which entry 
>> points are plugged into the scheduler interface table.
>> 
>> For 2.0 we want to eliminate config-time selections like this, so all 
>> variants will necessarily have to be compiled to be included in the 
>> single binary and selected dynamically at runtime. So I'm not sure this 
>> sort of change is consistent with that goal. This seems to need more 
>> discussion as to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154741738
updated_at 2017-12-04 18:56:09

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
Hmmm, with that combo I'm seeing a different issue:
```
  CC   odp_crypto.lo
odp_crypto.c: In function ‘odp_crypto_session_create’:
odp_crypto.c:901:2: error: this ‘if’ clause does not guard... 
[-Werror=misleading-indentation]
  if (session == NULL)
  ^~
odp_crypto.c:904:3: note: ...this statement, but the latter is misleadingly 
indented as if it were guarded by the ‘if’
   free_session(entry);
   ^~~~
cc1: all warnings being treated as errors
Makefile:1417: recipe for target 'odp_crypto.lo' failed
```

This looks like the base code is having problem with GCC 7? I'm running Ubundu 
17.10 which uses GCC 7.2.

> nagarahalli wrote
> Without these changes, try the compilation for the following configuration:
> ./configure --with-platform=linux-dpdk --enable-schedule-scalable  
> --with-sdk-install-path=


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> I did some experimenting with this and this seems to compile and run just 
>> fine without these Makefile.am changes. Am I missing something?


>>> nagarahalli wrote
>>> As we discussed in the call today, this is temporary. Once the changes, not 
>>> to use packet meta data, to default queue implementation is done, these can 
>>> go away.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Is this intended to be a temporary change? The problem with conditional 
 compilation is that it's very easy to make changes that break another file 
 that isn't compiled unless some special config option is used. That's why 
 in today's config-based scheduler selection we compile all modules and the 
 only thing that's actually conditional is which entry points are plugged 
 into the scheduler interface table.
 
 For 2.0 we want to eliminate config-time selections like this, so all 
 variants will necessarily have to be compiled to be included in the single 
 binary and selected dynamically at runtime. So I'm not sure this sort of 
 change is consistent with that goal. This seems to need more discussion as 
 to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154737345
updated_at 2017-12-04 18:42:08

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

nagarahalli replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
I am using GCC 5.4.0

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Hmmm, with that combo I'm seeing a different issue:
> ```
>   CC   odp_crypto.lo
> odp_crypto.c: In function ‘odp_crypto_session_create’:
> odp_crypto.c:901:2: error: this ‘if’ clause does not guard... 
> [-Werror=misleading-indentation]
>   if (session == NULL)
>   ^~
> odp_crypto.c:904:3: note: ...this statement, but the latter is misleadingly 
> indented as if it were guarded by the ‘if’
>free_session(entry);
>^~~~
> cc1: all warnings being treated as errors
> Makefile:1417: recipe for target 'odp_crypto.lo' failed
> ```
> 
> This looks like the base code is having problem with GCC 7? I'm running 
> Ubundu 17.10 which uses GCC 7.2.


>> nagarahalli wrote
>> Without these changes, try the compilation for the following configuration:
>> ./configure --with-platform=linux-dpdk --enable-schedule-scalable  
>> --with-sdk-install-path=


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> I did some experimenting with this and this seems to compile and run just 
>>> fine without these Makefile.am changes. Am I missing something?


 nagarahalli wrote
 As we discussed in the call today, this is temporary. Once the changes, 
 not to use packet meta data, to default queue implementation is done, 
 these can go away.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Is this intended to be a temporary change? The problem with conditional 
> compilation is that it's very easy to make changes that break another 
> file that isn't compiled unless some special config option is used. 
> That's why in today's config-based scheduler selection we compile all 
> modules and the only thing that's actually conditional is which entry 
> points are plugged into the scheduler interface table.
> 
> For 2.0 we want to eliminate config-time selections like this, so all 
> variants will necessarily have to be compiled to be included in the 
> single binary and selected dynamically at runtime. So I'm not sure this 
> sort of change is consistent with that goal. This seems to need more 
> discussion as to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154741057
updated_at 2017-12-04 18:53:44

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

nagarahalli replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
Without these changes, try the compilation for the following configuration:
./configure --with-platform=linux-dpdk --enable-schedule-scalable  
--with-sdk-install-path=

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I did some experimenting with this and this seems to compile and run just 
> fine without these Makefile.am changes. Am I missing something?


>> nagarahalli wrote
>> As we discussed in the call today, this is temporary. Once the changes, not 
>> to use packet meta data, to default queue implementation is done, these can 
>> go away.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Is this intended to be a temporary change? The problem with conditional 
>>> compilation is that it's very easy to make changes that break another file 
>>> that isn't compiled unless some special config option is used. That's why 
>>> in today's config-based scheduler selection we compile all modules and the 
>>> only thing that's actually conditional is which entry points are plugged 
>>> into the scheduler interface table.
>>> 
>>> For 2.0 we want to eliminate config-time selections like this, so all 
>>> variants will necessarily have to be compiled to be included in the single 
>>> binary and selected dynamically at runtime. So I'm not sure this sort of 
>>> change is consistent with that goal. This seems to need more discussion as 
>>> to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154733899
updated_at 2017-12-04 18:30:35

Re: [lng-odp] [PATCH 2.0 v1] linux-dpdk: buffer: remove default queue meta data

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

platform/linux-dpdk/Makefile.am
line 19
@@ -348,8 +346,10 @@ endif
 endif
 endif
 if ODP_SCHEDULE_SCALABLE
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/scalable.c
 ../linux-generic/queue/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
+__LIB__libodp_dpdk_la_SOURCES += ../linux-generic/queue/generic.c
 ../linux-generic/queue/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 endif
 


Comment:
I did some experimenting with this and this seems to compile and run just fine 
without these Makefile.am changes. Am I missing something?

> nagarahalli wrote
> As we discussed in the call today, this is temporary. Once the changes, not 
> to use packet meta data, to default queue implementation is done, these can 
> go away.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Is this intended to be a temporary change? The problem with conditional 
>> compilation is that it's very easy to make changes that break another file 
>> that isn't compiled unless some special config option is used. That's why in 
>> today's config-based scheduler selection we compile all modules and the only 
>> thing that's actually conditional is which entry points are plugged into the 
>> scheduler interface table.
>> 
>> For 2.0 we want to eliminate config-time selections like this, so all 
>> variants will necessarily have to be compiled to be included in the single 
>> binary and selected dynamically at runtime. So I'm not sure this sort of 
>> change is consistent with that goal. This seems to need more discussion as 
>> to why we're doing this here.


https://github.com/Linaro/odp/pull/303#discussion_r154729024
updated_at 2017-12-04 18:12:15

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

I added isocpus and mounted huge page TX became more stable at 7.6M. But
anyway it's better to test performance for this PR because previous
speed was 10M.

Maxim.

On 12/04/17 19:42, Honnappa Nagarahalli wrote:
> Can you run with Linux-DPDK in ODP 2.0?
> 
> On 4 December 2017 at 09:54, Maxim Uvarov  wrote:
>> after clean patches apply and fix in run scripts I made it run.
>>
>> But results is really bad. --enable-dpdk-zero-copy
>>
>> TX rate is:
>> 7673155 pps
>>
>> RX rate is:
>> 5989846 pps
>>
>>
>> Before patch PR 313 TX was 10M pps.
>>
>> I re run task and TX is 3.3M pps. All tests are single core. So
>> something strange happens in lava or this PR.
>>
>> Maxim.
>>
>>
>> On 12/04/17 17:03, Bogdan Pricope wrote:
>>> On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:
>>>
>>> ODP_REPO='https://github.com/muvarov/odp'
>>> ODP_BRANCH='api-next'
>>>
>>>
>>> On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:
>>>
>>> ODP_REPO='https://github.com/muvarov/odp'
>>> ODP_BRANCH='devel/api-next_shsum'
>>>
>>>
>>> or are you referring to other test?
>>>
>>>
>>> On 4 December 2017 at 15:53, Maxim Uvarov  wrote:


 On 4 December 2017 at 15:11, Bogdan Pricope 
 wrote:
>
> You need to put 313 on TX side (not RX).



 both rx and tx have patches from 313. l2fwd works on recv side. Generator
 does not work.

 Maxim.


>
>
> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>> Is the DPDK version 17.08 ? Other versions might not work properly.
>>
>>
>>
>> -Petri
>>
>>
>>
>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>> Sent: Monday, December 04, 2017 1:10 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> Cc: Bogdan Pricope ; lng-odp-forward
>> 
>>
>>
>> Subject: Re: [lng-odp] odp dpdk
>>
>>
>>
>> 313 does not work also:
>>
>> https://lng.validation.linaro.org/scheduler/job/23242.1
>>
>> I will replace RX side to l2fwd and see that will be there.
>>
>> Maxim.
>>
>>
>>
>>
>>
>> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>>
>> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
>> fix
>> checksum insert for 10/40GE Intel NICs.
>>
>> -Petri
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> Bogdan Pricope
>>> Sent: Monday, December 04, 2017 12:21 PM
>>> To: Maxim Uvarov 
>>> Cc: lng-odp-forward 
>>> Subject: Re: [lng-odp] odp dpdk
>>>
>>> I suspect this is actually caused by csum issue in TX side: on RX,
>>> socket pktio does not validate csum (and accept the packets) but on
>>> dpdk pktio the csum is validated and packets are dropped.
>>>
>>> I am not seeing this in my setup because default txq_flags for igb
>>> driver (1G interface) is
>>>
>>> .txq_flags = 0
>>>
>>> while for ixgbe (10G interface) is:
>>>
>>> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>>> ETH_TXQ_FLAGS_NOOFFLOADS,
>>>
>>>
>>> /B
>>>
>>>
>>>
>>>
>>> On 1 December 2017 at 23:47, Maxim Uvarov 
>>> wrote:

 Looking to dpdk pktio support and generator. It looks like receive
 part
 is broken. If for receive I use sockets it works well but receive
 with
 dpdk does not get any packets. For both master and api-next. Can
 somebody confirm please that it's so. Lava is not supper friendly to
 debug issue.


 1. Recv
 odp_generator -I 0 -m r -c 0x4

 https://lng.validation.linaro.org/scheduler/job/23206.1
 Network devices using DPDK-compatible driver
 
 :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
 drv=igb_uio unused=



 2. Send
 odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
 38:ea:a7:93:83:a0
 --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
 5000 -f 5001 -n 8

 https://lng.validation.linaro.org/scheduler/job/23206.0

 Thank you,
 Maxim.
>>
>>


>>

Re: [lng-odp] odp dpdk

[Honnappa Nagarahalli]

Can you run with Linux-DPDK in ODP 2.0?

On 4 December 2017 at 09:54, Maxim Uvarov  wrote:
> after clean patches apply and fix in run scripts I made it run.
>
> But results is really bad. --enable-dpdk-zero-copy
>
> TX rate is:
> 7673155 pps
>
> RX rate is:
> 5989846 pps
>
>
> Before patch PR 313 TX was 10M pps.
>
> I re run task and TX is 3.3M pps. All tests are single core. So
> something strange happens in lava or this PR.
>
> Maxim.
>
>
> On 12/04/17 17:03, Bogdan Pricope wrote:
>> On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:
>>
>> ODP_REPO='https://github.com/muvarov/odp'
>> ODP_BRANCH='api-next'
>>
>>
>> On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:
>>
>> ODP_REPO='https://github.com/muvarov/odp'
>> ODP_BRANCH='devel/api-next_shsum'
>>
>>
>> or are you referring to other test?
>>
>>
>> On 4 December 2017 at 15:53, Maxim Uvarov  wrote:
>>>
>>>
>>> On 4 December 2017 at 15:11, Bogdan Pricope 
>>> wrote:

 You need to put 313 on TX side (not RX).
>>>
>>>
>>>
>>> both rx and tx have patches from 313. l2fwd works on recv side. Generator
>>> does not work.
>>>
>>> Maxim.
>>>
>>>


 On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
  wrote:
> Is the DPDK version 17.08 ? Other versions might not work properly.
>
>
>
> -Petri
>
>
>
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Monday, December 04, 2017 1:10 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bogdan Pricope ; lng-odp-forward
> 
>
>
> Subject: Re: [lng-odp] odp dpdk
>
>
>
> 313 does not work also:
>
> https://lng.validation.linaro.org/scheduler/job/23242.1
>
> I will replace RX side to l2fwd and see that will be there.
>
> Maxim.
>
>
>
>
>
> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>
> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
> fix
> checksum insert for 10/40GE Intel NICs.
>
> -Petri
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Bogdan Pricope
>> Sent: Monday, December 04, 2017 12:21 PM
>> To: Maxim Uvarov 
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] odp dpdk
>>
>> I suspect this is actually caused by csum issue in TX side: on RX,
>> socket pktio does not validate csum (and accept the packets) but on
>> dpdk pktio the csum is validated and packets are dropped.
>>
>> I am not seeing this in my setup because default txq_flags for igb
>> driver (1G interface) is
>>
>> .txq_flags = 0
>>
>> while for ixgbe (10G interface) is:
>>
>> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> ETH_TXQ_FLAGS_NOOFFLOADS,
>>
>>
>> /B
>>
>>
>>
>>
>> On 1 December 2017 at 23:47, Maxim Uvarov 
>> wrote:
>>>
>>> Looking to dpdk pktio support and generator. It looks like receive
>>> part
>>> is broken. If for receive I use sockets it works well but receive
>>> with
>>> dpdk does not get any packets. For both master and api-next. Can
>>> somebody confirm please that it's so. Lava is not supper friendly to
>>> debug issue.
>>>
>>>
>>> 1. Recv
>>> odp_generator -I 0 -m r -c 0x4
>>>
>>> https://lng.validation.linaro.org/scheduler/job/23206.1
>>> Network devices using DPDK-compatible driver
>>> 
>>> :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>>> drv=igb_uio unused=
>>>
>>>
>>>
>>> 2. Send
>>> odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
>>> 38:ea:a7:93:83:a0
>>> --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>>> 5000 -f 5001 -n 8
>>>
>>> https://lng.validation.linaro.org/scheduler/job/23206.0
>>>
>>> Thank you,
>>> Maxim.
>
>
>>>
>>>
>

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

after clean patches apply and fix in run scripts I made it run.

But results is really bad. --enable-dpdk-zero-copy

TX rate is:
7673155 pps

RX rate is:
5989846 pps


Before patch PR 313 TX was 10M pps.

I re run task and TX is 3.3M pps. All tests are single core. So
something strange happens in lava or this PR.

Maxim.


On 12/04/17 17:03, Bogdan Pricope wrote:
> On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:
> 
> ODP_REPO='https://github.com/muvarov/odp'
> ODP_BRANCH='api-next'
> 
> 
> On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:
> 
> ODP_REPO='https://github.com/muvarov/odp'
> ODP_BRANCH='devel/api-next_shsum'
> 
> 
> or are you referring to other test?
> 
> 
> On 4 December 2017 at 15:53, Maxim Uvarov  wrote:
>>
>>
>> On 4 December 2017 at 15:11, Bogdan Pricope 
>> wrote:
>>>
>>> You need to put 313 on TX side (not RX).
>>
>>
>>
>> both rx and tx have patches from 313. l2fwd works on recv side. Generator
>> does not work.
>>
>> Maxim.
>>
>>
>>>
>>>
>>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>>>  wrote:
 Is the DPDK version 17.08 ? Other versions might not work properly.



 -Petri



 From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
 Sent: Monday, December 04, 2017 1:10 PM
 To: Savolainen, Petri (Nokia - FI/Espoo) 
 Cc: Bogdan Pricope ; lng-odp-forward
 


 Subject: Re: [lng-odp] odp dpdk



 313 does not work also:

 https://lng.validation.linaro.org/scheduler/job/23242.1

 I will replace RX side to l2fwd and see that will be there.

 Maxim.





 On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
  wrote:

 Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
 fix
 checksum insert for 10/40GE Intel NICs.

 -Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Bogdan Pricope
> Sent: Monday, December 04, 2017 12:21 PM
> To: Maxim Uvarov 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] odp dpdk
>
> I suspect this is actually caused by csum issue in TX side: on RX,
> socket pktio does not validate csum (and accept the packets) but on
> dpdk pktio the csum is validated and packets are dropped.
>
> I am not seeing this in my setup because default txq_flags for igb
> driver (1G interface) is
>
> .txq_flags = 0
>
> while for ixgbe (10G interface) is:
>
> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> ETH_TXQ_FLAGS_NOOFFLOADS,
>
>
> /B
>
>
>
>
> On 1 December 2017 at 23:47, Maxim Uvarov 
> wrote:
>>
>> Looking to dpdk pktio support and generator. It looks like receive
>> part
>> is broken. If for receive I use sockets it works well but receive
>> with
>> dpdk does not get any packets. For both master and api-next. Can
>> somebody confirm please that it's so. Lava is not supper friendly to
>> debug issue.
>>
>>
>> 1. Recv
>> odp_generator -I 0 -m r -c 0x4
>>
>> https://lng.validation.linaro.org/scheduler/job/23206.1
>> Network devices using DPDK-compatible driver
>> 
>> :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> drv=igb_uio unused=
>>
>>
>>
>> 2. Send
>> odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
>> 38:ea:a7:93:83:a0
>> --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> 5000 -f 5001 -n 8
>>
>> https://lng.validation.linaro.org/scheduler/job/23206.0
>>
>> Thank you,
>> Maxim.


>>
>>

[lng-odp] [PATCH v2 4/6] linux-gen: pktio: support using DPDK lt 17.08

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Debian unstable ships with DPDK 16.11. Add support for building with
this version.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 platform/linux-generic/pktio/dpdk.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 07671e62f..fa73cb93d 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -29,14 +29,27 @@
 
 #include 
 #include 
+#if __GNUC__ >= 7
+#pragma GCC diagnostic push
+#pragma GCC diagnostic warning "-Wimplicit-fallthrough=0"
+#endif
 #include 
+#if __GNUC__ >= 7
+#pragma GCC diagnostic pop
+#endif
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+
+#if RTE_VERSION < RTE_VERSION_NUM(17, 8, 0, 0)
+#define rte_log_set_global_level rte_set_log_level
+#endif
 
 #if ODP_DPDK_ZERO_COPY
 ODP_STATIC_ASSERT(CONFIG_PACKET_HEADROOM == RTE_PKTMBUF_HEADROOM,
@@ -54,6 +67,7 @@ static int disable_pktio; /** !0 this pktio disabled, 0 
enabled */
 /* Has dpdk_pktio_init() been called */
 static odp_bool_t dpdk_initialized;
 
+#ifndef RTE_BUILD_SHARED_LIB
 #define MEMPOOL_OPS(hdl) \
 extern void mp_hdlr_init_##hdl(void)
 
@@ -77,6 +91,7 @@ void refer_constructors(void)
mp_hdlr_init_ops_sp_mc();
mp_hdlr_init_ops_stack();
 }
+#endif
 
 /**
  * Calculate valid cache size for DPDK packet pool
@@ -928,6 +943,11 @@ static int dpdk_close(pktio_entry_t *pktio_entry)
rte_pktmbuf_free(pkt_dpdk->rx_cache[i].s.pkt[idx++]);
}
 
+#if RTE_VERSION < RTE_VERSION_NUM(17, 8, 0, 0)
+   if (pktio_entry->s.state != PKTIO_STATE_OPENED)
+   rte_eth_dev_close(pkt_dpdk->port_id);
+#endif
+
return 0;
 }
 
@@ -1064,14 +1084,16 @@ static void dpdk_mempool_free(struct rte_mempool *mp, 
void *arg ODP_UNUSED)
 
 static int dpdk_pktio_term(void)
 {
-   uint8_t port_id;
-
if (!dpdk_initialized)
return 0;
 
+#if RTE_VERSION >= RTE_VERSION_NUM(17, 8, 0, 0)
+   uint8_t port_id;
+
RTE_ETH_FOREACH_DEV(port_id) {
rte_eth_dev_close(port_id);
}
+#endif
 
if (!ODP_DPDK_ZERO_COPY)
rte_mempool_walk(dpdk_mempool_free, NULL);

[lng-odp] [PATCH v2 3/6] linux-gen: add support for using system-wide DPDK

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Support using distro-installed DPDK for Pkt I/O. Distributions (like
Ubuntu, Debian, etc) start providing DPDK packages. It is wise to enable
users to use distro-provided DPDK version rather than requiring to
always compile it from sources.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 m4/odp_dpdk.m4| 43 ---
 platform/linux-generic/m4/odp_dpdk.m4 | 28 +++
 2 files changed, 58 insertions(+), 13 deletions(-)

diff --git a/m4/odp_dpdk.m4 b/m4/odp_dpdk.m4
index 636170a7f..05e60cc06 100644
--- a/m4/odp_dpdk.m4
+++ b/m4/odp_dpdk.m4
@@ -16,6 +16,31 @@ AS_VAR_APPEND([DPDK_PMDS], [--no-whole-archive])
 AC_SUBST([DPDK_PMDS])
 ])
 
+# _ODP_DPDK_CHECK_LIB(LDFLAGS, [LIBS], [EXTRA_LIBS])
+# --
+# Check if one can use -ldpdk with provided set of libs
+AC_DEFUN([_ODP_DPDK_CHECK_LIB], [dnl
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_LIBS=$LIBS
+LDFLAGS="$1 $LDFLAGS"
+LIBS="$LIBS -ldpdk $2"
+
+AC_MSG_CHECKING([for rte_eal_init in -ldpdk $2])
+AC_LINK_IFELSE([AC_LANG_CALL([], [rte_eal_init])],
+  [AC_MSG_RESULT([yes])
+   DPDK_LIBS="$1 -ldpdk $3 $2"],
+  [AC_MSG_RESULT([no])])
+
+##
+# Restore old saved variables
+##
+LDFLAGS=$OLD_LDFLAGS
+LIBS=$OLD_LIBS
+])
+
 # ODP_DPDK_CHECK(CPPFLAGS, LDFLAGS, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
 # ---
 # Check for DPDK availability
@@ -23,10 +48,7 @@ AC_DEFUN([ODP_DPDK_CHECK], [dnl
 ##
 # Save and set temporary compilation flags
 ##
-OLD_LDFLAGS=$LDFLAGS
-OLD_LIBS=$LIBS
 OLD_CPPFLAGS=$CPPFLAGS
-LDFLAGS="$2 $LDFLAGS"
 CPPFLAGS="$1 $CPPFLAGS"
 
 dpdk_check_ok=yes
@@ -34,16 +56,21 @@ dpdk_check_ok=yes
 AC_CHECK_HEADERS([rte_config.h], [],
 [dpdk_check_ok=no])
 
-AC_CHECK_LIB([dpdk], [rte_eal_init], [],
-[dpdk_check_ok=no], [-ldl -lpthread -lnuma])
+DPDK_LIBS=""
+_ODP_DPDK_CHECK_LIB([$2])
+AS_IF([test "x$DPDK_LIBS" = "x"],
+  [_ODP_DPDK_CHECK_LIB([$2], [-ldl -lpthread], [-lm])])
+AS_IF([test "x$DPDK_LIBS" = "x"],
+  [_ODP_DPDK_CHECK_LIB([$2], [-ldl -lpthread -lnuma], [-lm])])
+AS_IF([test "x$DPDK_LIBS" = "x"],
+  [dpdk_check_ok=no])
 AS_IF([test "x$dpdk_check_ok" != "xno"],
-  [m4_default([$3], [:])],
+  [AC_SUBST([DPDK_LIBS])
+   m4_default([$3], [:])],
   [m4_default([$4], [:])])
 
 ##
 # Restore old saved variables
 ##
-LDFLAGS=$OLD_LDFLAGS
-LIBS=$OLD_LIBS
 CPPFLAGS=$OLD_CPPFLAGS
 ])
diff --git a/platform/linux-generic/m4/odp_dpdk.m4 
b/platform/linux-generic/m4/odp_dpdk.m4
index 91f76e2de..2beea365c 100644
--- a/platform/linux-generic/m4/odp_dpdk.m4
+++ b/platform/linux-generic/m4/odp_dpdk.m4
@@ -2,12 +2,27 @@
 # Enable DPDK support
 ##
 pktio_dpdk_support=no
+
+AC_ARG_ENABLE([pktio-dpdk],
+ [AS_HELP_STRING([--enable-pktio-dpdk], [enable DPDK support for 
Packet I/O])],
+ [pktio_dpdk_support=$enableval
+  DPDK_PATH=system])
+
 AC_ARG_WITH([dpdk-path],
 [AS_HELP_STRING([--with-dpdk-path=DIR], [path to dpdk build directory])],
 [DPDK_PATH="$withval"
-DPDK_CPPFLAGS="-isystem $DPDK_PATH/include"
-DPDK_LDFLAGS="-L$DPDK_PATH/lib"
-pktio_dpdk_support=yes],[])
+ pktio_dpdk_support=yes],[])
+
+AS_IF([test "x$DPDK_PATH" = "xsystem"],
+  [DPDK_CPPFLAGS="-isystem/usr/include/dpdk"
+   DPDK_LDFLAGS=""
+   DPDK_PMD_PATH="`$CC --print-file-name=librte_pmd_null.a`"
+   DPDK_PMD_PATH="`dirname "$DPDK_PMD_PATH"`"
+   AS_IF([test "x$DPDK_PMD_PATH" = "x"],
+[AC_MSG_FAILURE([Could not locate system DPDK PMD directory])])],
+  [DPDK_CPPFLAGS="-isystem $DPDK_PATH/include"
+   DPDK_LDFLAGS="-L$DPDK_PATH/lib"
+   DPDK_PMD_PATH="$DPDK_PATH/lib"])
 
 ##
 # Enable zero-copy DPDK pktio
@@ -30,14 +45,17 @@ then
 

[lng-odp] [PATCH v2 5/6] linux-gen: dpdk: cast addresses to uintptr_t rather than uint64_t

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

This is to remove the following error:

pktio/dpdk.c: In function ‘mbuf_data_off’:
pktio/dpdk.c:126:9: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  return (uint64_t)pkt_hdr->buf_hdr.seg[0].data -
 ^
pktio/dpdk.c:127:4: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
(uint64_t)mbuf->buf_addr;

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 platform/linux-generic/pktio/dpdk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index fa73cb93d..705a7968c 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -123,8 +123,8 @@ static unsigned cache_size(uint32_t num)
 static inline uint16_t mbuf_data_off(struct rte_mbuf *mbuf,
 odp_packet_hdr_t *pkt_hdr)
 {
-   return (uint64_t)pkt_hdr->buf_hdr.seg[0].data -
-   (uint64_t)mbuf->buf_addr;
+   return (uintptr_t)pkt_hdr->buf_hdr.seg[0].data -
+   (uintptr_t)mbuf->buf_addr;
 }
 
 /**

[lng-odp] [PATCH v2 6/6] travis: also use DPDK when doing cross-compile tests

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Compile and use DPDK when doing cross-compilation tests. This enables us
to test that pktio/dpdk.c works on non-x86 targets.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 .travis.yml | 50 ++
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index b5c1b6417..dab868129 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -98,7 +98,8 @@ before_install:
   else
 sudo -E apt-get -y --no-install-suggests 
--no-install-recommends --force-yes install g++-"$CROSS_GNU_TYPE" ;
   fi ;
-  sudo -E apt-get -y --no-install-suggests 
--no-install-recommends --force-yes install libc6-dev:"$CROSS_ARCH" 
libssl-dev:"$CROSS_ARCH" zlib1g-dev:"$CROSS_ARCH" libconfig-dev:"$CROSS_ARCH" 
libstdc++-4.8-dev:"$CROSS_ARCH";
+  sudo -E apt-get -y --no-install-suggests 
--no-install-recommends --force-yes install libc6-dev:"$CROSS_ARCH" 
libssl-dev:"$CROSS_ARCH" zlib1g-dev:"$CROSS_ARCH" libconfig-dev:"$CROSS_ARCH" 
libstdc++-4.8-dev:"$CROSS_ARCH" libpcap0.8-dev:"$CROSS_ARCH" ;
+  [ "$CROSS_ARCH" = "armhf" ] || sudo -E apt-get -y 
--no-install-suggests --no-install-recommends --force-yes install 
libnuma-dev:"$CROSS_ARCH";
   export 
PKG_CONFIG_PATH=/usr/lib/${CROSS_MULTIARCH}/pkgconfig:/usr/${CROSS_MULTIARCH}/lib/pkgconfig
 ;
   fi
 - if [ "${CC#clang}" != "${CC}" ] ;
@@ -106,16 +107,24 @@ before_install:
 if [ -n "$CROSS_ARCH" ] ;
 then
 export CC="${CC} --target=$CROSS_GNU_TYPE" ;
+if [ "$CROSS_ARCH" = "i386" ] ;
+then
+DPDK_CFLAGS="-m32" ;
+else
+DPDK_CROSS="$CROSS_GNU_TYPE-" ;
+fi
 fi ;
 export CXX="${CC/clang/clang++}";
   elif [ "$CROSS_ARCH" = "i386" ] ;
   then
 export CC="gcc -m32" ;
 export CXX="g++ -m32" ;
+DPDK_CFLAGS="-m32" ;
   elif [ -n "$CROSS_ARCH" ] ;
   then
 export CC="$CROSS_GNU_TYPE"-gcc ;
 export CXX="$CROSS_GNU_TYPE"-g++ ;
+DPDK_CROSS="$CROSS_GNU_TYPE-" ;
   fi
 - if test ! -L /usr/lib/ccache/${CC%% *} ; then sudo ln -s -t 
/usr/lib/ccache/ `which ${CC%% *}` ; fi
 - ccache -s
@@ -173,21 +182,48 @@ install:
   if [ "${CACHED_DPDK_VERS}" != "${DPDK_VERS}" ]; then
 rm -rf dpdk
   fi
-- TARGET=${TARGET:-"x86_64-native-linuxapp-gcc"}
 - |
-  if [ -z "$CROSS_ARCH" -a ! -f "dpdk/${TARGET}/lib/libdpdk.a" ]; then
+  case "$CROSS_ARCH" in
+"arm64")
+  TARGET="arm64-armv8a-linuxapp-gcc"
+  ;;
+"armhf")
+  TARGET="arm-armv7a-linuxapp-gcc"
+  ;;
+"i386")
+  TARGET="i686-native-linuxapp-gcc"
+  ;;
+"")
+  TARGET="x86_64-native-linuxapp-gcc"
+  DPDK_MACHINE=snb
+  ;;
+  esac
+- |
+  if [ -n "$TARGET" -a ! -f "dpdk/${TARGET}/lib/libdpdk.a" ]; then
 git -c advice.detachedHead=false clone -q --depth=1 
--single-branch --branch=v${DPDK_VERS} http://dpdk.org/git/dpdk dpdk
 pushd dpdk
 git log --oneline --decorate
+echo $CC
+# AArch64 && ARMv7 fixup
+sed -i -e 's/40900/40800/g' 
lib/librte_eal/common/include/arch/arm/rte_vect.h
+sed -i -e 's/!(/!(defined(__arm__) \&\& defined(__clang__) || /g' 
lib/librte_eal/common/include/arch/arm/rte_byteorder.h
+sed -i -e 's/__GNUC__/defined(__arm__) \&\& defined(__clang__) || 
__GNUC__/' lib/librte_eal/common/include/generic/rte_byteorder.h
 make config T=${TARGET} O=${TARGET}
 pushd ${TARGET}
 sed -ri 's,(CONFIG_RTE_LIBRTE_PMD_PCAP=).*,\1y,' .config
 cat .config |grep RTE_MACHINE
-sed -ri 's,(CONFIG_RTE_MACHINE=).*,\1"snb",' .config
+if test -n "${DPDK_MACHINE}" ; then
+  sed -ri 's,(CONFIG_RTE_MACHINE=).*,\1"'${DPDK_MACHINE}'",' 
.config
+fi
+if test -n "$CROSS_ARCH" ; then
+  sed -ri -e 's,(CONFIG_RTE_EAL_IGB_UIO=).*,\1n,' .config
+  sed -ri -e 's,(CONFIG_RTE_KNI_KMOD=).*,\1n,' .config
+fi
 popd
-make install 

[lng-odp] [PATCH v2 1/6] configure: separate common DPDK check to odp_dpdk.m4

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Separate DPDK macros to top-level file so that they can be reused by
other implementations (like ODP-DPDK).

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 m4/odp_dpdk.m4| 49 +++
 platform/linux-generic/m4/odp_dpdk.m4 | 35 +
 2 files changed, 56 insertions(+), 28 deletions(-)
 create mode 100644 m4/odp_dpdk.m4

diff --git a/m4/odp_dpdk.m4 b/m4/odp_dpdk.m4
new file mode 100644
index 0..636170a7f
--- /dev/null
+++ b/m4/odp_dpdk.m4
@@ -0,0 +1,49 @@
+# ODP_DPDK_PMDS(DPDK_DRIVER_PATH)
+# ---
+# Build a list of DPDK PMD drivers in DPDK_PMDS variable
+AC_DEFUN([ODP_DPDK_PMDS], [dnl
+AS_VAR_SET([DPDK_PMDS], [-Wl,--whole-archive,])
+for filename in "$1"/librte_pmd_*.a; do
+cur_driver=`basename "$filename" .a | sed -e 's/^lib//'`
+# rte_pmd_nfp has external dependencies which break linking
+if test "$cur_driver" = "rte_pmd_nfp"; then
+echo "skip linking rte_pmd_nfp"
+else
+AS_VAR_APPEND([DPDK_PMDS], [-l$cur_driver,])
+fi
+done
+AS_VAR_APPEND([DPDK_PMDS], [--no-whole-archive])
+AC_SUBST([DPDK_PMDS])
+])
+
+# ODP_DPDK_CHECK(CPPFLAGS, LDFLAGS, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
+# ---
+# Check for DPDK availability
+AC_DEFUN([ODP_DPDK_CHECK], [dnl
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_LIBS=$LIBS
+OLD_CPPFLAGS=$CPPFLAGS
+LDFLAGS="$2 $LDFLAGS"
+CPPFLAGS="$1 $CPPFLAGS"
+
+dpdk_check_ok=yes
+
+AC_CHECK_HEADERS([rte_config.h], [],
+[dpdk_check_ok=no])
+
+AC_CHECK_LIB([dpdk], [rte_eal_init], [],
+[dpdk_check_ok=no], [-ldl -lpthread -lnuma])
+AS_IF([test "x$dpdk_check_ok" != "xno"],
+  [m4_default([$3], [:])],
+  [m4_default([$4], [:])])
+
+##
+# Restore old saved variables
+##
+LDFLAGS=$OLD_LDFLAGS
+LIBS=$OLD_LIBS
+CPPFLAGS=$OLD_CPPFLAGS
+])
diff --git a/platform/linux-generic/m4/odp_dpdk.m4 
b/platform/linux-generic/m4/odp_dpdk.m4
index 1e8fa2de9..ba0fdc935 100644
--- a/platform/linux-generic/m4/odp_dpdk.m4
+++ b/platform/linux-generic/m4/odp_dpdk.m4
@@ -3,9 +3,10 @@
 ##
 pktio_dpdk_support=no
 AC_ARG_WITH([dpdk-path],
-AS_HELP_STRING([--with-dpdk-path=DIR   path to dpdk build directory]),
+[AS_HELP_STRING([--with-dpdk-path=DIR], [path to dpdk build directory])],
 [DPDK_PATH="$withval"
 DPDK_CPPFLAGS="-msse4.2 -isystem $DPDK_PATH/include"
+DPDK_LDFLAGS="-L$DPDK_PATH/lib"
 pktio_dpdk_support=yes],[])
 
 ##
@@ -13,17 +14,11 @@ AS_HELP_STRING([--with-dpdk-path=DIR   path to dpdk build 
directory]),
 ##
 zero_copy=0
 AC_ARG_ENABLE([dpdk-zero-copy],
-[  --enable-dpdk-zero-copy  enable experimental zero-copy DPDK pktio mode],
+[AS_HELP_STRING([--enable-dpdk-zero-copy], [enable experimental zero-copy 
DPDK pktio mode])],
 [if test x$enableval = xyes; then
 zero_copy=1
 fi])
 
-##
-# Save and set temporary compilation flags
-##
-OLD_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$DPDK_CPPFLAGS $CPPFLAGS"
-
 ##
 # Check for DPDK availability
 #
@@ -32,37 +27,21 @@ CPPFLAGS="$DPDK_CPPFLAGS $CPPFLAGS"
 ##
 if test x$pktio_dpdk_support = xyes
 then
-AC_CHECK_HEADERS([rte_config.h], [],
-[AC_MSG_FAILURE(["can't find DPDK header"])])
+ODP_DPDK_CHECK([$DPDK_CPPFLAGS], [$DPDK_LDFLAGS], [],
+   [AC_MSG_FAILURE([can't find DPDK])])
 
-AS_VAR_SET([DPDK_PMDS], [-Wl,--whole-archive,])
-for filename in "$DPDK_PATH"/lib/librte_pmd_*.a; do
-cur_driver=`basename "$filename" .a | sed -e 's/^lib//'`
-# rte_pmd_nfp has external dependencies which break linking
-if test "$cur_driver" = "rte_pmd_nfp"; then
-echo "skip linking rte_pmd_nfp"
-else
-AS_VAR_APPEND([DPDK_PMDS], [-l$cur_driver,])
-fi
-

[lng-odp] [PATCH v2 2/6] linux-gen: apply -msse4.2 only in x86 case

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Flag -msse4.2 should be used only for i?86/x86_64 targets, it does not
make sense for any other target.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
 platform/linux-generic/Makefile.am| 6 ++
 platform/linux-generic/m4/odp_dpdk.m4 | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 9cb501cf3..bbe6a21c2 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -14,6 +14,12 @@ AM_CPPFLAGS +=  $(OPENSSL_CPPFLAGS)
 AM_CPPFLAGS +=  $(DPDK_CPPFLAGS)
 AM_CPPFLAGS +=  $(NETMAP_CPPFLAGS)
 
+if PKTIO_DPDK
+if ARCH_IS_X86
+AM_CFLAGS += -msse4.2
+endif
+endif
+
 odpincludedir= $(includedir)/odp
 odpinclude_HEADERS = \
  include/odp/visibility_begin.h \
diff --git a/platform/linux-generic/m4/odp_dpdk.m4 
b/platform/linux-generic/m4/odp_dpdk.m4
index ba0fdc935..91f76e2de 100644
--- a/platform/linux-generic/m4/odp_dpdk.m4
+++ b/platform/linux-generic/m4/odp_dpdk.m4
@@ -5,7 +5,7 @@ pktio_dpdk_support=no
 AC_ARG_WITH([dpdk-path],
 [AS_HELP_STRING([--with-dpdk-path=DIR], [path to dpdk build directory])],
 [DPDK_PATH="$withval"
-DPDK_CPPFLAGS="-msse4.2 -isystem $DPDK_PATH/include"
+DPDK_CPPFLAGS="-isystem $DPDK_PATH/include"
 DPDK_LDFLAGS="-L$DPDK_PATH/lib"
 pktio_dpdk_support=yes],[])
 

[lng-odp] [PATCH v2 0/6] enhance DPDK integration

[Github ODP bot]

support DPDK 16.11
support DPDK on non-x86 platforms
support building using system DPDK

github
/** Email created from pull request 321 (lumag:dpdk-system-master)
 ** https://github.com/Linaro/odp/pull/321
 ** Patch: https://github.com/Linaro/odp/pull/321.patch
 ** Base sha: 5329e5211c447b9b823149baf76112eedfeb07fb
 ** Merge commit sha: 280c62aa5d2ea89ff05e376a74d7c6bbd29f002f
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 119 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 20 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 116 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 70 lines checked


to_send-p-003.patch has no obvious style problems and is ready for submission.
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
#14: 
pktio/dpdk.c:126:9: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]

total: 0 errors, 1 warnings, 0 checks, 10 lines checked


to_send-p-004.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 0 checks, 98 lines checked


to_send-p-005.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

On 12/04/17 17:03, Bogdan Pricope wrote:
> On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:
> 
> ODP_REPO='https://github.com/muvarov/odp'
> ODP_BRANCH='api-next'
> 
> 
> On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:
> 
> ODP_REPO='https://github.com/muvarov/odp'
> ODP_BRANCH='devel/api-next_shsum'
> 
> 
> or are you referring to other test?
> 

here I used l2fwd which works:
https://lng.validation.linaro.org/scheduler/job/23246.1

now I think that I did not apply patches cleanly to I re-applied them
and testing now:
https://lng.validation.linaro.org/scheduler/job/23255.1

If not I will comment out bad check summ drop in generator and do next
debug...

Maxim.


> 
> On 4 December 2017 at 15:53, Maxim Uvarov  wrote:
>>
>>
>> On 4 December 2017 at 15:11, Bogdan Pricope 
>> wrote:
>>>
>>> You need to put 313 on TX side (not RX).
>>
>>
>>
>> both rx and tx have patches from 313. l2fwd works on recv side. Generator
>> does not work.
>>
>> Maxim.
>>
>>
>>>
>>>
>>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>>>  wrote:
 Is the DPDK version 17.08 ? Other versions might not work properly.



 -Petri



 From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
 Sent: Monday, December 04, 2017 1:10 PM
 To: Savolainen, Petri (Nokia - FI/Espoo) 
 Cc: Bogdan Pricope ; lng-odp-forward
 


 Subject: Re: [lng-odp] odp dpdk



 313 does not work also:

 https://lng.validation.linaro.org/scheduler/job/23242.1

 I will replace RX side to l2fwd and see that will be there.

 Maxim.





 On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
  wrote:

 Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
 fix
 checksum insert for 10/40GE Intel NICs.

 -Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Bogdan Pricope
> Sent: Monday, December 04, 2017 12:21 PM
> To: Maxim Uvarov 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] odp dpdk
>
> I suspect this is actually caused by csum issue in TX side: on RX,
> socket pktio does not validate csum (and accept the packets) but on
> dpdk pktio the csum is validated and packets are dropped.
>
> I am not seeing this in my setup because default txq_flags for igb
> driver (1G interface) is
>
> .txq_flags = 0
>
> while for ixgbe (10G interface) is:
>
> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> ETH_TXQ_FLAGS_NOOFFLOADS,
>
>
> /B
>
>
>
>
> On 1 December 2017 at 23:47, Maxim Uvarov 
> wrote:
>>
>> Looking to dpdk pktio support and generator. It looks like receive
>> part
>> is broken. If for receive I use sockets it works well but receive
>> with
>> dpdk does not get any packets. For both master and api-next. Can
>> somebody confirm please that it's so. Lava is not supper friendly to
>> debug issue.
>>
>>
>> 1. Recv
>> odp_generator -I 0 -m r -c 0x4
>>
>> https://lng.validation.linaro.org/scheduler/job/23206.1
>> Network devices using DPDK-compatible driver
>> 
>> :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> drv=igb_uio unused=
>>
>>
>>
>> 2. Send
>> odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
>> 38:ea:a7:93:83:a0
>> --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> 5000 -f 5001 -n 8
>>
>> https://lng.validation.linaro.org/scheduler/job/23206.0
>>
>> Thank you,
>> Maxim.


>>
>>

Re: [lng-odp] odp dpdk

[Bogdan Pricope]

On TX (https://lng.validation.linaro.org/scheduler/job/23252.0) I see:

ODP_REPO='https://github.com/muvarov/odp'
ODP_BRANCH='api-next'


On RX (https://lng.validation.linaro.org/scheduler/job/23252.1) I see:

ODP_REPO='https://github.com/muvarov/odp'
ODP_BRANCH='devel/api-next_shsum'


or are you referring to other test?


On 4 December 2017 at 15:53, Maxim Uvarov  wrote:
>
>
> On 4 December 2017 at 15:11, Bogdan Pricope 
> wrote:
>>
>> You need to put 313 on TX side (not RX).
>
>
>
> both rx and tx have patches from 313. l2fwd works on recv side. Generator
> does not work.
>
> Maxim.
>
>
>>
>>
>> On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>> > Is the DPDK version 17.08 ? Other versions might not work properly.
>> >
>> >
>> >
>> > -Petri
>> >
>> >
>> >
>> > From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>> > Sent: Monday, December 04, 2017 1:10 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) 
>> > Cc: Bogdan Pricope ; lng-odp-forward
>> > 
>> >
>> >
>> > Subject: Re: [lng-odp] odp dpdk
>> >
>> >
>> >
>> > 313 does not work also:
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23242.1
>> >
>> > I will replace RX side to l2fwd and see that will be there.
>> >
>> > Maxim.
>> >
>> >
>> >
>> >
>> >
>> > On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>> >  wrote:
>> >
>> > Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
>> > fix
>> > checksum insert for 10/40GE Intel NICs.
>> >
>> > -Petri
>> >
>> >
>> >> -Original Message-
>> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> >> Bogdan Pricope
>> >> Sent: Monday, December 04, 2017 12:21 PM
>> >> To: Maxim Uvarov 
>> >> Cc: lng-odp-forward 
>> >> Subject: Re: [lng-odp] odp dpdk
>> >>
>> >> I suspect this is actually caused by csum issue in TX side: on RX,
>> >> socket pktio does not validate csum (and accept the packets) but on
>> >> dpdk pktio the csum is validated and packets are dropped.
>> >>
>> >> I am not seeing this in my setup because default txq_flags for igb
>> >> driver (1G interface) is
>> >>
>> >> .txq_flags = 0
>> >>
>> >> while for ixgbe (10G interface) is:
>> >>
>> >> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> >> ETH_TXQ_FLAGS_NOOFFLOADS,
>> >>
>> >>
>> >> /B
>> >>
>> >>
>> >>
>> >>
>> >> On 1 December 2017 at 23:47, Maxim Uvarov 
>> >> wrote:
>> >> >
>> >> > Looking to dpdk pktio support and generator. It looks like receive
>> >> > part
>> >> > is broken. If for receive I use sockets it works well but receive
>> >> > with
>> >> > dpdk does not get any packets. For both master and api-next. Can
>> >> > somebody confirm please that it's so. Lava is not supper friendly to
>> >> > debug issue.
>> >> >
>> >> >
>> >> > 1. Recv
>> >> > odp_generator -I 0 -m r -c 0x4
>> >> >
>> >> > https://lng.validation.linaro.org/scheduler/job/23206.1
>> >> > Network devices using DPDK-compatible driver
>> >> > 
>> >> > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> >> > drv=igb_uio unused=
>> >> >
>> >> >
>> >> >
>> >> > 2. Send
>> >> > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
>> >> > 38:ea:a7:93:83:a0
>> >> > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> >> > 5000 -f 5001 -n 8
>> >> >
>> >> > https://lng.validation.linaro.org/scheduler/job/23206.0
>> >> >
>> >> > Thank you,
>> >> > Maxim.
>> >
>> >
>
>

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

platform/linux-generic/odp_packet.c
line 34
@@ -944,6 +949,45 @@ odp_event_t odp_packet_to_event(odp_packet_t pkt)
return (odp_event_t)buffer_handle(packet_hdr(pkt));
 }
 
+void odp_packet_from_event_multi(odp_packet_t pkt[], const odp_event_t ev[],
+int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++)
+   pkt[i] = odp_packet_from_event(ev[i]);
+}
+
+void odp_packet_to_event_multi(const odp_packet_t pkt[], odp_event_t ev[],
+  int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++)
+   ev[i] = odp_packet_to_event(pkt[i]);
+}
+
+int odp_event_filter_packet(const odp_event_t event[],


Comment:
Yes.

> Petri Savolainen(psavol) wrote:
> Schedulers do not work that way. You cannot peak into head of schedule queue 
> and ignore non-packets and just select packets. Scheduler returns N events.
> 
> Also storing non-packets locally (inside scheduler SW) would not help, since 
> application could easily starve non-packets by polling those too seldom. 


>> Petri Savolainen(psavol) wrote:
>> The same answer. Improved implementation efficiency and cleaner application 
>> code.


>>> Petri Savolainen(psavol) wrote:
>>> pkts = odp_schedule_multi(NULL, ODP_SCHED_NO_WAIT, ev_tbl, MAX_PKT_BURST);
>>> 
>>> if (pkts <= 0)
>>> continue;
>>> 
>>> for (i = 0; i < pkts; i++)
>>> pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);
>>> 
>>> VS.
>>> 
>>> odp_packet_from_event_multi(pkt_tlb, ev_tbl, num_pkts);
>>> 
>>> 1) Single call vs. many calls makes difference when not inlined (ABI 
>>> compat).
>>> 2) This is not only cast, it's also a copy of the handle. Implementation 
>>> may be vectorized, for loop unrolled, etc.
>>> 3) Depending on implementation the conversion may include additional things 
>>> to the handle copy: extra checks, post processing of the event, etc 
>>> HW/implementation specific tricks. Which would open more optimization 
>>> opportunity in addition to load+store.
>>> 4) Application code is cleaner 


 Petri Savolainen(psavol) wrote:
 The same answer. Improved implementation efficiency.


> Petri Savolainen(psavol) wrote:
> " Handles are outputted to both arrays in the same order those are stored 
> in 'event' array. "
> 
> Events are not reordered. Packets are copied into packet[] and 
> non-packets into remain[]. Both arrays maintain p and np order of the 
> original array. Also original array is not modified.
> 
> packet[] = p1, p2, p3
> remain[] = np1, np2


>> muvarov wrote
>> why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need 
>> only packets then do scheduling only for packets. That has to be more 
>> fast than get all and then filer them.


>>> muvarov wrote
>>> is it valid case when odp_schedule() returns mixed events types? I.e. 
>>> some packets, some timeouts, some packets from one pool and packets 
>>> from other pool.


 Petri Savolainen(psavol) wrote:
 Application knows the configuration, so it knows when all packets 
 (e.g. from certain queue/pkt input/etc) are allocated from the same 
 pool. When that's the case, free implementation can be more efficient 
 (than today) as it does not have to access/check/sort all packets of 
 the burst. It can just free all into the pool of the first packet. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Doesn't this reorder events? As described consider an array of events 
> that consist of packets (p) and non-packets (np).
> 
> With an input array of events: np1, p1, np2, p2, p3 as described 
> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array 
> would contain p1, p2, p3, and the `remain[]` event would contain np1, 
> np2.  Is that behavior what we want?


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Even with the `odp_event_type_multi()` API semantics, it's still not 
>> clear why this is needed. Given that `odp_packet_from_event()` is 
>> likely just a cast there doesn't seem to be a great deal to be 
>> gained by having a `multi` version of this which can't be easily 
>> inlined away.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Again since `odp_packet_to_event()` is likely to be just a cast 
>>> that can be inlined away it's not clear why a `multi` version is 
>>> needed.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Again, it's not clear why this is needed. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Not clear why this is needed. How does an application determine 
> this more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154608767
updated_at 

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/event.h
line 54
@@ -141,6 +142,27 @@ odp_event_type_t odp_event_types(odp_event_t event,
 int odp_event_type_multi(const odp_event_t event[], int num,
 odp_event_type_t *type);
 
+/**
+ * Filter and convert packet events
+ *
+ * Checks event type of all input events, converts all packet events and 
outputs
+ * packet handles. Returns the number packet handles outputted. Outputs the
+ * remaining, non-packet event handles to 'remain' array. Handles are outputted
+ * to both arrays in the same order those are stored in 'event' array. Both
+ * output arrays must fit 'num' elements.
+ *
+ * @param  eventArray of event handles
+ * @param[out] packet   Packet handle array for output
+ * @param[out] remain   Event handle array for output of remaining, non-packet
+ *  events
+ * @param  num  Number of events (> 0)
+ *
+ * @return Number of packets outputted (0 ... num)
+ */
+int odp_event_filter_packet(const odp_event_t event[],
+   odp_packet_t packet[],
+   odp_event_t remain[], int num);


Comment:
Schedulers do not work that way. You cannot peak into head of schedule queue 
and ignore non-packets and just select packets. Scheduler returns N events.

Also storing non-packets locally (inside scheduler SW) would not help, since 
application could easily starve non-packets by polling those too seldom. 

> Petri Savolainen(psavol) wrote:
> The same answer. Improved implementation efficiency and cleaner application 
> code.


>> Petri Savolainen(psavol) wrote:
>> pkts = odp_schedule_multi(NULL, ODP_SCHED_NO_WAIT, ev_tbl, MAX_PKT_BURST);
>> 
>> if (pkts <= 0)
>>  continue;
>> 
>> for (i = 0; i < pkts; i++)
>>  pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);
>> 
>> VS.
>> 
>> odp_packet_from_event_multi(pkt_tlb, ev_tbl, num_pkts);
>> 
>> 1) Single call vs. many calls makes difference when not inlined (ABI compat).
>> 2) This is not only cast, it's also a copy of the handle. Implementation may 
>> be vectorized, for loop unrolled, etc.
>> 3) Depending on implementation the conversion may include additional things 
>> to the handle copy: extra checks, post processing of the event, etc 
>> HW/implementation specific tricks. Which would open more optimization 
>> opportunity in addition to load+store.
>> 4) Application code is cleaner 


>>> Petri Savolainen(psavol) wrote:
>>> The same answer. Improved implementation efficiency.


 Petri Savolainen(psavol) wrote:
 " Handles are outputted to both arrays in the same order those are stored 
 in 'event' array. "
 
 Events are not reordered. Packets are copied into packet[] and non-packets 
 into remain[]. Both arrays maintain p and np order of the original array. 
 Also original array is not modified.
 
 packet[] = p1, p2, p3
 remain[] = np1, np2


> muvarov wrote
> why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need 
> only packets then do scheduling only for packets. That has to be more 
> fast than get all and then filer them.


>> muvarov wrote
>> is it valid case when odp_schedule() returns mixed events types? I.e. 
>> some packets, some timeouts, some packets from one pool and packets from 
>> other pool.


>>> Petri Savolainen(psavol) wrote:
>>> Application knows the configuration, so it knows when all packets (e.g. 
>>> from certain queue/pkt input/etc) are allocated from the same pool. 
>>> When that's the case, free implementation can be more efficient (than 
>>> today) as it does not have to access/check/sort all packets of the 
>>> burst. It can just free all into the pool of the first packet. 


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Doesn't this reorder events? As described consider an array of events 
 that consist of packets (p) and non-packets (np).
 
 With an input array of events: np1, p1, np2, p2, p3 as described 
 `odp_event_filter_packet()` would have RC = 3, the `packet[]` array 
 would contain p1, p2, p3, and the `remain[]` event would contain np1, 
 np2.  Is that behavior what we want?


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Even with the `odp_event_type_multi()` API semantics, it's still not 
> clear why this is needed. Given that `odp_packet_from_event()` is 
> likely just a cast there doesn't seem to be a great deal to be gained 
> by having a `multi` version of this which can't be easily inlined 
> away.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Again since `odp_packet_to_event()` is likely to be just a cast that 
>> can be inlined away it's not clear why a `multi` version is needed.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Again, it's not clear why this 

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/packet.h
line 49
@@ -244,6 +267,16 @@ odp_packet_t odp_packet_from_event(odp_event_t ev);
  */
 odp_event_t odp_packet_to_event(odp_packet_t pkt);
 
+/**
+ * Convert multiple packet handles to events
+ *
+ * @param  pkt  Array of packet handles to convert
+ * @param[out] ev   Event handle array for output
+ * @param  num  Number of packets and events
+ */
+void odp_packet_to_event_multi(const odp_packet_t pkt[], odp_event_t ev[],
+  int num);


Comment:
The same answer. Improved implementation efficiency and cleaner application 
code.

> Petri Savolainen(psavol) wrote:
> pkts = odp_schedule_multi(NULL, ODP_SCHED_NO_WAIT, ev_tbl, MAX_PKT_BURST);
> 
> if (pkts <= 0)
>   continue;
> 
> for (i = 0; i < pkts; i++)
>   pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);
> 
> VS.
> 
> odp_packet_from_event_multi(pkt_tlb, ev_tbl, num_pkts);
> 
> 1) Single call vs. many calls makes difference when not inlined (ABI compat).
> 2) This is not only cast, it's also a copy of the handle. Implementation may 
> be vectorized, for loop unrolled, etc.
> 3) Depending on implementation the conversion may include additional things 
> to the handle copy: extra checks, post processing of the event, etc 
> HW/implementation specific tricks. Which would open more optimization 
> opportunity in addition to load+store.
> 4) Application code is cleaner 


>> Petri Savolainen(psavol) wrote:
>> The same answer. Improved implementation efficiency.


>>> Petri Savolainen(psavol) wrote:
>>> " Handles are outputted to both arrays in the same order those are stored 
>>> in 'event' array. "
>>> 
>>> Events are not reordered. Packets are copied into packet[] and non-packets 
>>> into remain[]. Both arrays maintain p and np order of the original array. 
>>> Also original array is not modified.
>>> 
>>> packet[] = p1, p2, p3
>>> remain[] = np1, np2


 muvarov wrote
 why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need 
 only packets then do scheduling only for packets. That has to be more fast 
 than get all and then filer them.


> muvarov wrote
> is it valid case when odp_schedule() returns mixed events types? I.e. 
> some packets, some timeouts, some packets from one pool and packets from 
> other pool.


>> Petri Savolainen(psavol) wrote:
>> Application knows the configuration, so it knows when all packets (e.g. 
>> from certain queue/pkt input/etc) are allocated from the same pool. When 
>> that's the case, free implementation can be more efficient (than today) 
>> as it does not have to access/check/sort all packets of the burst. It 
>> can just free all into the pool of the first packet. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Doesn't this reorder events? As described consider an array of events 
>>> that consist of packets (p) and non-packets (np).
>>> 
>>> With an input array of events: np1, p1, np2, p2, p3 as described 
>>> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array 
>>> would contain p1, p2, p3, and the `remain[]` event would contain np1, 
>>> np2.  Is that behavior what we want?


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Even with the `odp_event_type_multi()` API semantics, it's still not 
 clear why this is needed. Given that `odp_packet_from_event()` is 
 likely just a cast there doesn't seem to be a great deal to be gained 
 by having a `multi` version of this which can't be easily inlined away.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Again since `odp_packet_to_event()` is likely to be just a cast that 
> can be inlined away it's not clear why a `multi` version is needed.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Again, it's not clear why this is needed. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Not clear why this is needed. How does an application determine 
>>> this more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154607274
updated_at 2017-12-04 10:18:22

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/packet.h
line 32
@@ -235,6 +246,18 @@ int odp_packet_reset(odp_packet_t pkt, uint32_t len);
  */
 odp_packet_t odp_packet_from_event(odp_event_t ev);
 
+/**
+ * Convert multiple packet events to packet handles
+ *
+ * All events must be of type ODP_EVENT_PACKET.
+ *
+ * @param[out] pkt  Packet handle array for output
+ * @param  ev   Array of event handles to convert
+ * @param  num  Number of packets and events
+ */
+void odp_packet_from_event_multi(odp_packet_t pkt[], const odp_event_t ev[],
+int num);


Comment:
pkts = odp_schedule_multi(NULL, ODP_SCHED_NO_WAIT, ev_tbl, MAX_PKT_BURST);

if (pkts <= 0)
continue;

for (i = 0; i < pkts; i++)
pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);

VS.

odp_packet_from_event_multi(pkt_tlb, ev_tbl, num_pkts);

1) Single call vs. many calls makes difference when not inlined (ABI compat).
2) This is not only cast, it's also a copy of the handle. Implementation may be 
vectorized, for loop unrolled, etc.
3) Depending on implementation the conversion may include additional things to 
the handle copy: extra checks, post processing of the event, etc 
HW/implementation specific tricks. Which would open more optimization 
opportunity in addition to load+store.
4) Application code is cleaner 


> Petri Savolainen(psavol) wrote:
> The same answer. Improved implementation efficiency.


>> Petri Savolainen(psavol) wrote:
>> " Handles are outputted to both arrays in the same order those are stored in 
>> 'event' array. "
>> 
>> Events are not reordered. Packets are copied into packet[] and non-packets 
>> into remain[]. Both arrays maintain p and np order of the original array. 
>> Also original array is not modified.
>> 
>> packet[] = p1, p2, p3
>> remain[] = np1, np2


>>> muvarov wrote
>>> why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need 
>>> only packets then do scheduling only for packets. That has to be more fast 
>>> than get all and then filer them.


 muvarov wrote
 is it valid case when odp_schedule() returns mixed events types? I.e. some 
 packets, some timeouts, some packets from one pool and packets from other 
 pool.


> Petri Savolainen(psavol) wrote:
> Application knows the configuration, so it knows when all packets (e.g. 
> from certain queue/pkt input/etc) are allocated from the same pool. When 
> that's the case, free implementation can be more efficient (than today) 
> as it does not have to access/check/sort all packets of the burst. It can 
> just free all into the pool of the first packet. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Doesn't this reorder events? As described consider an array of events 
>> that consist of packets (p) and non-packets (np).
>> 
>> With an input array of events: np1, p1, np2, p2, p3 as described 
>> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array 
>> would contain p1, p2, p3, and the `remain[]` event would contain np1, 
>> np2.  Is that behavior what we want?


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Even with the `odp_event_type_multi()` API semantics, it's still not 
>>> clear why this is needed. Given that `odp_packet_from_event()` is 
>>> likely just a cast there doesn't seem to be a great deal to be gained 
>>> by having a `multi` version of this which can't be easily inlined away.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Again since `odp_packet_to_event()` is likely to be just a cast that 
 can be inlined away it's not clear why a `multi` version is needed.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Again, it's not clear why this is needed. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Not clear why this is needed. How does an application determine this 
>> more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154606661
updated_at 2017-12-04 10:15:48

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/packet.h
line 13
@@ -204,6 +204,17 @@ void odp_packet_free(odp_packet_t pkt);
  */
 void odp_packet_free_multi(const odp_packet_t pkt[], int num);
 
+/**
+ * Free multiple packets to the same pool
+ *
+ * Otherwise like odp_packet_free_multi(), but all packets must be from the
+ * same originating pool.
+ *
+ * @param pkt   Array of packet handles
+ * @param num   Number of packets to free
+ */
+void odp_packet_free_sp(const odp_packet_t pkt[], int num);


Comment:
The same answer. Improved implementation efficiency.

> Petri Savolainen(psavol) wrote:
> " Handles are outputted to both arrays in the same order those are stored in 
> 'event' array. "
> 
> Events are not reordered. Packets are copied into packet[] and non-packets 
> into remain[]. Both arrays maintain p and np order of the original array. 
> Also original array is not modified.
> 
> packet[] = p1, p2, p3
> remain[] = np1, np2


>> muvarov wrote
>> why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need only 
>> packets then do scheduling only for packets. That has to be more fast than 
>> get all and then filer them.


>>> muvarov wrote
>>> is it valid case when odp_schedule() returns mixed events types? I.e. some 
>>> packets, some timeouts, some packets from one pool and packets from other 
>>> pool.


 Petri Savolainen(psavol) wrote:
 Application knows the configuration, so it knows when all packets (e.g. 
 from certain queue/pkt input/etc) are allocated from the same pool. When 
 that's the case, free implementation can be more efficient (than today) as 
 it does not have to access/check/sort all packets of the burst. It can 
 just free all into the pool of the first packet. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Doesn't this reorder events? As described consider an array of events 
> that consist of packets (p) and non-packets (np).
> 
> With an input array of events: np1, p1, np2, p2, p3 as described 
> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array would 
> contain p1, p2, p3, and the `remain[]` event would contain np1, np2.  Is 
> that behavior what we want?


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Even with the `odp_event_type_multi()` API semantics, it's still not 
>> clear why this is needed. Given that `odp_packet_from_event()` is likely 
>> just a cast there doesn't seem to be a great deal to be gained by having 
>> a `multi` version of this which can't be easily inlined away.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Again since `odp_packet_to_event()` is likely to be just a cast that 
>>> can be inlined away it's not clear why a `multi` version is needed.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Again, it's not clear why this is needed. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Not clear why this is needed. How does an application determine this 
> more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154604104
updated_at 2017-12-04 10:05:31

Re: [lng-odp] [PATCH v1] enhance DPDK integration

[Github ODP bot]

Matias Elo(matiaselo) replied on github web page:

platform/linux-generic/pktio/dpdk.c
line 52
@@ -123,8 +123,8 @@ static unsigned cache_size(uint32_t num)
 static inline uint16_t mbuf_data_off(struct rte_mbuf *mbuf,
 odp_packet_hdr_t *pkt_hdr)
 {
-   return (uint64_t)pkt_hdr->buf_hdr.seg[0].data -
-   (uint64_t)mbuf->buf_addr;
+   return (unsigned long)pkt_hdr->buf_hdr.seg[0].data -
+   (unsigned long)mbuf->buf_addr;
 }


Comment:
uintptr_t would be a more suitable type here.

> Matias Elo(matiaselo) wrote:
> If I understood this correctly, a user would have to use 
> '--with-dpdk-path=system' configure option for this to work. Wouldn't a more 
> standard way of doing this be to add e.g. '--enable-dpdk-support' flag in the 
> same manner as with netmap pktio?


https://github.com/Linaro/odp/pull/321#discussion_r154612687
updated_at 2017-12-04 10:42:05

Re: [lng-odp] [PATCH v1] enhance DPDK integration

[Github ODP bot]

Dmitry Eremin-Solenikov(lumag) replied on github web page:

platform/linux-generic/pktio/dpdk.c
line 52
@@ -123,8 +123,8 @@ static unsigned cache_size(uint32_t num)
 static inline uint16_t mbuf_data_off(struct rte_mbuf *mbuf,
 odp_packet_hdr_t *pkt_hdr)
 {
-   return (uint64_t)pkt_hdr->buf_hdr.seg[0].data -
-   (uint64_t)mbuf->buf_addr;
+   return (unsigned long)pkt_hdr->buf_hdr.seg[0].data -
+   (unsigned long)mbuf->buf_addr;
 }


Comment:
ack

> Dmitry Eremin-Solenikov(lumag) wrote:
> Good question. For more or less typical case (non-system DPDK) this would 
> require adding two flags (`--enable-dpdk-support 
> --with-dpdk-path=PATH_TO_DPDK`).


>> Matias Elo(matiaselo) wrote:
>> uintptr_t would be a more suitable type here.


>>> Matias Elo(matiaselo) wrote:
>>> If I understood this correctly, a user would have to use 
>>> '--with-dpdk-path=system' configure option for this to work. Wouldn't a 
>>> more standard way of doing this be to add e.g. '--enable-dpdk-support' flag 
>>> in the same manner as with netmap pktio?


https://github.com/Linaro/odp/pull/321#discussion_r154632254
updated_at 2017-12-04 12:18:04

Re: [lng-odp] [PATCH v1] enhance DPDK integration

[Github ODP bot]

Matias Elo(matiaselo) replied on github web page:

platform/linux-generic/m4/odp_dpdk.m4
@@ -5,9 +5,21 @@ pktio_dpdk_support=no
 AC_ARG_WITH([dpdk-path],
 [AS_HELP_STRING([--with-dpdk-path=DIR], [path to dpdk build directory])],
 [DPDK_PATH="$withval"
+ pktio_dpdk_support=yes],[])
+
+if test "x$DPDK_PATH" = "xsystem" ; then


Comment:
I would suggest going forward with this approach (two separate flags).

If the user only gives '--with-dpdk-path= PATH_TO_DPDK' flag, you can 
presumably handle this in the configure script (so that only one flag has to be 
used).

> Dmitry Eremin-Solenikov(lumag) wrote:
> ack


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Good question. For more or less typical case (non-system DPDK) this would 
>> require adding two flags (`--enable-dpdk-support 
>> --with-dpdk-path=PATH_TO_DPDK`).


>>> Matias Elo(matiaselo) wrote:
>>> uintptr_t would be a more suitable type here.


 Matias Elo(matiaselo) wrote:
 If I understood this correctly, a user would have to use 
 '--with-dpdk-path=system' configure option for this to work. Wouldn't a 
 more standard way of doing this be to add e.g. '--enable-dpdk-support' 
 flag in the same manner as with netmap pktio?


https://github.com/Linaro/odp/pull/321#discussion_r154651878
updated_at 2017-12-04 13:48:41

[lng-odp] [PATCH API-NEXT v1 3/3] api: tm: remove param-in doxygen tag

[Github ODP bot]

From: Petri Savolainen 

All parameters are input only (tag [in]) by default. Output
parameters are better highlighted, when only those are tagged.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 322 (psavol:next-delete-param-in)
 ** https://github.com/Linaro/odp/pull/322
 ** Patch: https://github.com/Linaro/odp/pull/322.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: 1b785f059a15f6ead9fa5d3e8abc30745e0cf954
 **/
 include/odp/api/spec/traffic_mngr.h | 639 ++--
 1 file changed, 318 insertions(+), 321 deletions(-)

diff --git a/include/odp/api/spec/traffic_mngr.h 
b/include/odp/api/spec/traffic_mngr.h
index c9134e8e4..b956f0022 100644
--- a/include/odp/api/spec/traffic_mngr.h
+++ b/include/odp/api/spec/traffic_mngr.h
@@ -484,8 +484,8 @@ typedef struct {
  * odp_tm_requirements_t record before it is first used or assigned to.
  * This is done to allow for vendor specific additions to this record.
  *
- * @param[in] requirements  A pointer to an odp_tm_requirements_t record which
- *  is to be initialized.
+ * @param requirements  A pointer to an odp_tm_requirements_t record which
+ *  is to be initialized.
  */
 void odp_tm_requirements_init(odp_tm_requirements_t *requirements);
 
@@ -495,8 +495,8 @@ void odp_tm_requirements_init(odp_tm_requirements_t 
*requirements);
  * record before it is first used or assigned to.
  * This is done to allow for vendor specific additions to this record.
  *
- * @param[in] egress  A pointer to an odp_tm_egress_t record which
- *is to be initialized.
+ * @param egress  A pointer to an odp_tm_egress_t record which
+ *is to be initialized.
  */
 void odp_tm_egress_init(odp_tm_egress_t *egress);
 
@@ -518,7 +518,7 @@ void odp_tm_egress_init(odp_tm_egress_t *egress);
  *
  * @param[out] capabilities  An array of odp_tm_capabilities_t records to
  *   be filled in.
- * @param[in]  capabilities_size The number of odp_tm_capabilities_t records
+ * @param  capabilities_size The number of odp_tm_capabilities_t records
  *   in the capabilities array.
  * @return   Returns < 0 upon failure.  Returns N > 0,
  *   where N is the maximum number of different
@@ -531,16 +531,16 @@ int odp_tm_capabilities(odp_tm_capabilities_t 
capabilities[],
 
 /** Create/instantiate a TM Packet Scheduling system.
  *
- * @param[in] name  The name to be assigned to this TM system.  Cannot
- *  be NULL, and also must be unique amongst all other
- *  TM system names.
- * @param[in] requirements  The minimum required feature set and limits needed
- *  by the ODP application.
- * @param[in] egressDescribes the single egress "spigot" of this
- *  TM system.
- * @return  Returns ODP_TM_INVALID upon failure, otherwise the
- *  newly created TM system's odp_tm_t handle is
- *  returned.
+ * @param name  The name to be assigned to this TM system.  Cannot
+ *  be NULL, and also must be unique amongst all other
+ *  TM system names.
+ * @param requirements  The minimum required feature set and limits needed
+ *  by the ODP application.
+ * @param egressDescribes the single egress "spigot" of this
+ *  TM system.
+ * @return  Returns ODP_TM_INVALID upon failure, otherwise the
+ *  newly created TM system's odp_tm_t handle is
+ *  returned.
  */
 odp_tm_t odp_tm_create(const char*name,
   odp_tm_requirements_t *requirements,
@@ -558,21 +558,21 @@ odp_tm_t odp_tm_create(const char*name,
  * the existing (built-in or created by odp_tm_create) TM system that best
  * matches the requirements is returned.
  *
- * @param[in] name  If NULL then only uses the requirements parameter 
to
- *  find a closest match, otherwise if the name is
- *  matched by an existing TM system it is returned.
- * @param[in] requirements  Used when the name is NULL (in which case the
- *  closest match is returned) or when the name is
- *  not-NULL, but doesn't match any existing TM system
- *  in which case the requirements is used to find the
- *  FIRST TM system matching exactly these limits.
- * @param[in] egressIf a TM system is found, then this specifies the
- *  egress "spigot" to be associated with this TM
- *  system.
- * @return   

[lng-odp] [PATCH API-NEXT v1 2/3] api: cls: remove param-in doxygen tag

[Github ODP bot]

From: Petri Savolainen 

All parameters are input only (tag [in]) by default. Output
parameters are better highlighted, when only those are tagged.
Also changed tab to spaces inside documentation. Text is more
readable on various editors when tabs and spaces are not mixed.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 322 (psavol:next-delete-param-in)
 ** https://github.com/Linaro/odp/pull/322
 ** Patch: https://github.com/Linaro/odp/pull/322.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: 1b785f059a15f6ead9fa5d3e8abc30745e0cf954
 **/
 include/odp/api/spec/classification.h | 166 --
 1 file changed, 78 insertions(+), 88 deletions(-)

diff --git a/include/odp/api/spec/classification.h 
b/include/odp/api/spec/classification.h
index 16bf3e6ea..4db046fc3 100644
--- a/include/odp/api/spec/classification.h
+++ b/include/odp/api/spec/classification.h
@@ -287,7 +287,7 @@ typedef struct odp_cls_cos_param {
  *
  * Initialize an odp_cls_cos_param_t to its default value for all fields
  *
- * @param param   Address of the odp_cls_cos_param_t to be initialized
+ * @param paramAddress of the odp_cls_cos_param_t to be initialized
  */
 void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
 
@@ -296,10 +296,10 @@ void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
  *
  * Outputs classification capabilities on success.
  *
- * @param[out] capability  Pointer to classification capability structure.
+ * @param[out] capability  Pointer to classification capability structure.
  *
- * @retval 0 on success
- * @retval <0 on failure
+ * @retval  0 on success
+ * @retval <0 on failure
  */
 int odp_cls_capability(odp_cls_capability_t *capability);
 
@@ -308,12 +308,12 @@ int odp_cls_capability(odp_cls_capability_t *capability);
  *
  * The use of class-of-service name is optional. Unique names are not required.
  *
- * @param   nameName of the class-of-service or NULL. Maximum string
- *  length is ODP_COS_NAME_LEN.
- * @param   param   Class-of-service parameters
+ * @param name Name of the class-of-service or NULL. Maximum string
+ * length is ODP_COS_NAME_LEN.
+ * @param paramClass-of-service parameters
  *
- * @retval  Class-of-service handle
- * @retval  ODP_COS_INVALID on failure.
+ * @retval Class-of-service handle
+ * @retval ODP_COS_INVALID on failure.
  *
  * @note ODP_QUEUE_INVALID and ODP_POOL_INVALID are valid values for queue
  * and pool associated with a class of service and when any one of these values
@@ -327,12 +327,11 @@ odp_cos_t odp_cls_cos_create(const char *name, 
odp_cls_cos_param_t *param);
  * based on the packet parameters and hash protocol field configured with the
  * class of service.
  *
- * @param  cos class of service
- * @param  packet  Packet handle
+ * @param cos  class of service
+ * @param packet   Packet handle
  *
- * @retval Returns the queue handle on which this packet will be
- * enqueued.
- * @retval ODP_QUEUE_INVALID for error case
+ * @retval Returns the queue handle on which this packet will be enqueued.
+ * @retval ODP_QUEUE_INVALID for error case
  *
  * @note The packet has to be updated with valid header pointers L2, L3 and L4.
  */
@@ -341,60 +340,54 @@ odp_queue_t odp_cls_hash_result(odp_cos_t cos, 
odp_packet_t packet);
 /**
  * Discard a class-of-service along with all its associated resources
  *
- * @param[in]  cos_id  class-of-service instance.
+ * @param cos_id   class-of-service instance.
  *
- * @retval 0 on success
- * @retval <0 on failure
+ * @retval  0 on success
+ * @retval <0 on failure
  */
 int odp_cos_destroy(odp_cos_t cos_id);
 
 /**
  * Assign a queue for a class-of-service
  *
- * @param[in]  cos_id  class-of-service instance.
+ * @param cos_id   class-of-service instance.
+ * @param queue_id Identifier of a queue where all packets of this specific
+ * class of service will be enqueued.
  *
- * @param[in]  queue_idIdentifier of a queue where all packets
- * of this specific class of service
- * will be enqueued.
- *
- * @retval 0 on success
- * @retval <0 on failure
+ * @retval  0 on success
+ * @retval <0 on failure
  */
 int odp_cos_queue_set(odp_cos_t cos_id, odp_queue_t queue_id);
 
 /**
 * Get the queue associated with the specific class-of-service
 *
-* @param[in]   cos_id  class-of-service instance.
-*
-* @retval  queue_handleQueue handle associated with the
-*  given class-of-service
+* @param cos_idclass-of-service instance.
 *
-* @retval  ODP_QUEUE_INVALID   on 

[lng-odp] [PATCH API-NEXT v1 1/3] api: queue: remove param-in doxygen tag

[Github ODP bot]

From: Petri Savolainen 

All parameters are input only (tag [in]) by default. Output
parameters are better highlighted, when only those are tagged.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 322 (psavol:next-delete-param-in)
 ** https://github.com/Linaro/odp/pull/322
 ** Patch: https://github.com/Linaro/odp/pull/322.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: 1b785f059a15f6ead9fa5d3e8abc30745e0cf954
 **/
 include/odp/api/spec/queue.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
index 73598be06..014d3362e 100644
--- a/include/odp/api/spec/queue.h
+++ b/include/odp/api/spec/queue.h
@@ -309,7 +309,7 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
  * has to take care of them.
  *
  * @param queue   Queue handle
- * @param[in] events Array of event handles
+ * @param events  Array of event handles
  * @param num Number of event handles to enqueue
  *
  * @return Number of events actually enqueued (0 ... num)

Re: [lng-odp] odp dpdk

[Bogdan Pricope]

You need to put 313 on TX side (not RX).

On 4 December 2017 at 13:19, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
> Is the DPDK version 17.08 ? Other versions might not work properly.
>
>
>
> -Petri
>
>
>
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Monday, December 04, 2017 1:10 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bogdan Pricope ; lng-odp-forward
> 
>
>
> Subject: Re: [lng-odp] odp dpdk
>
>
>
> 313 does not work also:
>
> https://lng.validation.linaro.org/scheduler/job/23242.1
>
> I will replace RX side to l2fwd and see that will be there.
>
> Maxim.
>
>
>
>
>
> On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>
> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to fix
> checksum insert for 10/40GE Intel NICs.
>
> -Petri
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Bogdan Pricope
>> Sent: Monday, December 04, 2017 12:21 PM
>> To: Maxim Uvarov 
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] odp dpdk
>>
>> I suspect this is actually caused by csum issue in TX side: on RX,
>> socket pktio does not validate csum (and accept the packets) but on
>> dpdk pktio the csum is validated and packets are dropped.
>>
>> I am not seeing this in my setup because default txq_flags for igb
>> driver (1G interface) is
>>
>> .txq_flags = 0
>>
>> while for ixgbe (10G interface) is:
>>
>> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> ETH_TXQ_FLAGS_NOOFFLOADS,
>>
>>
>> /B
>>
>>
>>
>>
>> On 1 December 2017 at 23:47, Maxim Uvarov  wrote:
>> >
>> > Looking to dpdk pktio support and generator. It looks like receive part
>> > is broken. If for receive I use sockets it works well but receive with
>> > dpdk does not get any packets. For both master and api-next. Can
>> > somebody confirm please that it's so. Lava is not supper friendly to
>> > debug issue.
>> >
>> >
>> > 1. Recv
>> > odp_generator -I 0 -m r -c 0x4
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23206.1
>> > Network devices using DPDK-compatible driver
>> > 
>> > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
>> > drv=igb_uio unused=
>> >
>> >
>> >
>> > 2. Send
>> > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac 38:ea:a7:93:83:a0
>> > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
>> > 5000 -f 5001 -n 8
>> >
>> > https://lng.validation.linaro.org/scheduler/job/23206.0
>> >
>> > Thank you,
>> > Maxim.
>
>

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

313 does not work also:
https://lng.validation.linaro.org/scheduler/job/23242.1


I will replace RX side to l2fwd and see that will be there.

Maxim.


On 4 December 2017 at 13:46, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to
> fix checksum insert for 10/40GE Intel NICs.
>
> -Petri
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Bogdan Pricope
> > Sent: Monday, December 04, 2017 12:21 PM
> > To: Maxim Uvarov 
> > Cc: lng-odp-forward 
> > Subject: Re: [lng-odp] odp dpdk
> >
> > I suspect this is actually caused by csum issue in TX side: on RX,
> > socket pktio does not validate csum (and accept the packets) but on
> > dpdk pktio the csum is validated and packets are dropped.
> >
> > I am not seeing this in my setup because default txq_flags for igb
> > driver (1G interface) is
> >
> > .txq_flags = 0
> >
> > while for ixgbe (10G interface) is:
> >
> > .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> > ETH_TXQ_FLAGS_NOOFFLOADS,
> >
> >
> > /B
> >
> >
> >
> >
> > On 1 December 2017 at 23:47, Maxim Uvarov 
> wrote:
> > >
> > > Looking to dpdk pktio support and generator. It looks like receive part
> > > is broken. If for receive I use sockets it works well but receive with
> > > dpdk does not get any packets. For both master and api-next. Can
> > > somebody confirm please that it's so. Lava is not supper friendly to
> > > debug issue.
> > >
> > >
> > > 1. Recv
> > > odp_generator -I 0 -m r -c 0x4
> > >
> > > https://lng.validation.linaro.org/scheduler/job/23206.1
> > > Network devices using DPDK-compatible driver
> > > 
> > > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> > > drv=igb_uio unused=
> > >
> > >
> > >
> > > 2. Send
> > > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac
> 38:ea:a7:93:83:a0
> > > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
> > > 5000 -f 5001 -n 8
> > >
> > > https://lng.validation.linaro.org/scheduler/job/23206.0
> > >
> > > Thank you,
> > > Maxim.
>

Re: [lng-odp] odp dpdk

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

Maxim, try https://github.com/Linaro/odp/pull/313 It has been tested to fix 
checksum insert for 10/40GE Intel NICs.

-Petri

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Bogdan Pricope
> Sent: Monday, December 04, 2017 12:21 PM
> To: Maxim Uvarov 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] odp dpdk
> 
> I suspect this is actually caused by csum issue in TX side: on RX,
> socket pktio does not validate csum (and accept the packets) but on
> dpdk pktio the csum is validated and packets are dropped.
> 
> I am not seeing this in my setup because default txq_flags for igb
> driver (1G interface) is
> 
> .txq_flags = 0
> 
> while for ixgbe (10G interface) is:
> 
> .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> ETH_TXQ_FLAGS_NOOFFLOADS,
> 
> 
> /B
> 
> 
> 
> 
> On 1 December 2017 at 23:47, Maxim Uvarov  wrote:
> >
> > Looking to dpdk pktio support and generator. It looks like receive part
> > is broken. If for receive I use sockets it works well but receive with
> > dpdk does not get any packets. For both master and api-next. Can
> > somebody confirm please that it's so. Lava is not supper friendly to
> > debug issue.
> >
> >
> > 1. Recv
> > odp_generator -I 0 -m r -c 0x4
> >
> > https://lng.validation.linaro.org/scheduler/job/23206.1
> > Network devices using DPDK-compatible driver
> > 
> > :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> > drv=igb_uio unused=
> >
> >
> >
> > 2. Send
> > odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac 38:ea:a7:93:83:a0
> > --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
> > 5000 -f 5001 -n 8
> >
> > https://lng.validation.linaro.org/scheduler/job/23206.0
> >
> > Thank you,
> > Maxim.

Re: [lng-odp] odp dpdk

[Bogdan Pricope]

I suspect this is actually caused by csum issue in TX side: on RX,
socket pktio does not validate csum (and accept the packets) but on
dpdk pktio the csum is validated and packets are dropped.

I am not seeing this in my setup because default txq_flags for igb
driver (1G interface) is

.txq_flags = 0

while for ixgbe (10G interface) is:

.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,


/B




On 1 December 2017 at 23:47, Maxim Uvarov  wrote:
>
> Looking to dpdk pktio support and generator. It looks like receive part
> is broken. If for receive I use sockets it works well but receive with
> dpdk does not get any packets. For both master and api-next. Can
> somebody confirm please that it's so. Lava is not supper friendly to
> debug issue.
>
>
> 1. Recv
> odp_generator -I 0 -m r -c 0x4
>
> https://lng.validation.linaro.org/scheduler/job/23206.1
> Network devices using DPDK-compatible driver
> 
> :07:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=igb_uio unused=
>
>
>
> 2. Send
> odp_generator -I 0 --srcmac 38:ea:a7:93:98:94 --dstmac 38:ea:a7:93:83:a0
> --srcip 192.168.100.2 --dstip 192.168.100.1 -m u -i 0 -c 0x8 -p 18 -e
> 5000 -f 5001 -n 8
>
> https://lng.validation.linaro.org/scheduler/job/23206.0
>
> Thank you,
> Maxim.

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

muvarov replied on github web page:

platform/linux-generic/odp_packet.c
line 34
@@ -944,6 +949,45 @@ odp_event_t odp_packet_to_event(odp_packet_t pkt)
return (odp_event_t)buffer_handle(packet_hdr(pkt));
 }
 
+void odp_packet_from_event_multi(odp_packet_t pkt[], const odp_event_t ev[],
+int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++)
+   pkt[i] = odp_packet_from_event(ev[i]);
+}
+
+void odp_packet_to_event_multi(const odp_packet_t pkt[], odp_event_t ev[],
+  int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++)
+   ev[i] = odp_packet_to_event(pkt[i]);
+}
+
+int odp_event_filter_packet(const odp_event_t event[],


Comment:
is it valid case when odp_schedule() returns mixed events types? I.e. some 
packets, some timeouts, some packets from one pool and packets from other pool.

> Petri Savolainen(psavol) wrote:
> Application knows the configuration, so it knows when all packets (e.g. from 
> certain queue/pkt input/etc) are allocated from the same pool. When that's 
> the case, free implementation can be more efficient (than today) as it does 
> not have to access/check/sort all packets of the burst. It can just free all 
> into the pool of the first packet. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Doesn't this reorder events? As described consider an array of events that 
>> consist of packets (p) and non-packets (np).
>> 
>> With an input array of events: np1, p1, np2, p2, p3 as described 
>> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array would 
>> contain p1, p2, p3, and the `remain[]` event would contain np1, np2.  Is 
>> that behavior what we want?


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Even with the `odp_event_type_multi()` API semantics, it's still not clear 
>>> why this is needed. Given that `odp_packet_from_event()` is likely just a 
>>> cast there doesn't seem to be a great deal to be gained by having a `multi` 
>>> version of this which can't be easily inlined away.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Again since `odp_packet_to_event()` is likely to be just a cast that can 
 be inlined away it's not clear why a `multi` version is needed.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Again, it's not clear why this is needed. 


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Not clear why this is needed. How does an application determine this 
>> more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154596535
updated_at 2017-12-04 09:36:52

Re: [lng-odp] [PATCH API-NEXT v1] api: multi event functions

[Github ODP bot]

muvarov replied on github web page:

include/odp/api/spec/event.h
line 54
@@ -141,6 +142,27 @@ odp_event_type_t odp_event_types(odp_event_t event,
 int odp_event_type_multi(const odp_event_t event[], int num,
 odp_event_type_t *type);
 
+/**
+ * Filter and convert packet events
+ *
+ * Checks event type of all input events, converts all packet events and 
outputs
+ * packet handles. Returns the number packet handles outputted. Outputs the
+ * remaining, non-packet event handles to 'remain' array. Handles are outputted
+ * to both arrays in the same order those are stored in 'event' array. Both
+ * output arrays must fit 'num' elements.
+ *
+ * @param  eventArray of event handles
+ * @param[out] packet   Packet handle array for output
+ * @param[out] remain   Event handle array for output of remaining, non-packet
+ *  events
+ * @param  num  Number of events (> 0)
+ *
+ * @return Number of packets outputted (0 ... num)
+ */
+int odp_event_filter_packet(const odp_event_t event[],
+   odp_packet_t packet[],
+   odp_event_t remain[], int num);


Comment:
why not odp_schedule_type(ODP_PACKET,  void  *array) ? I.e. if you need only 
packets then do scheduling only for packets. That has to be more fast than get 
all and then filer them.

> muvarov wrote
> is it valid case when odp_schedule() returns mixed events types? I.e. some 
> packets, some timeouts, some packets from one pool and packets from other 
> pool.


>> Petri Savolainen(psavol) wrote:
>> Application knows the configuration, so it knows when all packets (e.g. from 
>> certain queue/pkt input/etc) are allocated from the same pool. When that's 
>> the case, free implementation can be more efficient (than today) as it does 
>> not have to access/check/sort all packets of the burst. It can just free all 
>> into the pool of the first packet. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Doesn't this reorder events? As described consider an array of events that 
>>> consist of packets (p) and non-packets (np).
>>> 
>>> With an input array of events: np1, p1, np2, p2, p3 as described 
>>> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array would 
>>> contain p1, p2, p3, and the `remain[]` event would contain np1, np2.  Is 
>>> that behavior what we want?


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 Even with the `odp_event_type_multi()` API semantics, it's still not clear 
 why this is needed. Given that `odp_packet_from_event()` is likely just a 
 cast there doesn't seem to be a great deal to be gained by having a 
 `multi` version of this which can't be easily inlined away.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> Again since `odp_packet_to_event()` is likely to be just a cast that can 
> be inlined away it's not clear why a `multi` version is needed.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Again, it's not clear why this is needed. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Not clear why this is needed. How does an application determine this 
>>> more efficiently than the implementation would?


https://github.com/Linaro/odp/pull/318#discussion_r154597327
updated_at 2017-12-04 09:40:28

[lng-odp] [PATCH API-NEXT v2 5/5] linux-gen: dpdk: checksum insert enabled flag

[Github ODP bot]

From: Petri Savolainen 

Added interface level flag to optimize checksum insertion
checks. If checksum insertion has not been enabled, further
configuration or packet level checks are not performed.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 313 (psavol:next-pktout-config)
 ** https://github.com/Linaro/odp/pull/313
 ** Patch: https://github.com/Linaro/odp/pull/313.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: e4a122986c2750ffb044994107b385bd8002cbf4
 **/
 platform/linux-generic/include/odp_packet_io_internal.h |  3 ++-
 platform/linux-generic/pktio/dpdk.c | 11 +++
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index f323d5c31..598b1ad50 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -113,7 +113,8 @@ struct pktio_entry {
/* These two locks together lock the whole pktio device */
odp_ticketlock_t rxl;   /**< RX ticketlock */
odp_ticketlock_t txl;   /**< TX ticketlock */
-   int cls_enabled;/**< is classifier enabled */
+   uint8_t cls_enabled;/**< classifier enabled */
+   uint8_t chksum_insert_ena;  /**< pktout checksum offload enabled */
odp_pktio_t handle; /**< pktio handle */
union {
pkt_loop_t pkt_loop;/**< Using loopback for IO */
diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 4a37fe6e5..48c2d0b0e 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -546,6 +546,9 @@ static inline void pkt_set_ol_tx(odp_pktout_config_opt_t 
*pktout_cfg,
odp_bool_t ipv4_chksum_pkt, udp_chksum_pkt, tcp_chksum_pkt;
packet_parser_t *pkt_p = _hdr->p;
 
+   if (pkt_p->l3_offset == ODP_PACKET_OFFSET_INVALID)
+   return;
+
l3_hdr = (void *)(mbuf_data + pkt_p->l3_offset);
 
if (check_proto(l3_hdr, _proto_v4, _proto))
@@ -633,7 +636,7 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
 
odp_packet_copy_to_mem(pkt_table[i], 0, pkt_len, data);
 
-   if (pkt_hdr->p.l3_offset != ODP_PACKET_OFFSET_INVALID) {
+   if (odp_unlikely(pktio_entry->s.chksum_insert_ena)) {
odp_pktout_config_opt_t *pktout_capa =
_entry->s.capa.config.pktout;
 
@@ -748,7 +751,7 @@ static inline int pkt_to_mbuf_zero(pktio_entry_t 
*pktio_entry,
   pkt_hdr->extra_type == PKT_EXTRA_TYPE_DPDK)) {
mbuf_update(mbuf, pkt_hdr, pkt_len);
 
-   if (pkt_hdr->p.l3_offset != ODP_PACKET_OFFSET_INVALID)
+   if (odp_unlikely(pktio_entry->s.chksum_insert_ena))
pkt_set_ol_tx(pktout_cfg, pktout_capa, pkt_hdr,
  mbuf, _odp_packet_data(pkt));
} else {
@@ -771,8 +774,7 @@ static inline int pkt_to_mbuf_zero(pktio_entry_t 
*pktio_entry,
mbuf_init((struct rte_mempool *)
  pool_entry->ext_desc, mbuf, pkt_hdr);
mbuf_update(mbuf, pkt_hdr, pkt_len);
-   if (pkt_hdr->p.l3_offset !=
-   ODP_PACKET_OFFSET_INVALID)
+   if (pktio_entry->s.chksum_insert_ena)
pkt_set_ol_tx(pktout_cfg, pktout_capa,
  pkt_hdr, mbuf,
  _odp_packet_data(pkt));
@@ -1432,6 +1434,7 @@ static int dpdk_start(pktio_entry_t *pktio_entry)
rte_eth_dev_info_get(port_id, _info);
dev_info.default_txconf.txq_flags = txq_flags;
txconf = _info.default_txconf;
+   pktio_entry->s.chksum_insert_ena = 1;
}
 
ret = rte_eth_tx_queue_setup(port_id, i, DPDK_NM_TX_DESC,

[lng-odp] [PATCH API-NEXT v2 4/5] test: l2fwd: add checksum offload option

[Github ODP bot]

From: Petri Savolainen 

Added option to enable checksum insertion at packet output. This
can be used to test checksum offload in various packet IO
combinations.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 313 (psavol:next-pktout-config)
 ** https://github.com/Linaro/odp/pull/313
 ** Patch: https://github.com/Linaro/odp/pull/313.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: e4a122986c2750ffb044994107b385bd8002cbf4
 **/
 test/performance/odp_l2fwd.c | 105 +++
 1 file changed, 76 insertions(+), 29 deletions(-)

diff --git a/test/performance/odp_l2fwd.c b/test/performance/odp_l2fwd.c
index 2daf0e2db..0ebb0dd17 100644
--- a/test/performance/odp_l2fwd.c
+++ b/test/performance/odp_l2fwd.c
@@ -92,6 +92,7 @@ static inline int sched_mode(pktin_mode_t in_mode)
  * Parsed command line application arguments
  */
 typedef struct {
+   int extra_check;/**< Some extra checks have been enabled */
int cpu_count;
int if_count;   /**< Number of interfaces to be used */
int addr_count; /**< Number of dst addresses to be used */
@@ -106,6 +107,7 @@ typedef struct {
int dst_change; /**< Change destination eth addresses */
int src_change; /**< Change source eth addresses */
int error_check;/**< Check packet errors */
+   int chksum; /**< Checksum offload */
int sched_mode; /**< Scheduler mode */
int num_groups; /**< Number of scheduling groups */
int verbose;/**< Verbose output */
@@ -293,6 +295,18 @@ static inline int event_queue_send(odp_queue_t queue, 
odp_packet_t *pkt_tbl,
return sent;
 }
 
+static inline void chksum_insert(odp_packet_t *pkt_tbl, int pkts)
+{
+   odp_packet_t pkt;
+   int i;
+
+   for (i = 0; i < pkts; i++) {
+   pkt = pkt_tbl[i];
+   odp_packet_l3_chksum_insert(pkt, 1);
+   odp_packet_l4_chksum_insert(pkt, 1);
+   }
+}
+
 /**
  * Packet IO worker thread using scheduled queues
  *
@@ -366,18 +380,23 @@ static int run_worker_sched_mode(void *arg)
for (i = 0; i < pkts; i++)
pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);
 
-   if (gbl_args->appl.error_check) {
-   int rx_drops;
+   if (odp_unlikely(gbl_args->appl.extra_check)) {
+   if (gbl_args->appl.chksum)
+   chksum_insert(pkt_tbl, pkts);
 
-   /* Drop packets with errors */
-   rx_drops = drop_err_pkts(pkt_tbl, pkts);
+   if (gbl_args->appl.error_check) {
+   int rx_drops;
 
-   if (odp_unlikely(rx_drops)) {
-   stats->s.rx_drops += rx_drops;
-   if (pkts == rx_drops)
-   continue;
+   /* Drop packets with errors */
+   rx_drops = drop_err_pkts(pkt_tbl, pkts);
 
-   pkts -= rx_drops;
+   if (odp_unlikely(rx_drops)) {
+   stats->s.rx_drops += rx_drops;
+   if (pkts == rx_drops)
+   continue;
+
+   pkts -= rx_drops;
+   }
}
}
 
@@ -487,18 +506,23 @@ static int run_worker_plain_queue_mode(void *arg)
for (i = 0; i < pkts; i++)
pkt_tbl[i] = odp_packet_from_event(event[i]);
 
-   if (gbl_args->appl.error_check) {
-   int rx_drops;
+   if (odp_unlikely(gbl_args->appl.extra_check)) {
+   if (gbl_args->appl.chksum)
+   chksum_insert(pkt_tbl, pkts);
 
-   /* Drop packets with errors */
-   rx_drops = drop_err_pkts(pkt_tbl, pkts);
+   if (gbl_args->appl.error_check) {
+   int rx_drops;
 
-   if (odp_unlikely(rx_drops)) {
-   stats->s.rx_drops += rx_drops;
-   if (pkts == rx_drops)
-   continue;
+   /* Drop packets with errors */
+   rx_drops = drop_err_pkts(pkt_tbl, pkts);
 
-   pkts -= rx_drops;
+   if (odp_unlikely(rx_drops)) {
+   stats->s.rx_drops += rx_drops;
+   if (pkts == rx_drops)
+ 

[lng-odp] [PATCH API-NEXT v2 0/5] api: pktio: add checksum insert enable bits

[Github ODP bot]

Added bits to control if checksum insertion is enabled /
disabled at packet output. Current configuration options
control if checksum is inserted / not inserted by default,
but leaves it open for application to request checksum
always with override functions. Explicit disable allows
implementation to optimize performance. E.g. DPDK does
uses more optimized driver code on Intel NICs when checksum
offload is disabled.

github
/** Email created from pull request 313 (psavol:next-pktout-config)
 ** https://github.com/Linaro/odp/pull/313
 ** Patch: https://github.com/Linaro/odp/pull/313.patch
 ** Base sha: bdb7cbf620ada8682c89b5ae5a97cb84f16c0ed0
 ** Merge commit sha: e4a122986c2750ffb044994107b385bd8002cbf4
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 94 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 10 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 68 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 197 lines checked


to_send-p-003.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 50 lines checked


to_send-p-004.patch has no obvious style problems and is ready for submission.
/checkpatch.pl