[lng-odp] new mailing list address

[Maxim Uvarov]

As part of ODP project moving from Linaro to Open Fast Path Foundation
the mailing list address has changed. The new mailing list address is
o...@lists.opendataplane.org. Mailing list subscriptions are not
automatically transferred to the new list. Please resubscribe to the
new list at https://lists.opendataplane.org/mailman/listinfo/odp.

The weekly ODP public call is arranged on Mondays at 13:00 (GMT).
Please find more information at ODP website
https://opendataplane.org/index.php/service/getinvolved/.

Best regards,
Maxim.

[lng-odp] did not attend today's ODP call

[Maxim Uvarov]

Gentleman, I'm sorry for missing call today.  Daughter had spike if
high temperature just on that time and I had to lower it.

If there are some questions or something needs to be done for ODP,
please send me an email.

Maxim.

[lng-odp] v1.20.0.0 has been released

[Maxim Uvarov]

v1.20.0.0 has been released and api-next branch is rebased on top of it.

== OpenDataPlane (1.20.0.0)
=== Summary of Changes
ODP v1.20.0.0 is a refresh of ODP, incorporating significant configurability
and performance improvements as well as new APIs and API restructures.

 APIs
= Symbol `ODP_SHM_NULL` Removed.
An invalid `odp_shm_t` has the value `ODP_SHM_INVALID`, consistent with
other
ODP types. The legacy synonym `ODP_SHM_NULL` is now removed for consistency.

= New 3GPP Crypto Algorithm Support
New support for 3GPP crypto algorithms is added by defining symbols for

* `ODP_CIPHER_ALG_KASUMI_F8`
* `ODP_CIPHER_ALG_SNOW3G_UEA2`
* `ODP_CIPHER_ALG_ZUC_EEA3`

In addition new authentication algorithm symbols are defined for

* `ODP_AUTH_ALG_KASUMI_F9`
* `ODP_AUTH_ALG_SNOW3G_UIA2`
* `ODP_AUTH_ALG_ZUC_EIA3`

These values are returned as ODP capabilities as well as being accepted in
crypto session creation for implementations that indicate support for them.

= Crypto Capability for Bitwise Operation
The new `bit_mode` capability Boolean is added to the
`odp_crypto_cipher_capability_t` struct to indicate that an implementation
supports operating in bit mode. When operating in bit
mode, field offsets and lengths are expressed in terms of bits rather than
bytes. However, such lengths must always be specified in multiples of 8.

= Improved Crypto Spec Documentation
The ODP crypto API specification is tightened to specify default values for
cipher and authentication algorithms. Also documented when key and IV
parameters need to be set.

= IPsec Extensions
IPsec requires "salt" (extra keying material) when the GMAC authentication
algorithm is used. To accommodate this the `auth_key_extra` field is added
to
the `odp_ipsec_crypto_param_t` struct and documentation is added clarifying
when this field is needed and how it should be used.

= Classifier Type Rename
The `odp_pmr_t` type name for an invalid value is renamed from
`ODP_PMR_INVAL`
to `ODP_PMR_INVALID` for consistency with the rest of ODP type names. The
old
symbol is still available when ODP is configured with
`--enable-deprecated`.

= New API for Packet Event Subtypes
The `odp_packet_subtype()` API is added that returns the subtype of a packet
event directly.

= Streamlined Packet Parsing Results
The `odp_packet_parse_result()` API is added that returns the result of
packet parsing as a single `odp_packet_parse_result_t` struct. This can
offer efficiency improvements for applications that need all parse results
rather than making individual parse result calls.

= PktIO Extensions to Support per-Queue Configuration
PktIO interfaces support multiple input queues to enable increased
parallelism
in I/O processing. Previously, all of these input queues were required to
belong to the same scheduler group. The `odp_pktin_queue_param_t` struct is
now extended with an optional `odp_pktin_queue_param_ovr_t` struct that
permits individual pktin queues to be assigned to separate scheduler groups.
This may permit improved performance for advanced application use cases.

= Timer Pool Capabilities
The `odp_timer_capability_t` struct is extended to return three additional
pieces of information:

`max_pools_combined`::
The total number of timer pools that can be created combining different
clock sources

`max_pools`::
The maximum number of timer pools for a given clock source.

`max_timers`::
The maximum number of timers in a single pool. A zero value means number is
limited only by available memory.

= Add Scheduler mix/max/default Priority Functions
Three new APIs: `odp_schedule_max_prio()`, `odp_schedule_min_prio()`, and
`odp_schedule_default_prio()` are added that return the min, max, and
default
values specified for the `prio` field in the `odp_schedule_param_t` struct.

With the introduction of these scheduling priority functions the previously
defined macros (`ODP_SCHED_PRIO_HIGHEST`, `ODP_SCHED_PRIO_NORMAL`, and
`ODP_SCHED_PRIO_LOWEST`) are now deprecated and should no longer be used.

= Specification of `odp_schedule_prio_t` as an `int`
Previously, the `odp_schedule_prio_t` type definition was left to each
implementation. With the addition of explicit schedule priority ranges, this
type is now specified to be an `int` to permit efficient implementation
(including inlining) of these functions.

== New Scheduler APIs
The new scheduler APIs `odp_schedule_multi_wait()` and
`odp_schedule_multi_no_wait()` are added to provide more efficiently
implementable versions of these functions. The existing scheduler APIs
remain
unchanged. These new APIs can simply provide a fastpath for some
applications/implementations as an alternative to specifying a parameter on
`odp_schedule_multi()`.

= Memory Model in `odp_init_global()`
The `odp_init_t` parameter passed to `odp_init_global()` is extended to
add the `mem_model` field. This field is defined by the new
`odp_mem_model_t`
struct and is used to specify whether the applicat

Re: [lng-odp] can't configure ODP with DPDK pktio using DPDK package in Ubutnu

[Maxim Uvarov]

apt-get install dpdk-dev
cd odp.git
./configure

It has to take everything from repo. At least ubuntu 18.04 has dpdk for x86.

For cross compilation please take a look at .travis.yml file. It uses
docker to compile odp. But cross compilation for now is only for 16.04
becase it was well ported on arm.
https://github.com/Linaro/odp-docker-images that project we use to build
images which are used for CI by .travis.yml.

Best regard,
Maxim.



On Mon, 29 Oct 2018 at 20:15, gyanesh patra 
wrote:

> Hi,
> I see that newer ubuntu has an updated version of DPDK. How can I build/run
> ODP with this DPDK in ubuntu? For me it fails at configure step.
> *Steps:*
>  1)Install dpdk-dev, libdpdk-dev, dpdk
>  2) ./configure --prefix=/root/odp/build
> --with-dpdk-path=/usr/share/dpdk/arm64-armv8a-linuxapp-gcc/
>
> *I am getting an error in configure step:*
>
> configure: Using shared DPDK library found at
> /usr/share/dpdk/arm64-armv8a-linuxapp-gcc//lib
> checking rte_config.h usability... no
> checking rte_config.h presence... no
> checking for rte_config.h... no
> checking for rte_eal_init in -ldpdk ... yes
> configure: error: in `/root/odp':
> configure: error: can't find DPDK
> See `config.log' for more details
>
>
> *Output from config.log file:*
>
> configure:20358: Using shared DPDK library found at
> /usr/share/dpdk/arm64-armv8a-linuxapp-gcc//lib
> configure:20374: checking rte_config.h usability
> configure:20374: gcc -c -g -O2 -pthread -isystem
> /usr/share/dpdk/arm64-armv8a-linuxapp-gcc//include/dpdk  conftest.c >&5
> conftest.c:107:10: fatal error: rte_config.h: No such file or directory
>  #include 
>   ^~
> compilation terminated.
> configure:20374: $? = 1
>
>
> *The rte_config.h file is foud at:*
>
> root@cavium:~/odp# locate rte_config.h
> /usr/include/aarch64-linux-gnu/dpdk/rte_config.h
> /usr/share/dpdk/arm64-armv8a-linuxapp-gcc/include/rte_config.h
>
>
> It is ubuntu 18.04, DPDK 17.11 and AARCH64 system.
>
> Thanks,
> P Gyanesh Kumar Patra
>

Re: [lng-odp] [EXT] Re: Get Physical address

[Maxim Uvarov]

It looks like to get address is not so complex, just read /proc/$pid/pagemap
https://stackoverflow.com/questions/5748492/is-there-any-api-for-determining-the-physical-address-from-virtual-address-in-li

But for linux-generic it's not clear why do we need this. Maybe AF_XDP
require physical address...

One of solution might be empty function in linux-generic which other
implementers can use redefine and use it as template.

Maxim.

On Tue, 23 Oct 2018 at 00:13, Bill Fischofer 
wrote:

> On Mon, Oct 22, 2018 at 3:17 PM Liron Himi  wrote:
>
> > Hi,
> >
> >
> >
> > I was not looking for a "standardized" set of internal API.
> >
> > I want to use the linux-generic implementation of odp-shared-memory, and
> > just request for additional linux-generic internal API to retrieve the
> > physical address of the buffer.
> >
> > Those internal APIs can be part of either of the odp_ishm_internal.h
> > files.
> >
>
> At present linux-generic has no need for such an API so I'm not sure how
> we'd define, use, or test one. But if you have a suggestion for what you'd
> like to see, feel free to create a PR to add it if that would better
> illustrate it.
>
>
> >
> >
> > Liron
> >
> >
> >
> > *From:* Bill Fischofer 
> > *Sent:* Monday, October 22, 2018 22:40
> > *To:* Liron Himi 
> > *Cc:* Elo, Matias (Nokia - FI/Espoo) ;
> > lng-odp-forward 
> > *Subject:* Re: [EXT] Re: [lng-odp] Get Physical address
> >
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 1:40 PM Liron Himi  wrote:
> >
> > Hi,
> >
> >
> >
> > It is for implementing ODP itself on our platform. So yes, we need
> > internal APIs to get physical address.
> >
> > Do you have plans to add such internal APIs?
> >
> >
> >
> > We do not have a "standardized" set of internal APIs because these would
> > be very platform specific and hence not readily portable to other
> > platforms. ODP has been focused on defining an external API set that
> > address application needs and can be in turn implemented efficiently
> across
> > a range of different platform architectures. This is the main reason why
> > ODP makes use of abstract data types so that each platform can define
> what
> > these mean in a manner that closely matches their own native data types
> and
> > organizational model without impacting application portability.
> >
> >
> >
> > One of the key design strategies behind ODP is not to define an
> > implementation model to preserve maximum flexibility on the part of
> > implementations to achieve native-level performance in a portable manner.
> > This is what enables easy realization of different ODP APIs in HW, SW, or
> > any combination of HW and SW as the implementation chooses.
> >
> >
> >
> > My suggestion would be that you define these abstract types in terms that
> > are native to your platform so that any "translation" needed can be done
> > under the covers with casts or similar minimal-cost constructs. That's
> the
> > model used in the reference implementation and has been successfully
> > adopted by other platforms.
> >
> >
> >
> > If you'd like to discuss specifics we can do that during the weekly ODP
> > public call (15:00 UTC every Tuesday). Feel free to join us for
> tomorrow's
> > call or whenever else is convenient.
> >
> >
> >
> >
> >
> > Liron
> >
> >
> >
> > *From:* Bill Fischofer 
> > *Sent:* Monday, October 22, 2018 21:32
> > *To:* Liron Himi 
> > *Cc:* Elo, Matias (Nokia - FI/Espoo) ;
> > lng-odp-forward 
> > *Subject:* Re: [EXT] Re: [lng-odp] Get Physical address
> >
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 12:41 PM Liron Himi  wrote:
> >
> > Hi Bill,
> >
> >
> >
> > We would like to use the linux-generic’s memory management especially
> with
> > the huge-pages support.
> >
> > This way we can refer to the above as a “infrastructure service” for
> > memory management. And we only need to get the physical address of the
> > buffers and pass them to our HW pools.
> >
> > Having this support provide us the ability to move to future versions
> with
> > the need to modify the platform memory management and support new APIs.
> >
> >
> >
> > Is this for applications or for implementing ODP itself on your platform?
> > ODP implementations will typically use ODP APIs internally for many
> common
> > needs and augment them with internal APIs. The ODP reference
> implementation
> > we supply has many such internal APIs that are typically prefixed with
> > _odp_xxx() to distinguish them from external APIs that use the odp_xxx()
> > form. If your internal memory management has a need for the concept of
> > physical addresses then you could certainly follow this pattern.
> >
> >
> >
> > The criteria for adding new ODP APIs is twofold: To address the
> functional
> > needs of ODP applications, and to enable platforms implementing ODP to
> > expose acceleration functions to applications efficiently in a
> > platform-neutral manner. Do you have an application use case for wanting
> > physical addresses, and if so can you elaborate on how you'd expect
> > appli

Re: [lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

[Maxim Uvarov]

can you create test case for us?

On Thu, 18 Oct 2018 at 14:55, gyanesh patra 
wrote:

> Hi,
> We are curious if there is any solution in the pipeline for this issue of
> iplookuptable insert, i.e. crash at buffer_alloc_multi() ? Any pointer
> will be really helpful.
> If it will help, we can create an issue in github too.
> Thanks for the help.
>
> Regards,
> P Gyanesh Kumar Patra
>
> On Tue, Sep 11, 2018 at 12:17 PM Maxim Uvarov 
> wrote:
>
>> odp prints happen on places where ODP_DBG("print something") is placed.
>> It's just additional debug information.
>> Also you can increase stack with ulimit -s unlimited and run valgrind to
>> that app. But I generated core on adding to table random values I saw
>> segfault and gdb pointed to that function.
>>
>> Maxim.
>>
>>
>>
>>
>> On 11 September 2018 at 18:03, Fabricio Rodríguez 
>> wrote:
>>
>>> Hi Maxim,
>>>
>>> I have tried the patch that you sent, but the issue continues.
>>>
>>> Also was trying enabling the debug flags at ODP but for some reason, I
>>> can not see any print, you have any suggestion of how to see the ODP debug
>>> prints when using an ODP library from an external application?.
>>>
>>> Regards,
>>>
>>> Fabricio
>>>
>>>
>>> El mar., 11 sept. 2018 a las 10:44, Maxim Uvarov (<
>>> maxim.uva...@linaro.org>) escribió:
>>>
>>>> Gyanesh,
>>>>
>>>> I tried to add some random data to ip lookup table and found that it
>>>> breaks it's own stack due to recursion.
>>>>
>>>> I have no idea if it's your case or not. Probably not because you have
>>>> buffer_alloc_multi in stack trace and I do not see that.
>>>>
>>>> You can test this patch:
>>>> https://github.com/Linaro/odp/pull/700
>>>>
>>>> Maxim.
>>>>
>>>> On 10.09.2018 20:01, gyanesh patra wrote:
>>>> > We tried it as:
>>>> > #define ENTRY_NUM_SUBTREE(1 << 12)
>>>> >
>>>> > But it didn't work. We couldn't increase it anymore without adding
>>>> > more RAM to system.
>>>> > One point to consider is that, this same thing was working with ODP
>>>> > 1.16 code, but with ODP 1.19 version it is not working.
>>>> >
>>>> > P Gyanesh Kumar Patra
>>>> >
>>>> >
>>>> > On Mon, Sep 10, 2018 at 12:31 PM Maxim Uvarov <
>>>> maxim.uva...@linaro.org
>>>> > <mailto:maxim.uva...@linaro.org>> wrote:
>>>> >
>>>> > did you try to increase?
>>>> >
>>>> > /* The size of one L2\L3 subtree */
>>>> > #define ENTRY_NUM_SUBTREE(1 << 8)
>>>> > ./helper/iplookuptable.c
>>>> >
>>>> > On 10 September 2018 at 18:27, gyanesh patra
>>>> > mailto:pgyanesh.pa...@gmail.com>>
>>>> wrote:
>>>> >
>>>> > We are using ODP library from an external application. hence i
>>>> > dont have a simple test code to reproduce it.
>>>> > But to give a perspective:
>>>> > - the value size as 12
>>>> > - the ip prefix is 32
>>>> > The crash is happening around 159th entry. If the prefix is
>>>> > changed to 16, the crash happens at around 496th entry.
>>>> > Regards,
>>>> > P Gyanesh Kumar Patra
>>>> >
>>>> >
>>>> > On Mon, Sep 10, 2018 at 12:16 PM Maxim Uvarov
>>>> > mailto:maxim.uva...@linaro.org>>
>>>> wrote:
>>>> >
>>>> > do you have some test code to reproduce it?
>>>> >
>>>> > On 10 September 2018 at 18:06, gyanesh patra
>>>> > >>> > <mailto:pgyanesh.pa...@gmail.com>> wrote:
>>>> >
>>>> > Hi,
>>>> > ODP is crashing at buffer_alloc_multi() while
>>>> > inserting into iplookuptable.
>>>> >
>>>> > The backtrace is as below: (gdb) bt #0
>>>> buffer_alloc_multi
>>>> > (pool=0x7fffd5420c00,
>>>> > buf_hdr=buf_hdr@entry=0x7fff55fa8bb0,
>>>> > max_num=max_num@entry=1) at odp_pool.c:700 #1
>>>> > 0x00433083 in
>>>> > odp_buffer_alloc (pool_hdl=pool_hdl@entry=0x9) at
>>>> > odp_pool.c:861 #2
>>>> > 0x00703732 in cache_alloc_new_pool
>>>> > (type=CACHE_TYPE_TRIE,
>>>> > tbl=) at iplookuptable.c:223 #3
>>>> > cache_get_buffer
>>>> > (type=CACHE_TYPE_TRIE, tbl=) at
>>>> > iplookuptable.c:248 #4
>>>> > trie_insert_node (nexthop=,
>>>> > cidr=,
>>>> > ip=, root=,
>>>> > tbl=) at
>>>> > iplookuptable.c:317 #5 odph_iplookup_table_put_value
>>>> > (tbl=,
>>>> > key=, value=) at
>>>> > iplookuptable.c:686
>>>> >
>>>> > Am i looking at any limitation to iplookuptable
>>>> > implementaion here? If any
>>>> > other details are needed, please let us know.
>>>> >
>>>> > Regards,
>>>> > P Gyanesh Kumar Patra
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>

[lng-odp] fixed netmap pktio test run under Travis

[Maxim Uvarov]

Fixed netmap pktio test run under Travis.

Example test run:

https://travis-ci.org/Linaro/odp/jobs/442711508

PASS: validation/api/pktio/pktio_run_netmap.sh

Fix:

https://github.com/Linaro/odp-docker-images/commit/86d32b463e6471662f21ff015cebc28f5e16c3c3

Problem was with missing lsmod/insmod in Ubuntu 16.04 Docker image.

Maxim.

Re: [lng-odp] odp with dpdk pktio gives error with larger packets - 'Segmented buffers not supported'

[Maxim Uvarov]

9000 is maximum size for large packets. 1500 is standard packet size. Plus
if you network wraps original ip packets to some tunnel that size (1500)
can be increased.

On Tue, 16 Oct 2018 at 23:45, gyanesh patra 
wrote:

> Hi Maxim,
> Increasing the POOL_SEG_LEN worked. But i am not sure how to calculate the
> necessary value to use?
> I was using the values from the odp_l2fwd example before. But now i
> required to increase it upto 2200 for it to work.
> Is there any guideline how to calculate this value? And also does it have
> any impact on performance?
>
> Regarding the examples, i tried with odp_l2fwd_simple and odp_switch and
> faced the same problem. But in my case "odp_l2fwd" example never recieves
> any packets. Hence i have not been able to test that.  If you can give any
> input regarding this, it will be helpful too.
> Thanks for your help.
>
> Regards,
> P Gyanesh Kumar Patra
>
>
> On Tue, Oct 16, 2018 at 3:36 PM Maxim Uvarov 
> wrote:
>
>> DPDK as ODP can have packets which are not in physacally continius
>> memory. I.e. packet can be split on several memory segments. That is not
>> supported by current code and you have this warning. I think that we have
>> dpdk pkio validation test and it works with large packets. But to do that
>> you need to be sure that you created pool with right parameters. In your
>> case  POOL_SEG_LEN has to be increased.
>>
>> Also you can try more featured example: ./test/performance/odp_l2fwd
>>
>> Best Regards,
>> Maxim.
>>
>>
>> On Tue, 16 Oct 2018 at 20:49, gyanesh patra 
>> wrote:
>>
>>> Hi,
>>> I am facing problem while using ODP master branch with DPDK pktio &
>>> zero-pkt-copy as below:
>>>
>>> ODP/bin/# ./odp_l2fwd_simple ./odp_l2fwd_simple
>>>
>>> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
>>> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
>>> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
>>> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
>>>
>>> This error is present for dpdk pktio only. It appears with larger packet
>>> sizes like 1518bytes, 1280bytes. But everything works fine with 1024bytes
>>> and smaller packets.
>>>
>>> I have verified that the packets have IP-don't fragment flag set. And
>>> Wireshark doesn't show any abnormality with the pcap.
>>> Is it broken or we need to specify some extra flags?
>>>
>>> I am on:
>>> commit 570758a22fd0d6e2b2a73eb8ed0a8360a5b0ef32
>>> Author: Matias Elo 
>>> Date:   Tue Oct 2 14:13:35 2018 +0300
>>>linux-gen: ring: allocate global data from shm
>>>
>>>
>>> Thanks,
>>> P Gyanesh Kumar Patra
>>>
>>

Re: [lng-odp] odp with dpdk pktio gives error with larger packets - 'Segmented buffers not supported'

[Maxim Uvarov]

DPDK as ODP can have packets which are not in physacally continius memory.
I.e. packet can be split on several memory segments. That is not supported
by current code and you have this warning. I think that we have dpdk pkio
validation test and it works with large packets. But to do that you need to
be sure that you created pool with right parameters. In your case
 POOL_SEG_LEN has to be increased.

Also you can try more featured example: ./test/performance/odp_l2fwd

Best Regards,
Maxim.


On Tue, 16 Oct 2018 at 20:49, gyanesh patra 
wrote:

> Hi,
> I am facing problem while using ODP master branch with DPDK pktio &
> zero-pkt-copy as below:
>
> ODP/bin/# ./odp_l2fwd_simple ./odp_l2fwd_simple
>
> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
> pktio/dpdk.c:851:mbuf_to_pkt_zero():Segmented buffers not supported
>
> This error is present for dpdk pktio only. It appears with larger packet
> sizes like 1518bytes, 1280bytes. But everything works fine with 1024bytes
> and smaller packets.
>
> I have verified that the packets have IP-don't fragment flag set. And
> Wireshark doesn't show any abnormality with the pcap.
> Is it broken or we need to specify some extra flags?
>
> I am on:
> commit 570758a22fd0d6e2b2a73eb8ed0a8360a5b0ef32
> Author: Matias Elo 
> Date:   Tue Oct 2 14:13:35 2018 +0300
>linux-gen: ring: allocate global data from shm
>
>
> Thanks,
> P Gyanesh Kumar Patra
>

[lng-odp] will be miss today arch call

[Maxim Uvarov]

Hello team,

I will miss today's arch call due to family needs. I think I will be able
to do review and merge patches later today.

Best regards,
Maxim.

[lng-odp] github renaming script is not operation right now

[Maxim Uvarov]

As you can see github assistant scripts stopped to work now. We re run AWS
server with that scripts but unfortunately github changed authorization api
to 2-way authorization and it will take some time to create tokens and link
them to login. I'm sure that I can fix it just after way back from Connect,
not sure if I can fix everything during Connect.

Maxim.

Re: [lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

[Maxim Uvarov]

Can you please compile ODP with debug:
 ./configure --enable-debug --enable-debug-print
--enable-helper-debug-print CFLAGS="-O0"

Do you run on x86?

It looks like prefix_insert_into_lx() a little bit buggy and there might be
recursion forever. Ret is defined as uint8, has to be int. e->cidr does not
use upper bit of uint8_t, so it's in range of 0 to 127, but range is not
validated. Upper function does not test for error return.

Also if you are saying that it worked on 1.16 then 'git bissect' can point
to exact commit which broke it.
The only commit which touched this file is:
commit 5a4502fc6bc53e6503169da3028f456b64811a0b
Author: Ilias Apalodimas 
Date:   Tue Jan 16 21:09:35 2018 +0200

linux-gen: align: Fix alignment for typedef definitions

* typedef struct { } ODP_ALIGN() test_t; is correct
* typedef struct ODP_ALIGN() {} test_t; is correct and
preferred from gcc standards
* typedef struct {} test_t ODP_ALIGN() discards align
Had segfauls on gcc-7 using that

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Bill Fischofer 
    Signed-off-by: Maxim Uvarov 

Maxim.

On 10 September 2018 at 20:01, gyanesh patra 
wrote:

> We tried it as:
> #define ENTRY_NUM_SUBTREE (1 << 12)
>
> But it didn't work. We couldn't increase it anymore without adding more
> RAM to system.
> One point to consider is that, this same thing was working with ODP 1.16
> code, but with ODP 1.19 version it is not working.
>
> P Gyanesh Kumar Patra
>
>
> On Mon, Sep 10, 2018 at 12:31 PM Maxim Uvarov 
> wrote:
>
>> did you try to increase?
>>
>> /* The size of one L2\L3 subtree */
>> #define ENTRY_NUM_SUBTREE (1 << 8)
>> ./helper/iplookuptable.c
>>
>> On 10 September 2018 at 18:27, gyanesh patra 
>> wrote:
>>
>>> We are using ODP library from an external application. hence i dont have
>>> a simple test code to reproduce it.
>>> But to give a perspective:
>>> - the value size as 12
>>> - the ip prefix is 32
>>> The crash is happening around 159th entry. If the prefix is changed to
>>> 16, the crash happens at around 496th entry.
>>>
>>> Regards,
>>> P Gyanesh Kumar Patra
>>>
>>>
>>> On Mon, Sep 10, 2018 at 12:16 PM Maxim Uvarov 
>>> wrote:
>>>
>>>> do you have some test code to reproduce it?
>>>>
>>>> On 10 September 2018 at 18:06, gyanesh patra 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> ODP is crashing at buffer_alloc_multi() while inserting into
>>>>> iplookuptable.
>>>>>
>>>>> The backtrace is as below: (gdb) bt #0 buffer_alloc_multi
>>>>> (pool=0x7fffd5420c00, buf_hdr=buf_hdr@entry=0x7fff55fa8bb0,
>>>>> max_num=max_num@entry=1) at odp_pool.c:700 #1 0x00433083 in
>>>>> odp_buffer_alloc (pool_hdl=pool_hdl@entry=0x9) at odp_pool.c:861 #2
>>>>> 0x00703732 in cache_alloc_new_pool (type=CACHE_TYPE_TRIE,
>>>>> tbl=) at iplookuptable.c:223 #3 cache_get_buffer
>>>>> (type=CACHE_TYPE_TRIE, tbl=) at iplookuptable.c:248 #4
>>>>> trie_insert_node (nexthop=, cidr=,
>>>>> ip=, root=, tbl=) at
>>>>> iplookuptable.c:317 #5 odph_iplookup_table_put_value (tbl=>>>> out>,
>>>>> key=, value=) at iplookuptable.c:686
>>>>>
>>>>> Am i looking at any limitation to iplookuptable implementaion here? If
>>>>> any
>>>>> other details are needed, please let us know.
>>>>>
>>>>> Regards,
>>>>> P Gyanesh Kumar Patra
>>>>>
>>>>
>>>>
>>

Re: [lng-odp] ODP crash at buffer_alloc_multi() while inserting into iplookuptable

[Maxim Uvarov]

do you have some test code to reproduce it?

On 10 September 2018 at 18:06, gyanesh patra 
wrote:

> Hi,
> ODP is crashing at buffer_alloc_multi() while inserting into iplookuptable.
>
> The backtrace is as below: (gdb) bt #0 buffer_alloc_multi
> (pool=0x7fffd5420c00, buf_hdr=buf_hdr@entry=0x7fff55fa8bb0,
> max_num=max_num@entry=1) at odp_pool.c:700 #1 0x00433083 in
> odp_buffer_alloc (pool_hdl=pool_hdl@entry=0x9) at odp_pool.c:861 #2
> 0x00703732 in cache_alloc_new_pool (type=CACHE_TYPE_TRIE,
> tbl=) at iplookuptable.c:223 #3 cache_get_buffer
> (type=CACHE_TYPE_TRIE, tbl=) at iplookuptable.c:248 #4
> trie_insert_node (nexthop=, cidr=,
> ip=, root=, tbl=) at
> iplookuptable.c:317 #5 odph_iplookup_table_put_value (tbl=,
> key=, value=) at iplookuptable.c:686
>
> Am i looking at any limitation to iplookuptable implementaion here? If any
> other details are needed, please let us know.
>
> Regards,
> P Gyanesh Kumar Patra
>

Re: [lng-odp] pktio_run_pcap.sh question

[Maxim Uvarov]

does it hangs or it takes too long time to complete?

On 5 September 2018 at 10:46, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> On 05/09/18 09:24, Maxim Uvarov wrote:
> > it hangs on some ubuntu where iptables default policy is drop. Can it be
> > that case? (we had fix in .travis.yaml for that.)
>
> iptables fix was necessary for tap test, I'm asking about pcap test.
>
> >
> > On 5 September 2018 at 00:49, Dmitry Eremin-Solenikov
> >  > <mailto:dmitry.ereminsoleni...@linaro.org>> wrote:
> >
> > Hello colleagues,
> >
> > I'm observing pktio pcap test taking too long to complete.
> Unfortunately
> > this happens in Automake-controlled test run on PPA, so the only
> known
> > thing is that this test timeouts. Any suggestions/ideas?
> >
> > --
> > With best wishes
> > Dmitry
> >
> >
>
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] pktio_run_pcap.sh question

[Maxim Uvarov]

it hangs on some ubuntu where iptables default policy is drop. Can it be
that case? (we had fix in .travis.yaml for that.)

On 5 September 2018 at 00:49, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello colleagues,
>
> I'm observing pktio pcap test taking too long to complete. Unfortunately
> this happens in Automake-controlled test run on PPA, so the only known
> thing is that this test timeouts. Any suggestions/ideas?
>
> --
> With best wishes
> Dmitry
>

[lng-odp] odp docker ci howto

[Maxim Uvarov]

Hello Matias,

I've update here Travis paragraph for Docker usage:
https://github.com/Linaro/odp/wiki

Best regards,
Maxim.

Re: [lng-odp] Reconsidering PowerPC architecture for ODP

[Maxim Uvarov]

DPAA is arm64, at least main core. Isn't it?

I see that DPDK is supported on IBM Power8. So ODP-DPDK on Power is one 
use case. I'm not sure if there can be done any native ODP port or they 
just use PCI.


So the question is how it will affect on ODP  Debian packaging? If 
Debian will build ODP for Power it might be good to support it. From 
other point of view to port odp linux-generic to different arch should 
not be a big problem. And we can left this task to person which needs that.


Maxim.


On 22.08.2018 14:44, Bill Fischofer wrote:

While ODP itself is platform-neutral and architecture independent, which
platforms to test on is a question of resourcing. So this is really an
SC-level question. We'll support whatever architectures the ODP membership
wishes to emphasize, but the current test focus remains Arm and x86.

If we have easy access to POWER8/9 cross compilers it might be good to do a
quick test compile to see if there are any issues that arise, but unless
someone steps forward to champion these architectures I don't see us making
them part of our standard regression tests and packaging.

On Wed, Aug 22, 2018 at 6:11 AM Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:


Hello,

While working on ODP packages for Debian and Ubuntu, I've noticed that
those distros have switched their focus from 'powerpc' port (old 32-bit
big endian machines) to ppc64el (64-bit little endian machines: POWER8,
POWER9). E.g. Debian has moved 'powerpc' from main archive to ports.d.o
since July 1st, 2018.

Should we reconsider supporting plain powerpc and also switch to ppc64el
architecture? Or do we plan to support powerpc to let ODP applications
run on Freescale/NXP PowerQUICC/DPAA processors?

--
With best wishes
Dmitry

[lng-odp] destroy tm system

[Maxim Uvarov]

I'm looking on errors of our example for traffic manager. There is
missing destroy path for created tm queues. Now when I look to it I'm
thinking that it will be good to simplify ODP api  for cleaning up TM
settings.

On configuring TM we need to create TM nodes and TM queues, then link
nodes and queues. I.e. we build some kind of tree of nodes and queues.
And on termination we need to destroy that tree. I.e. application
should store this tree to be able to walk over it and cleanly destroy.
That is very annoying from application development point of view. We
can flush TM queues and then destroy TM system and implementation can
take care how to destroy it in clean way.

Best regards,
Maxim.

[lng-odp] patches to mailing list

[Maxim Uvarov]

I restored sripts to email patches from github to mailing list. There 
was problem with python utf-8 strings conversion which came with some 
update. In general I can run script to email all even already closed 
PRs. That might be useful for searching for patches from web. Mailing 
list test is more easy to index then github https pages.



Maxim.

Re: [lng-odp] latency calulation with netmap pkt i/o fails with oversized packet debug msg

[Maxim Uvarov]

On 26 July 2018 at 21:24, gyanesh patra  wrote:

> I verified the throughput over the link with/without this debug message.
> With DEBUG message: 10-15 Mbps
> without DEBUG message: 1500 Mbps
>
> Due to this debug message to the stdout, the throughput drops to the
> minimum and the latency can't be calculated properly too.
> Should i just remove the debug message from the netmap.c file? Does it
> serve any purpose?
>
>
Yes it has to be removed or odp compiled without --enable-debug

Actually print is on wrong arm of "if" statement. I.e. when packet accepted
drop error printed. Thanks for reporting this.

Maxim.




> Regards,
> Gyanesh
>
> On Thu, Jul 26, 2018 at 11:25 AM Maxim Uvarov 
> wrote:
>
>>
>>
>> On 26 July 2018 at 16:01, gyanesh patra  wrote:
>>
>>> Hi,
>>> Here is the output for the debug messages as advised:
>>> For this code:
>>> --
>>>  541 ODP_DBG("MTU: %" PRIu32 "\n", mtu);
>>>
>>>  542 ODP_DBG("NM buf_size: %" PRIu32 "\n", buf_size);
>>>
>>>  543 pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>>>
>>> Output:
>>> -
>>> netmap interface: eth5
>>>   num_rx_desc: 0
>>>   num_tx_desc: 0
>>> pktio/netmap.c:541:netmap_open():MTU: 1514
>>> pktio/netmap.c:542:netmap_open():NM buf_size: 2048
>>> pktio/netmap.c:567:netmap_open():netmap pktio eth5 does not support
>>> statistics counters
>>> odp_packet_io.c:295:odp_pktio_open():interface: eth5, driver: netmap
>>>
>>> =
>>> For this code:
>>> --
>>>  839 if (odp_likely(ring->slot[slot_id].len <= mtu)) {
>>>
>>>  840 slot_tbl[num_rx].buf = buf;
>>>
>>>  841 slot_tbl[num_rx].len = ring->slot[slot_id].len;
>>>
>>>  842 ODP_DBG("dropped oversized packet %d
>>> %d\n",ring->slot[slot_id].len, mtu);
>>>  843 num_rx++;
>>>
>>>  844 }
>>>
>>> Output:
>>> 
>>> pktio/netmap.c:842:netmap_recv_desc():dropped oversized packet 60 1514
>>> pktio/netmap.c:842:netmap_recv_desc():dropped oversized packet 60 1514
>>>
>>>
>> Are packets dropped or you just see this message?
>>
>> if (odp_likely(ring->slot[slot_id].len <= mtu)) {
>> slot_tbl[num_rx].buf = buf;
>> slot_tbl[num_rx].len = ring->slot[slot_id].len;
>> ODP_DBG("dropped oversized packet\n");
>> num_rx++;
>> }
>>
>> num_rx is increasing then packet wrapped into odp:
>> if (num_rx) {
>> return netmap_pkt_to_odp(pktio_entry, pkt_table, slot_tbl,
>> num_rx, ts);
>>
>> it looks like message just confusing. Packet is less then mtu.
>>
>>
>>
>>
>>> If anything else is required, i can get those details too.
>>>
>>> Thanks,
>>> P Gyanesh Kumar Patra
>>>
>>>
>>> On Thu, Jul 26, 2018 at 3:36 AM Elo, Matias (Nokia - FI/Espoo) <
>>> matias@nokia.com> wrote:
>>>
>>>>
>>>>
>>>> > On 25 Jul 2018, at 17:11, Maxim Uvarov 
>>>> wrote:
>>>> >
>>>> > For quick look it looks like mtu is not set correctly on open(). Can
>>>> you try this patch:
>>>> >
>>>> > diff --git a/platform/linux-generic/pktio/netmap.c
>>>> b/platform/linux-generic/pktio/netmap.c
>>>> > index 0da2b7a..d4db0af 100644
>>>> > --- a/platform/linux-generic/pktio/netmap.c
>>>> > +++ b/platform/linux-generic/pktio/netmap.c
>>>> > @@ -539,6 +539,7 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED,
>>>> pktio_entry_t *pktio_entry,
>>>> > goto error;
>>>> > }
>>>> > pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>>>> > +   pkt_priv(pktio_entry)->mtu = pkt_nm->mtu;
>>>>
>>>>
>>>> pkt_netmap_t *pkt_nm = pkt_priv(pktio_entry), so this is unnecessary.
>>>>
>>>>
>>>> >>
>>>> >>
>>>> >> Is this a know issue or am i missing something?
>>>> >>
>>>>
>>>>
>>>> As far as I can see the problem is caused by reading interface MTU
>>>> incorrectly or netmap using unusually small buffers (assuming moongen sends
>>>> packets smaller than MTU). The following patch should help debug the issue.
>>>>
>>>> -Matias
>>>>
>>>> diff --git a/platform/linux-generic/pktio/netmap.c
>>>> b/platform/linux-generic/pktio/netmap.c
>>>> index 0da2b7afd..3e0a17542 100644
>>>> --- a/platform/linux-generic/pktio/netmap.c
>>>> +++ b/platform/linux-generic/pktio/netmap.c
>>>> @@ -538,6 +538,10 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED,
>>>> pktio_entry_t *pktio_entry,
>>>> ODP_ERR("Unable to read interface MTU\n");
>>>> goto error;
>>>> }
>>>> +
>>>> +   ODP_DBG("MTU: %" PRIu32 "\n", mtu);
>>>> +   ODP_DBG("NM buf_size: %" PRIu32 "\n", buf_size);
>>>> +
>>>> pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>>>>
>>>> /* Check if RSS is supported. If not, set 'max_input_queues' to
>>>> 1. */
>>>>
>>>>
>>>>
>>

Re: [lng-odp] latency calulation with netmap pkt i/o fails with oversized packet debug msg

[Maxim Uvarov]

On 26 July 2018 at 16:01, gyanesh patra  wrote:

> Hi,
> Here is the output for the debug messages as advised:
> For this code:
> --
>  541 ODP_DBG("MTU: %" PRIu32 "\n", mtu);
>
>  542 ODP_DBG("NM buf_size: %" PRIu32 "\n", buf_size);
>
>  543 pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>
> Output:
> -
> netmap interface: eth5
>   num_rx_desc: 0
>   num_tx_desc: 0
> pktio/netmap.c:541:netmap_open():MTU: 1514
> pktio/netmap.c:542:netmap_open():NM buf_size: 2048
> pktio/netmap.c:567:netmap_open():netmap pktio eth5 does not support
> statistics counters
> odp_packet_io.c:295:odp_pktio_open():interface: eth5, driver: netmap
>
> =
> For this code:
> --
>  839 if (odp_likely(ring->slot[slot_id].len <= mtu)) {
>
>  840 slot_tbl[num_rx].buf = buf;
>
>  841 slot_tbl[num_rx].len = ring->slot[slot_id].len;
>
>  842 ODP_DBG("dropped oversized packet %d
> %d\n",ring->slot[slot_id].len, mtu);
>  843 num_rx++;
>
>  844 }
>
> Output:
> 
> pktio/netmap.c:842:netmap_recv_desc():dropped oversized packet 60 1514
> pktio/netmap.c:842:netmap_recv_desc():dropped oversized packet 60 1514
>
>
Are packets dropped or you just see this message?

if (odp_likely(ring->slot[slot_id].len <= mtu)) {
slot_tbl[num_rx].buf = buf;
slot_tbl[num_rx].len = ring->slot[slot_id].len;
ODP_DBG("dropped oversized packet\n");
num_rx++;
}

num_rx is increasing then packet wrapped into odp:
if (num_rx) {
return netmap_pkt_to_odp(pktio_entry, pkt_table, slot_tbl,
num_rx, ts);

it looks like message just confusing. Packet is less then mtu.




> If anything else is required, i can get those details too.
>
> Thanks,
> P Gyanesh Kumar Patra
>
>
> On Thu, Jul 26, 2018 at 3:36 AM Elo, Matias (Nokia - FI/Espoo) <
> matias@nokia.com> wrote:
>
>>
>>
>> > On 25 Jul 2018, at 17:11, Maxim Uvarov  wrote:
>> >
>> > For quick look it looks like mtu is not set correctly on open(). Can
>> you try this patch:
>> >
>> > diff --git a/platform/linux-generic/pktio/netmap.c
>> b/platform/linux-generic/pktio/netmap.c
>> > index 0da2b7a..d4db0af 100644
>> > --- a/platform/linux-generic/pktio/netmap.c
>> > +++ b/platform/linux-generic/pktio/netmap.c
>> > @@ -539,6 +539,7 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED,
>> pktio_entry_t *pktio_entry,
>> > goto error;
>> > }
>> > pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>> > +   pkt_priv(pktio_entry)->mtu = pkt_nm->mtu;
>>
>>
>> pkt_netmap_t *pkt_nm = pkt_priv(pktio_entry), so this is unnecessary.
>>
>>
>> >>
>> >>
>> >> Is this a know issue or am i missing something?
>> >>
>>
>>
>> As far as I can see the problem is caused by reading interface MTU
>> incorrectly or netmap using unusually small buffers (assuming moongen sends
>> packets smaller than MTU). The following patch should help debug the issue.
>>
>> -Matias
>>
>> diff --git a/platform/linux-generic/pktio/netmap.c
>> b/platform/linux-generic/pktio/netmap.c
>> index 0da2b7afd..3e0a17542 100644
>> --- a/platform/linux-generic/pktio/netmap.c
>> +++ b/platform/linux-generic/pktio/netmap.c
>> @@ -538,6 +538,10 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED,
>> pktio_entry_t *pktio_entry,
>> ODP_ERR("Unable to read interface MTU\n");
>> goto error;
>> }
>> +
>> +   ODP_DBG("MTU: %" PRIu32 "\n", mtu);
>> +   ODP_DBG("NM buf_size: %" PRIu32 "\n", buf_size);
>> +
>> pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
>>
>> /* Check if RSS is supported. If not, set 'max_input_queues' to
>> 1. */
>>
>>
>>

Re: [lng-odp] latency calulation with netmap pkt i/o fails with oversized packet debug msg

[Maxim Uvarov]

For quick look it looks like mtu is not set correctly on open(). Can you 
try this patch:


diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c

index 0da2b7a..d4db0af 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -539,6 +539,7 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,

    goto error;
    }
    pkt_nm->mtu = (mtu < buf_size) ? mtu : buf_size;
+   pkt_priv(pktio_entry)->mtu = pkt_nm->mtu;

    /* Check if RSS is supported. If not, set 'max_input_queues' to 
1. */

    if (rss_conf_get_supported_fd(sockfd, netdev, &hash_proto) == 0) {
@@ -836,7 +837,8 @@ static inline int netmap_recv_desc(pktio_entry_t 
*pktio_entry,

    if (odp_likely(ring->slot[slot_id].len <= mtu)) {
    slot_tbl[num_rx].buf = buf;
    slot_tbl[num_rx].len = 
ring->slot[slot_id].len;

-   ODP_DBG("dropped oversized packet\n");
+   ODP_DBG("dropped oversized packet %d %d\n",
+ ring->slot[slot_id].len, mtu);
    num_rx++;
    }
    ring->cur = nm_ring_next(ring, slot_id);


On 25.07.2018 16:59, gyanesh patra wrote:

I am trying to run moongen to calculate the latency in the link. I compiled
ODP with netmap.
I run example/l2-load-latency.lua from moongen and odp_l2fwd_simple from
ODP. I found that most of the packets are dropped at the rx side of ODP.

ODP--
root@test:~/gyn/odp/buildN/bin# ./odp_l2fwd_simple eth5 eth6
01:02:03:04:05:06 07:08:09:0a:0b:0c

pktio/netmap.c:839:netmap_recv_desc():dropped oversized packet
pktio/netmap.c:839:netmap_recv_desc():dropped oversized packet
---

---MOONGEN---
root@ubuntu:/home/ubuntu# ./MoonGen/build/MoonGen
./MoonGen/examples/l2-load-latency.lua 0 1
---

---ubunut--
root@test:# ifconfig eth5
eth5  Link encap:Ethernet  HWaddr a0:36:9f:3e:95:34
   inet6 addr: fe80::a236:9fff:fe3e:9534/64 Scope:Link
   UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
   RX packets:8288 errors:21532426 dropped:*1229684107* overruns:0
frame:21532426
   TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:742932 (742.9 KB)  TX bytes:2376 (2.3 KB)

root@test:# ifconfig eth6
eth6  Link encap:Ethernet  HWaddr a0:36:9f:3e:95:36
   inet6 addr: fe80::a236:9fff:fe3e:9536/64 Scope:Link
   UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
   RX packets:2780 errors:0 dropped:554038705 overruns:0 frame:0
   TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:166800 (166.8 KB)  TX bytes:3276 (3.2 KB)



When i try the same thing while compiling ODP with DPDK, it works fine. I
am getting error in case of Netmap packet i/o.

Is this a know issue or am i missing something?

Thanks
Gyanesh

Re: [lng-odp] ODP logo to use in academic publications

[Maxim Uvarov]

main odp project has:
./doc/images/ODP-Logo-HQ.svg

I think it should be possible to convert it to eps.

Maxim.

On 25 July 2018 at 15:38, gyanesh patra  wrote:

> ​
> Hi,
> I am looking for the ODP Logo in eps format to use in academic
> publications. I have only encountered png files. Is there any goto location
> where i can find the logo?
>
> Thanks,
> P Gyanesh Kumar Patra
>

[lng-odp] travis CI issues

[Maxim Uvarov]

It looks like Travis has issues with images which marked as deprecated in
travis.yaml file. Unfortunately quick jump to new image will break cross
platforms builds. I almost rewrote CI jobs into containers. Hope with
update PR at the end of current week. I.e. I have CI worked again but need
to prepare clean patch. Verification configuration inside Travis takes some
time

Maxim.

[lng-odp] odp v1.19.0.2 has been tagged!

[Maxim Uvarov]

Hello,

New ODP release has be tagged in the repo (https://github.com/Linaro/odp).
I think it might be reasonable to duplicate changelog in mailing list.
Because of we switched ot github and people who do not signed to github
email notifications might not see that news. Please find changelog bellow.

== OpenDataPlane (1.19.0.2)
=== Summary of Changes
ODP v1.19.0.2 is the second service update for the Tiger Moth release. It
incorporates a number of corrections and enhancements that further improve
the
quality and testability of ODP.

 APIs
There are no API changes in this release.

 DPDK Service Release Sync
ODP is now paired with DPDK 17.11.3 for its DPDK-related support. This is
the
current service level for the DPDK 17.11 LTS package used by ODP Tiger Moth.

=== Implementation Improvements
This release incorporates several improvements in the `odp-linux` reference
implementation of ODP.

 Enhanced Inlining
ODP supports inlining of functions in embedded environments when ABI
compatibility is not needed. ODP itself now makes use of inlined functions
for
all relevant internal use of its APIs, leading to improved performance.

 Completion of CRC API Implementation
The `odp_hash_crc_gen64()` API is now properly implemented and appropriate
validation tests added to support it.

In addition, a streamlined table-based implementation of the basic CRC
functions eliminates the previous dependency on `zlib`.

 PktIO-Specific Parsing
To better integrate with DPDK parsing capabilities, ODP packet parsing has
been restructured to operate at the PktIO level. This permits DPDK PktIO
types
to exploit the native DPDK packet parser and checksum facilities, leading
to better integration.

 PktIO Internal Cleanup and Restructure
The PktIO functions have been streamlined and refactored in a number of ways
to provide better long-term maintainability of these functions. This
includes
moving per-PktIO data into individual files rather than sharing a common
file,
as well as better placement for I/O statistics.

 Checksum Validation Support
Loop PktIO interfaces now add the capability to validate packet L3 and L4
checksums as part of receive processing. The existing
`odp_pktio_capability()`
API now reports that checksum validation is available for these interfaces.

 Single Producer / Single Consumer Queue Performance Optimizations
When defining lock free queues that have only a single producer and
consumer,
a streamlined implementation offers significant speedup.
 Fast PCAPng Packet Capture
Fast pcap capture is now provided in `odp-linux` to capture packets on any
interface. This is enabled via the `--enable-pcapng-support` configuration
option. Once enabled, packets can be captured using a sequence such as:
-
sudo mkdir /var/run/odp/
start ODP application that reads/writes to the interface of interest
start the ODP application
sudo dd if=/var/run/odp/--flow- of=~/test.pcap

cntrl^c to end capture
wireshark ~/test.pcap to view capture
-

Interfaces of interest are identified by a string consisting of the
application process ID, the interface name, and the queue number of
interest,
if the interface supports multiple queues.

 Removal of GPL M4 Macros
A number of autotools/autoconf M4 macros used in configuring `odp-linux`
have
been rewritten to avoid potential GPL licensing concerns. These macros are
used only during ODP configuration processing and have no role in ODP
or ODP application use.

=== Validation Test Improvements
 Queue Pair Validation Tests
The validation test suite for queue API testing is enhanced to now test
operation on queue pairs properly. This enables the various enqueue/dequeue
modes defined by the ODP specification to be more fully exercised, leading
to improved API conformance.

 Scheduling Test Improvements
The scheduling validation tests now better use the various capability APIs
to
ensure that implementations are only tested for advertised capabilities.

=== Crypto Test Improvements
The crypto validation tests now better use the various capability APIs to
ensure that implementations are tested across advertised crypto
capabilities.

=== Performance Test Improvements
 New Performance Test
A new `odp_queue_perf` test has been added to test plain (non-scheduled)
queue performance in various modes.

=== Helper Changes
* The `getopt` library calls are no longer used to avoid packaging conflicts
that can arise with this use. There are no changes to helper functionality.
This change simply improves packaging.

=== Examples Improvements
* The `odp_generator` example adds UDP port range support.

 CI Improvements
Numerous changes to Travis integration are added to improve the quality and
reliability of Continuous Integration (CI) testing.

=== Bug Fixes
 https://bugs.linaro.org/show_bug.cgi?id=3787[Bug 3787]
Timeout accuracy breaks down with odd resolution requests

 https://bugs.linaro.org/show_bug.cgi?id=3867[Bug 3867]
timer validation test 

Re: [lng-odp] unrecognized command line option '-fstack-protector-strong'

[Maxim Uvarov]

On 27.06.2018 19:41, Bill Fischofer wrote:
Is this an ODP question or a DPDK question? Is this unique to Ubuntu 
14.04?  I notice that release goes out of support in April 2019 so I'm 
wondering if it's still an important release to carry.




I'm trying to build dependencies for linux-generic odp for the same 
Ubuntu which Travis ships in his image. Which a little bit buggy for 
cross arch support (libpcap-dev package conflicts between arches,
some other dependencies issues). But in general it works.  But I think 
you are right it's better to switch to some fresh image, like Ubuntu 
18.04 LTS.


Maxim.

On Wed, Jun 27, 2018 at 10:41 AM Maxim Uvarov <mailto:maxim.uva...@linaro.org>> wrote:


Ubuntu 14.04.5 which I run in container uses gcc 4.8 but on host I
use more
fresh Ubuntu kernel compiled with stack protector. That makes dpdk
modules
not compatible.  But it's not clear why dpdk modules inherit kernels
compiler options. Is there any workaround for that?

  LD

/root/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/built-in.o
  CC [M]

/root/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
gcc: error: unrecognized command line option
'-fstack-protector-strong'


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.4'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
--enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object
--disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror
--with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)

[lng-odp] unrecognized command line option '-fstack-protector-strong'

[Maxim Uvarov]

Ubuntu 14.04.5 which I run in container uses gcc 4.8 but on host I use more
fresh Ubuntu kernel compiled with stack protector. That makes dpdk modules
not compatible.  But it's not clear why dpdk modules inherit kernels
compiler options. Is there any workaround for that?

  LD
/root/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/built-in.o
  CC [M]
/root/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
gcc: error: unrecognized command line option '-fstack-protector-strong'


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.4'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)

[lng-odp] move odp travis tests under docker

[Maxim Uvarov]

Hello,

I'm going to issue PR to completely move all travis tests under docker 
environment. It will be the same environment ubuntu + cross tools 
installed with apt-get but everything is already set up there.


I did experiments and see that execution time is about the same.

Commit to run docker image:

https://github.com/muvarov/odp/commit/5daeb6ea4c5f4d8e031ec96c94938dff03e3f155

Test results.

https://travis-ci.org/muvarov/odp/builds/395065016?utm_source=github_status&utm_medium=notification

One of the benefit which docker provides is easy what to run cross 
compilation tests locally and tests everything locally.


Just 2 commands:

1) apt-get install docket.io

2) Run compilation with share current ODP directory inside container:

docker run  -i -t -v `pwd`:/odp maximuvarov/odp_ubuntu_14.04.5 
/root/build_arm64.sh


or

docker run  -i -t -v `pwd`:/odp maximuvarov/odp_ubuntu_14.04.5 
/root/build_armhf.sh


(for debugging you can run /bin/bash and run all steps from console).

I think that is very awesome for debugging and quickly set all 
environment and dependencies. And will allow use quickly adopt test 
environment to new distros.


Also I do not see any reason why we should left current apt-get 
everything in travis. So it can be removed.


And some virtual qemu target tests can be implemented. It will be match 
more faster to debug them locally than pushing changes to Travis system.


Does anybody has objections about doing such changes?

Maxim.

Re: [lng-odp] push_head vs pull_head

[Maxim Uvarov]

If you use some Ubuntu version it might be needed to change iptables
default policy to not drop packets in firewall:
https://github.com/Linaro/odp/pull/615/commits/3f0d341faad21b57e3d980f3df5b0b54701c7fbd

On 19 June 2018 at 17:02, Daniel Feferman  wrote:

> Hi All,
>
> Yes, I believe it fits into default headroom.
>
> I see, since I was using MACSAD with v16, I believe I should give v19 a
> try and check it. However, when I asked about IPsec, I asked cause I was
> using v19 and I was still not able to see packets being forwarded. I'll
> check MACSAD with new version and if not I'll go back to IPsec test.
>
> Daniel
>
> On Mon, Jun 18, 2018 at 4:54 PM Bill Fischofer 
> wrote:
>
>> Hi Daniel,
>>
>> ODP support for IPsec was introduced in v1.17.0.0 and is part of the
>> Tiger Moth LTS level of the code (v1.19 series). If your intent is to do
>> things with IPsec I recommend upgrading to that. The current LTS support
>> level is v1.19.0.1. I'm not sure if that will work with MACSAD, but you
>> might want to check.
>>
>> Are you able to see if this level of the code works for you?
>>
>> Thanks.
>>
>> On Mon, Jun 18, 2018 at 2:33 PM, Maxim Uvarov 
>> wrote:
>>
>>> how match do you pull head? Does this value fit into default headroom?
>>>
>>> Maxim.
>>>
>>> On 18 June 2018 at 18:34, Daniel Feferman  wrote:
>>>
>>>> Hi Bill,
>>>>
>>>> Thank you for your answer. Answering your questions:
>>>>
>>>> -v16. odp-linux.
>>>> -It was a Xeon E5, then x86 using a link of up to 10G.
>>>> -I'm new on ODP, I'm currently working on a VXLAN implementation (but we
>>>> similar problem with a BNG use case) using P4 language with this
>>>> compiler
>>>> (which I'm a bit more familiar) that uses ODP:
>>>> https://github.com/intrig-unicamp/macsad
>>>>
>>>> So, you may be right, it may be after APIs are called. However, for
>>>> now, my
>>>> best guess was something known with ODP. I was thinking to run one of
>>>> ODP
>>>> examples with both functions to test the performance and see if I get
>>>> the
>>>> same throughput to discard ODP. I saw this IPsec which seems to use
>>>> both of
>>>> them, but I'm sending packets and it's not forwarding, I've tried the
>>>> "--enable-debug-print" flag but I was not able to figure it out what's
>>>> wrong.
>>>>
>>>> I'm running IPsec using:
>>>>
>>>> ./odp_ipsec -i veth1,veth3,veth5 -m 0
>>>>
>>>> I'm using scapy to send the packet set like:
>>>>
>>>> pkt1 =
>>>> Ether(dst='08:00:27:4C:55:CC',src='08:00:27:76:B5:E0')/IP(
>>>> dst='192.168.111.1',src='192.168.111.2')
>>>>
>>>> And sending it through veth1. Am I doing something wrong? Do you have
>>>> any
>>>> hint about it?
>>>>
>>>> Best,
>>>> Daniel
>>>>
>>>>
>>>> On Mon, Jun 18, 2018 at 11:54 AM Bill Fischofer <
>>>> bill.fischo...@linaro.org>
>>>> wrote:
>>>>
>>>> > Hi Daniel. Can you give a bit more detail?
>>>> >
>>>> > - What version of ODP are you using? Is this the odp-linux or odp-dpdk
>>>> > reference implementations from GitHub or some other implementation?
>>>> > - The platform / system you're running on. x86? Arm? Something else?
>>>> > - A small code snippet / test program illustrating what you're trying
>>>> to
>>>> > do?
>>>> >
>>>> > The push/pull routines should have similar performance
>>>> characteristics.
>>>> > The differences you're observing may be due to what's happening in
>>>> your
>>>> > program after these APIs are called.
>>>> >
>>>> > On Mon, Jun 18, 2018 at 9:35 AM, Daniel Feferman <
>>>> dlfefer...@gmail.com>
>>>> > wrote:
>>>> >
>>>> >> Hi all,
>>>> >>
>>>> >> I'm running a compiler that takes advantage of ODP to allow good
>>>> >> throughput
>>>> >> with portability. However, one of our tests seems to point that
>>>> >> odp_packet_pull_head
>>>> >> strongly impact the performance compared to the "opposite" function (
>>>> >> odp_packet_push_head), I mean a program using push seems have
>>>> considerably
>>>> >> better throughput than the same using pull. Is it a known issue or
>>>> >> something that someone has seen before?
>>>> >>
>>>> >> Furthermore, I'm trying to run IPsec example to test it, but I was
>>>> not
>>>> >> able
>>>> >> to run it with 3 different veth interface, ODP simply does not
>>>> forward the
>>>> >> packet. Do I really need 3 separate VMs to run it or may I use veth
>>>> to set
>>>> >> similar environment?
>>>> >>
>>>> >> Thanks,
>>>> >> Daniel
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>

Re: [lng-odp] push_head vs pull_head

[Maxim Uvarov]

how match do you pull head? Does this value fit into default headroom?

Maxim.

On 18 June 2018 at 18:34, Daniel Feferman  wrote:

> Hi Bill,
>
> Thank you for your answer. Answering your questions:
>
> -v16. odp-linux.
> -It was a Xeon E5, then x86 using a link of up to 10G.
> -I'm new on ODP, I'm currently working on a VXLAN implementation (but we
> similar problem with a BNG use case) using P4 language with this compiler
> (which I'm a bit more familiar) that uses ODP:
> https://github.com/intrig-unicamp/macsad
>
> So, you may be right, it may be after APIs are called. However, for now, my
> best guess was something known with ODP. I was thinking to run one of ODP
> examples with both functions to test the performance and see if I get the
> same throughput to discard ODP. I saw this IPsec which seems to use both of
> them, but I'm sending packets and it's not forwarding, I've tried the
> "--enable-debug-print" flag but I was not able to figure it out what's
> wrong.
>
> I'm running IPsec using:
>
> ./odp_ipsec -i veth1,veth3,veth5 -m 0
>
> I'm using scapy to send the packet set like:
>
> pkt1 =
> Ether(dst='08:00:27:4C:55:CC',src='08:00:27:76:B5:E0')/IP(
> dst='192.168.111.1',src='192.168.111.2')
>
> And sending it through veth1. Am I doing something wrong? Do you have any
> hint about it?
>
> Best,
> Daniel
>
>
> On Mon, Jun 18, 2018 at 11:54 AM Bill Fischofer  >
> wrote:
>
> > Hi Daniel. Can you give a bit more detail?
> >
> > - What version of ODP are you using? Is this the odp-linux or odp-dpdk
> > reference implementations from GitHub or some other implementation?
> > - The platform / system you're running on. x86? Arm? Something else?
> > - A small code snippet / test program illustrating what you're trying to
> > do?
> >
> > The push/pull routines should have similar performance characteristics.
> > The differences you're observing may be due to what's happening in your
> > program after these APIs are called.
> >
> > On Mon, Jun 18, 2018 at 9:35 AM, Daniel Feferman 
> > wrote:
> >
> >> Hi all,
> >>
> >> I'm running a compiler that takes advantage of ODP to allow good
> >> throughput
> >> with portability. However, one of our tests seems to point that
> >> odp_packet_pull_head
> >> strongly impact the performance compared to the "opposite" function (
> >> odp_packet_push_head), I mean a program using push seems have
> considerably
> >> better throughput than the same using pull. Is it a known issue or
> >> something that someone has seen before?
> >>
> >> Furthermore, I'm trying to run IPsec example to test it, but I was not
> >> able
> >> to run it with 3 different veth interface, ODP simply does not forward
> the
> >> packet. Do I really need 3 separate VMs to run it or may I use veth to
> set
> >> similar environment?
> >>
> >> Thanks,
> >> Daniel
> >>
> >
> >
>

[lng-odp] armv8 gcc lock free instructions

[Maxim Uvarov]

Hello Maxim,

we have discussion here that gcc for armv8 does not generated lock free
instructions for 64 bit types. But all other arched do.

https://github.com/Linaro/odp/pull/611

Do you know reasons for that?

Thank you,
Maxim.

Re: [lng-odp] odp tools manpages

[Maxim Uvarov]

shouldn't it be man page for odp library which we somehow can generate from
doxygen?

Where do you package odp examples? I think they have to be somewhere under
/usr/share/bin/odp-examples and just referenced as example apps. (Like QT
examples do). Rather then be "tools".


Maxim.

On 5 June 2018 at 10:46, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> To finish ODP packaging work I have to provide manpages for ODP tools
> that are going to be packages. I've written manpages for odp_hello and
> odp_crypto, however
> I'm asking for the help in writing manpages for l2fwd/l3fwd/generator.
> Could you please help me by sketching clean descriptions of what these
> tools do, that I can put into manpage?
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] Debian package for ODP

[Maxim Uvarov]

Thanks. What are the next steps in upstreaming it to debian? How we can
help with it?

On 28 April 2018 at 20:04, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hi,
>
> On 28 April 2018 at 13:59, Dmitry Eremin-Solenikov
>  wrote:
> > Current package review is handled in Debian bug 896970:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896970
>
> And just for the reference. ODP-DPDK preview (basing on Matias' merge
> branch)
> is also uploaded to mentors.d.n: https://mentors.debian.net/
> package/odp-dpdk
>
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] Debian package for ODP

[Maxim Uvarov]

On 28 April 2018 at 14:38, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> On 28 April 2018 at 14:28, Maxim Uvarov  wrote:
> > Nice,
> >
> > might be better to have common examples with abi-compat mode, so they
> will
> > not depend on platfrom.
>
> Of course packages are built in ABI-compat mode. That is the whole point.
>
>
in that case package name for examples can not include platform name.


> >
> > Maxim.
> >
> > On 28 April 2018 at 13:59, Dmitry Eremin-Solenikov
> >  wrote:
> >>
> >> Hello,
> >>
> >> Current package review is handled in Debian bug 896970:
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896970
> >>
> >> --
> >> With best wishes
> >> Dmitry
> >
> >
>
>
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] TigerMoth_LTS brach

[Maxim Uvarov]

On 28 April 2018 at 14:25, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello, Maxim,
>
> Could you please start pushing pending fixes to tigermoth_lts branch, so
> that
> they can be picked into packaging?
>
>
As we discussed before I plan to release new development tag first and then
cherry-pick commits. In that case we can have good testing for commits
which we are cherry-picking.
For now almost all commits for master can go to tigermoth_lts. Do  you pick
for packaging branch or some specific tag?

Maxim.


> --
> With best wishes
> Dmitry
>

Re: [lng-odp] Debian package for ODP

[Maxim Uvarov]

Nice,

might be better to have common examples with abi-compat mode, so they will
not depend on platfrom.

Maxim.

On 28 April 2018 at 13:59, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> Current package review is handled in Debian bug 896970:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896970
>
> --
> With best wishes
> Dmitry
>

[lng-odp] pull request versions script is broken

[Maxim Uvarov]

Hello,

our host which we use for updating pull request numbers looks like down.
I'm not sure if it will be fixed tomorrow. If not I will do some workaround
for that. Probably move this task inside Travis runs.

Maxim.

Re: [lng-odp] wrong push to master branch was reverted

[Maxim Uvarov]

Reapplied. Fixed.

Thank you,
Maxim.

On 9 April 2018 at 12:32, Peltonen, Janne (Nokia - FI/Espoo) <
janne.pelto...@nokia.com> wrote:

> My repo, to which I pulled from ODP before the odp-dpdk merge happened,
> has the following commit that has not disappeared from the ODP repo. Is it
> intentional? (btw, the commit comment of it may not be totally accurate
> anyway (i.e. does it really fix the bug)):
>
> Janne
>
> commit 273264b459d98140a3c1a217bcea2c7bd680c826 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Josep Puigdemont 
> AuthorDate: Tue Apr 3 09:44:51 2018 +0200
> Commit: Maxim Uvarov 
> CommitDate: Wed Apr 4 15:58:26 2018 +0300
>
> fdserver: handle interruption by signal in accept
>
> This patch fixes: https://bugs.linaro.org/show_bug.cgi?id=3690
>
> Suggested-by: Janne Peltonen 
> Signed-off-by: Josep Puigdemont 
> Reviewed-by: Bill Fischofer 
> Signed-off-by: Maxim Uvarov 
>
>
>
> > -Original Message-----
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Maxim Uvarov
> > Sent: Monday, April 09, 2018 10:37 AM
> > To: LNG ODP Mailman List 
> > Subject: [lng-odp] wrong push to master branch was reverted
> >
> > Colleagues,
> >
> > I'm apologize of wrong push to master branch. On had new environment and
> > wrongly pushed odp-dpdk changes to master branch. (pushed to wrong git
> > remote). Then I quickly corrected that with force push. I hope current
> > history is good as it was before. But if you used automatic pulls from
> > master it's needed to rebase.
> >
> > I apologize for that accident.
> >
> > Maxim.
>

[lng-odp] wrong push to master branch was reverted

[Maxim Uvarov]

Colleagues,

I'm apologize of wrong push to master branch. On had new environment and
wrongly pushed odp-dpdk changes to master branch. (pushed to wrong git
remote). Then I quickly corrected that with force push. I hope current
history is good as it was before. But if you used automatic pulls from
master it's needed to rebase.

I apologize for that accident.

Maxim.

Re: [lng-odp] release

[Maxim Uvarov]

docker run -i -t 5b1f9964e594 /bin/bash
apt-get update
apt-get install git
git clone https://github.com/Linaro/odp.git
./bootstrap
./configure --disable-test-perf --disable-test-perf-proc
make -j 8
export ODP_SCHEDULER=scalable
./helper/test/cuckootable
works!

./configure --disable-test-perf --disable-test-perf-proc CFLAGS="-O0 -g"
./helper/test/cuckootable
hungs!

export ODP_SCHEDULER=basic
./helper/test/cuckootable
works again!


On 13 March 2018 at 10:34, Maxim Uvarov  wrote:

> CC odp ML for this issue.
>
> Maxim.
>
> On 13 March 2018 at 03:33, Bill Fischofer 
> wrote:
>
>> Additional details.
>>
>> __atomic_load_n() is a GCC intrinsic, however __lockfree_load_16() is
>> defined in platform/linux-generic/arch/aarch64/odp_atomic.h:
>>
>> static inline __int128 __lockfree_load_16(__int128 *var, int mo)
>> {
>> __int128 old = *var; /* Possibly torn read */
>>
>> /* Do CAS to ensure atomicity
>>  * Either CAS succeeds (writing back the same value)
>>  * Or CAS fails and returns the old value (atomic read)
>>  */
>> (void)__lockfree_compare_exchange_16(var, &old, old, false, mo,
>> mo);
>> return old;
>> }
>>
>> As is __lockfree_compare_exchange_16():
>>
>> static inline bool
>> __lockfree_compare_exchange_16(register __int128 *var, __int128 *exp,
>>register __int128 neu, bool weak, int mo_success,
>>int mo_failure)
>> {
>> (void)weak; /* Always do strong CAS or we can't perform atomic read */
>> /* Ignore memory ordering for failure, memory order for
>> * success must be stronger or equal. */
>> (void)mo_failure;
>> register __int128 old;
>> register __int128 expected;
>> int ll_mo = LL_MO(mo_success);
>> int sc_mo = SC_MO(mo_success);
>>
>> expected = *exp;
>> __asm__ volatile("" ::: "memory");
>> do {
>> /* Atomicity of LLD is not guaranteed */
>> old = lld(var, ll_mo);
>> /* Must write back neu or old to verify atomicity of LLD */
>> } while (odp_unlikely(scd(var, old == expected ? neu : old, sc_mo)));
>> *exp = old; /* Always update, atomically read value */
>> return old == expected;
>> }
>>
>> In turn lld() and scd() are defined in platform/linux-generic/arch/aa
>> rch64/odp_llsc.h:
>>
>> static inline __int128 lld(__int128 *var, int mm)
>> {
>> union i128 old;
>>
>> if (mm == __ATOMIC_ACQUIRE)
>> __asm__ volatile("ldaxp %0, %1, [%2]"
>> : "=&r" (old.i64[0]), "=&r" (old.i64[1])
>> : "r" (var)
>> : "memory");
>> else if (mm == __ATOMIC_RELAXED)
>> __asm__ volatile("ldxp %0, %1, [%2]"
>> : "=&r" (old.i64[0]), "=&r" (old.i64[1])
>> : "r" (var)
>> : );
>> else
>> ODP_ABORT();
>> return old.i128;
>> }
>>
>> /* Return 0 on success, 1 on failure */
>> static inline uint32_t scd(__int128 *var, __int128 neu, int mm)
>> {
>> uint32_t ret;
>>
>> if (mm == __ATOMIC_RELEASE)
>> __asm__ volatile("stlxp %w0, %1, %2, [%3]"
>> : "=&r" (ret)
>> : "r" (((union i128)neu).i64[0]),
>>"r" (((union i128)neu).i64[1]),
>>"r" (var)
>> : "memory");
>> else if (mm == __ATOMIC_RELAXED)
>> __asm__ volatile("stxp %w0, %1, %2, [%3]"
>> : "=&r" (ret)
>> : "r" (((union i128)neu).i64[0]),
>>"r" (((union i128)neu).i64[1]),
>>"r" (var)
>> : );
>> else
>> ODP_ABORT();
>> return ret;
>> }
>>
>> So these boil down to a sequence of __asm__() instructions. If these are
>> hanging it suggests a compiler issue. Does this occur with a newer GCC
>> level?
>>
>> On Mon, Mar 12, 2018 at 5:21 PM, Maxim Uvarov 
>> wrote:
>>
>>> gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/4.8/lto-wrapper
>>> Target: aarch64-linux-gnu
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
>>> 4.8.5-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
>>> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
>>> --program-suffix=-4.8 --enable-shared --enable-linker-build-id
>>> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
>>> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/u

Re: [lng-odp] release

[Maxim Uvarov]

CC odp ML for this issue.

Maxim.

On 13 March 2018 at 03:33, Bill Fischofer  wrote:

> Additional details.
>
> __atomic_load_n() is a GCC intrinsic, however __lockfree_load_16() is
> defined in platform/linux-generic/arch/aarch64/odp_atomic.h:
>
> static inline __int128 __lockfree_load_16(__int128 *var, int mo)
> {
> __int128 old = *var; /* Possibly torn read */
>
> /* Do CAS to ensure atomicity
>  * Either CAS succeeds (writing back the same value)
>  * Or CAS fails and returns the old value (atomic read)
>  */
> (void)__lockfree_compare_exchange_16(var, &old, old, false, mo,
> mo);
> return old;
> }
>
> As is __lockfree_compare_exchange_16():
>
> static inline bool
> __lockfree_compare_exchange_16(register __int128 *var, __int128 *exp,
>register __int128 neu, bool weak, int mo_success,
>int mo_failure)
> {
> (void)weak; /* Always do strong CAS or we can't perform atomic read */
> /* Ignore memory ordering for failure, memory order for
> * success must be stronger or equal. */
> (void)mo_failure;
> register __int128 old;
> register __int128 expected;
> int ll_mo = LL_MO(mo_success);
> int sc_mo = SC_MO(mo_success);
>
> expected = *exp;
> __asm__ volatile("" ::: "memory");
> do {
> /* Atomicity of LLD is not guaranteed */
> old = lld(var, ll_mo);
> /* Must write back neu or old to verify atomicity of LLD */
> } while (odp_unlikely(scd(var, old == expected ? neu : old, sc_mo)));
> *exp = old; /* Always update, atomically read value */
> return old == expected;
> }
>
> In turn lld() and scd() are defined in platform/linux-generic/arch/
> aarch64/odp_llsc.h:
>
> static inline __int128 lld(__int128 *var, int mm)
> {
> union i128 old;
>
> if (mm == __ATOMIC_ACQUIRE)
> __asm__ volatile("ldaxp %0, %1, [%2]"
> : "=&r" (old.i64[0]), "=&r" (old.i64[1])
> : "r" (var)
> : "memory");
> else if (mm == __ATOMIC_RELAXED)
> __asm__ volatile("ldxp %0, %1, [%2]"
> : "=&r" (old.i64[0]), "=&r" (old.i64[1])
> : "r" (var)
> : );
> else
> ODP_ABORT();
> return old.i128;
> }
>
> /* Return 0 on success, 1 on failure */
> static inline uint32_t scd(__int128 *var, __int128 neu, int mm)
> {
> uint32_t ret;
>
> if (mm == __ATOMIC_RELEASE)
> __asm__ volatile("stlxp %w0, %1, %2, [%3]"
> : "=&r" (ret)
> : "r" (((union i128)neu).i64[0]),
>"r" (((union i128)neu).i64[1]),
>"r" (var)
> : "memory");
> else if (mm == __ATOMIC_RELAXED)
> __asm__ volatile("stxp %w0, %1, %2, [%3]"
> : "=&r" (ret)
> : "r" (((union i128)neu).i64[0]),
>"r" (((union i128)neu).i64[1]),
>"r" (var)
> : );
> else
> ODP_ABORT();
> return ret;
> }
>
> So these boil down to a sequence of __asm__() instructions. If these are
> hanging it suggests a compiler issue. Does this occur with a newer GCC
> level?
>
> On Mon, Mar 12, 2018 at 5:21 PM, Maxim Uvarov 
> wrote:
>
>> gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/4.8/lto-wrapper
>> Target: aarch64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
>> 4.8.5-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
>> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
>> --program-suffix=-4.8 --enable-shared --enable-linker-build-id
>> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
>> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
>> --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
>> --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
>> --disable-libsanitizer --disable-libquadmath --enable-plugin
>> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>> --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-arm64/jre
>> --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-arm64
>> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-arm64
>> --with-arch-directory=arm64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>> --enable-multiarch --disable-werror --enable-checking=release
>> --build=aarch64-linux-gnu --host=aarch64-linux-gnu
>> --target=aarch64-linux-gnu
>> Thread model: posix
>> gcc version 4.8.5 (Ubuntu/Linaro 4.8.5-4ubuntu2)
>>
>> On 13 March 2018 at 00:20, Maxi

[lng-odp] api-next branch force updated

[Maxim Uvarov]

Hello,

api-next branch is forced update to current master. Please audjust that in
your PR. Backup is here:
https://github.com/muvarov/odp/tree/api-next_1.18_backup

Thank you,
Maxim.

Re: [lng-odp] Shippable: no test reports

[Maxim Uvarov]

has now to be fixed.

On 28 February 2018 at 18:04, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> Just for your info: currently Shippable fails to generate test reports
> due to one of the system files being compiled for the wrong
> architecture. I've opened an issue at
> https://github.com/Shippable/support/issues/4157
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] ODP release tarballs

[Maxim Uvarov]

github automacitally creates tar balls for tags:
https://github.com/Linaro/odp/releases

is that what is needed?

On 28 February 2018 at 08:18, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> I have been looking for tarballs from previous ODP releases. Do we put
> them somewhere for downloading (we should, in my opinion)?
>
> GitHub releases might be an interesting option to host releases, however
> we should not that currently they provide a way to download git tree
> snapshot, rather than 'make dist' tarball.
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] Clang + AArch64 + non-ABI workaround

[Maxim Uvarov]

On 02/16/18 21:47, Dmitry Eremin-Solenikov wrote:
> On 16 February 2018 at 18:26, Maxim Uvarov  wrote:
>> can you link to problem description? is it segfault here?
> 
> https://bugs.linaro.org/show_bug.cgi?id=3611
> 

but it has to fail.
as I said /dev/shm under docker (which uses shippable) is limited to
64Mb by default.

we run: ODP_SHM_DIR=/dev/shm/odp make check

So it creates files (alloc shared memory) in that directory. Helpers
like cuckoohash use more then 64Mb memory to build hash table. It
allocates memory but on access there is seg. fault.

I think ODP_SHM_DIR=/var make check has to work here.

But it's not clear how it's related to this patch.

Maxim.

>>
>> On 16 February 2018 at 17:54, Dmitry Eremin-Solenikov
>>  wrote:
>>>
>>> Hello,
>>>
>>> I've been debugging the Clang/AArch64/non-ABI case during this week.
>>>
>>> It indeed is a compiler issue. Here is a workaround, which fixes the
>>> issue for at least clang 7 (did not try with earlier versions, probably
>>> it would also help). At this moment I do not think we should apply this
>>> fix, but rather declare this combination as not supported. Our code is
>>> perfectly valid from my POV.
>>>
>>> diff --git a/platform/linux-generic/odp_pool.c
>>> b/platform/linux-generic/odp_pool.c
>>> index e5ba8982a29a..a97d096d1a53 100644
>>> --- a/platform/linux-generic/odp_pool.c
>>> +++ b/platform/linux-generic/odp_pool.c
>>> @@ -727,12 +727,13 @@ int buffer_alloc_multi(pool_t *pool,
>>> odp_buffer_hdr_t *buf_hdr[], int max_num)
>>> buf_hdr[i] = buf_hdr_from_index(pool,
>>> cache->buf_index[j]);
>>> }
>>>
>>> -   /* If needed, get more from the global pool */
>>> -   if (odp_unlikely(num_deq)) {
>>> /* Temporary copy needed since odp_buffer_t is uintptr_t
>>>  * and not uint32_t. */
>>> uint32_t data[burst];
>>>
>>> +   /* If needed, get more from the global pool */
>>> +   if (odp_unlikely(num_deq)) {
>>> +
>>> ring  = &pool->ring->hdr;
>>> mask  = pool->ring_mask;
>>> burst = ring_deq_multi(ring, mask, data, burst);
>>>
>>>
>>> --
>>> With best wishes
>>> Dmitry
>>
>>
> 
> 
> 

Re: [lng-odp] Clang + AArch64 + non-ABI workaround

[Maxim Uvarov]

can you link to problem description? is it segfault here?

On 16 February 2018 at 17:54, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> Hello,
>
> I've been debugging the Clang/AArch64/non-ABI case during this week.
>
> It indeed is a compiler issue. Here is a workaround, which fixes the
> issue for at least clang 7 (did not try with earlier versions, probably
> it would also help). At this moment I do not think we should apply this
> fix, but rather declare this combination as not supported. Our code is
> perfectly valid from my POV.
>
> diff --git a/platform/linux-generic/odp_pool.c
> b/platform/linux-generic/odp_pool.c
> index e5ba8982a29a..a97d096d1a53 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -727,12 +727,13 @@ int buffer_alloc_multi(pool_t *pool,
> odp_buffer_hdr_t *buf_hdr[], int max_num)
> buf_hdr[i] = buf_hdr_from_index(pool, cache->buf_index[j]);
> }
>
> -   /* If needed, get more from the global pool */
> -   if (odp_unlikely(num_deq)) {
> /* Temporary copy needed since odp_buffer_t is uintptr_t
>  * and not uint32_t. */
> uint32_t data[burst];
>
> +   /* If needed, get more from the global pool */
> +   if (odp_unlikely(num_deq)) {
> +
> ring  = &pool->ring->hdr;
> mask  = pool->ring_mask;
> burst = ring_deq_multi(ring, mask, data, burst);
>
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] odp_packet_data() considered harmful

[Maxim Uvarov]

pool can have segments layout in it's capabilities and if needed on thread
creating we can check that odp_packet_data() will not be uses cross
segments.

Maxim.

On 15 February 2018 at 17:42, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>
> > -Original Message-
> > From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
> > Sent: Thursday, February 15, 2018 4:00 PM
> > To: Savolainen, Petri (Nokia - FI/Espoo) ;
> > Bill Fischofer 
> > Cc: lng-odp-forward 
> > Subject: Re: [lng-odp] odp_packet_data() considered harmful
> >
> > On 15/02/18 16:32, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> > > odp_packet_offset() is more complex than the proposed
> > odp_packet_data_seg_len(). Application mostly finds its data from the
> > first segment, so it's important to keep the most common use case fast
> (==
> > simple). We cannot and should not modify/remove current data() and
> > offset() functions. But we can add another which combines data() +
> > seg_len(), which is mostly enough for application. When application knows
> > already that all (interesting) data is in the first segment, it can use
> > data() which is the fastest and simplest function (to inline) to get
> > access to the data.
> >
> > I'm fine with proposed odp_packet_data_seg_len() if that will allow us
> > to drop odp_packet_data().
>
> There's no need or possibility to remove data(). Documentation for data()
> may be improved to be more explicit about possibility of multiple segments.
> The function just returns pointer to current head of data, it does not
> promise anything more. When application knows already how much data follows
> (and usually all data follows), it does not need ask e.g. segment length
> over and over again.
>
> static inline void* odp_packet_data(pkt) {
> return (pkt_desc_t)pkt->data_ptr;
> }
>
> static inline void* odp_packet_data_seg_len(pkt, *len) {
> *len = (pkt_desc_t)pkt->seg_len;
> return (pkt_desc_t)pkt->data_ptr;
> }
>
> The first is faster when application does not need to ask the segment
> length.
>
> -Petri
>
>

Re: [lng-odp] Compilation flags for release build and performance evaluation

[Maxim Uvarov]

./configure --help

for linux-generic and linux-dpdk platforms.

Maxim.

On 31 January 2018 at 22:41, gyanesh patra  wrote:

> Hi,
> I am curious if there are any specific flags available for ODP for release
> builds or performance evaluation?
>
> Also where can i find the list of features i can disable by passing to
> configure scripts? I found couple of options in odp-thunderx project such
> as  "-DODP_DISABLE_CLASSIFICATION and -DNIC_DISABLE_PACKET_PARSING".
> Is there any other such flags available?
>
> Thank you,
> P Gyanesh Kumar Patra
>

Re: [lng-odp] problem about packet_alloc() function.

[Maxim Uvarov]

CC lng-odp-dpdk mailing list.

On 26 January 2018 at 04:27, lin huang  wrote:

> Hi all,
> I checked the code of odp-dpdk. And I got a problem which confused me
> a lot.
> In the function packet_alloc(), odp tried to alloc a buffer which
> originated from the mbuf at the dpdk memory pool.
> After that, rte_pktmbuf_alloc() got a pointer which ponted to the
> beginning of mbuf structures.
> Then the code just changed the pointer to point to odp_packet_hdr_t type.
> Is there something wrong?? Or rte_mempool_create() has done some magic
> work before alloc the mbuf??
> rte_mbuf: +==+
> ===++===+
> |   rte_mbuf|   RTE_PKTMBUF_HEADROOM
>   | pkt data| RTE_PKTMBUF_TRAILROOM |
> +==+
> ===++===+
> mbuf = rte_pktmbuf_alloc(pool->s.rte_mempool);
> if (mbuf == NULL) {
> rte_errno = ENOMEM;
> return ODP_PACKET_INVALID;
> }
> pkt_hdr = (odp_packet_hdr_t *)mbuf;
> pkt_hdr->buf_hdr.totsize = mbuf->buf_len;
>

[lng-odp] odp git procedure

[Maxim Uvarov]

Hello,

after some talks we came to agreement that one of the major thing for
odp is it's validation over CI. So for now we decided to keep current
scheme of work. I.e. patches which do not touch api go to master and api
patches go to api-next branch.

To make git maintenance more easy we will rebase api-next branch on top
of the latest development release. I.e. just after we do development
release in master branch we rebase api-next branch. That will require to
do rebase of pending pull requests on github. This can happen once per
month or one per two months. Depend how often we will do releases.
Please take in account in your scripts that direct pull from api-next
might not work.

Also we are thinking about upgrade number of parallel Travis jobs. Now
we have demo period to upgrade from 5 to 15 parallel ci jobs. That will
work for a day. So we can test it and decide if it's needed for us.

One other thing which is worth to mention is usage of Travis in private
repositories. Travis runs are long and each PR needs it's own round of
CI. Please test your changes locally on private github clones before you
open PR. If you need to do some small change after you opened PR, second
CI job will be queued just after first one. So we will do one CI run for
nothing.

Best regards,
Maxim.

Re: [lng-odp] problem about odp-ovs(with dpdk)

[Maxim Uvarov]

On 01/16/18 10:35, lin huang wrote:
> Hi guys,
>I get a problem when I try to use odp-ovs with odp-dpdk.
> I compiled the odp-dpdk and odp-ovs successfully. and then I want to try add 
> a port to ovs bridge with the following command:
> 
> ovs-vsctl add-port br0 odp:enp0s8 -- set Interface odp:enp0s8 type=odp
> 
> these commands work properly when I use odp-ovs with odp-linux.
> But when I input these command when I use odp-ovs with odp-dpdk it failed.
> 
> The ovs-vswitchd.log content:
> root@vagrant:/usr/local/bin# tail 
> /usr/local/var/log/openvswitch/ovs-vswitchd.log
> 2018-01-16T07:09:51.384Z|00049|bridge|WARN|could not open network device 
> odp:enp0s8 (Address family not supported by protocol)
> 2018-01-16T07:10:04.683Z|00050|odp|ERR|../linux-generic/odp_packet_io.c:226:setup_pktio_entry():Unable
>  to init any I/O type.
> 2018-01-16T07:10:04.683Z|00051|odp|ERR|Error: odp_pktio_open() failed
> 2018-01-16T07:10:04.685Z|00052|bridge|WARN|could not open network device 
> odp:enp0s8 (No such file or directory)
> 
> So, are there somebody knows how it work?? Or how to configure it???
> I need you help
> 
> Thank you very much!!
> 

In dpdk interfaces names are numbers 0, 1, 2. And you need
dpdk-devbind.py to move nic from linux mode to kernel mode.
You can find example how to do it from this log:
https://lng.validation.linaro.org/scheduler/job/23296.1

Best regards,
Maxim.

[lng-odp] api-next history was rewritten

[Maxim Uvarov]

git push -f to api-next branch. Because of code is similar to master
there is no need to have branch with not plain history (merge from
master to api-next and back). As a side affect old PRs for api-next
branch look ugly in github web interface because they have now different
merge points. To review it's better to follow to original(personal) git
an see top commits.

old api-next branch is here:
https://github.com/muvarov/odp/tree/api-next_save_2018_01_15

BR,
Maxim.

Re: [lng-odp] Travis runs not being linked from PRs?

[Maxim Uvarov]

On 01/12/18 20:27, Bill Fischofer wrote:
> Looks like something changed in the GitHub scripts. The link to the Travis
> run from the PR is no longer present. This is not good.
> 

For last 2 prs 338 and 339 everything is ok. Bor 339 I needed to scroll
down frame window with results.

Maxim.

[lng-odp] Tiger Moth rc1 has been tagged

[Maxim Uvarov]

Hello team,


I put 2 tags to repo it's v1.17.0.0 and v1.17.0.0_tigermoth_rc1.

ODP API changes are really big can be found in CHANGELOG for
corresponding tag or in this email bellow:

https://github.com/Linaro/odp/blob/master/CHANGELOG

All api changes from api-next branch went to master branch. The only
thing which was not merged it modules support (including dependency on
libconfig, travis changes and etc.). That will be subject for
Caterpillar branch.

I also see some refinements in PRs which will be go to next rc2 release.

Also I would like to rewrite history of api-next. And git push -f master
there. There will be no code change. But history will be more plain (no
merges from master and back).

Best regards,
Maxim.

== OpenDataPlane (1.17.0.0)
=== New Features
ODP v1.17.0.0 is Tiger Moth Release Candidate 1 (RC 1). It introduces
significant new API support as well as functional refinements that expand
ODP offload support to cover IPsec, as well as other improvements.

 APIs
The following new and changed APIs are included in this release:

= Event Extensions
The ODP event model has been expanded to include new types as well as event
subtypes. Subtypes are used to qualify an event by indicating that the event
carries additional metadata relating to specific usage or operations.

New event `ODP_EVENT_IPSEC_STATUS` (to be discussed
below) is added. The initial subtypes defined are: `ODP_EVENT_PACKET_BASIC`,
`ODP_EVENT_PACKET_CRYPTO`, `ODP_EVENT_PACKET_IPSEC`, and
`ODP_EVENT_NO_SUBTYPE`, which are also discussed below.

Associated with this support, new event APIs are added:

* `odp_event_subtype()` extracts the `odp_event_subtype_t` from an
`odp_event_t`.

* `odp_event_types()` returns the `odp_event_type_t` and
`odp_event_subtype_t`
of an `odp_event_t` in a single call.

* `odp_event_type_multi()` scans a list of `odp_event_t` objects and returns
the number that share the same indicated `odp_event_type_t`. This allows
multiple events to be processed by groups of the same event type.

* `odp_event_filter_packet()` scans a list of `odp_event_t` objects and
partitions them into a returned array of `odp_packet_t` objects and a
remaining
array of non-packet events.

* `odp_event_free_multi()` frees multiple events in a single call.

* `odp_event_free_sp()` frees multiple events originating from the same
pool in a single call. The caller must assure that the input events are from
the same pool.

= IPsec support
ODP Tiger Moth introduces comprehensive protocol offload support for IPsec,
allowing applications to leverage the IPsec acceleration capabilities of
many
SoCs. Support includes APIs for Security Association (SA) creation and
lifecycle management, as well as IPsec packet operations for inbound
(RX) and
outbound (TX) processing. Packet operations are further divided into
lookaside
and inline support.

== Lookaside Support
Lookaside processing enables IPsec packets to be decrypted into plain
packets
or plain packets to be encrypted into IPsec packets in a single
operation under
explicit application control. This is useful for packets that need pre- or
post-processing, or to better fit with existing application design.

Two forms of lookaside processing are provided: the `odp_ipsec_in()` and
`odp_ipsec_out()` APIs provide synchronous decrypt and encrypt support,
respectively. The corresponding `odp_ipsec_in_enq()` and
`odp_ipsec_out_enq()`
APIs provide these same services in asynchronous form where operations
can be
launched and completed later.

== Inline Support
In contrast to lookaside support, IPsec inline support permits
applications to
fully leverage the offload capabilities found in many SoCs by allowing
inbound
IPsec packets to be recognized and decrypted automatically before they are
presented to the application for processing. This is done by configuring a
Security Association (SA) and its associated PktIO to operate in inline
mode.

Similarly, following output SA and PktIO configuration, the
`odp_ipsec_out_inline()` API permits a packet to be encrypted into an IPsec
packet and automatically scheduled for TX processing in a single
operation. Such "fire and forget" processing enables applications to
leverage
IPsec HW support for such processing in a portable manner.

Applications using IPsec inline support need only "touch" a packet once
compared to three times when using lookaside processing, leading to greater
processing efficiency.

== IPsec Events
New event types and subtypes are introduced to provide support for IPsec
processing. The `ODP_EVENT_PACKET` type has a new subtype:
`ODP_EVENT_PACKET_IPSEC` that provides extended metadata associated with
IPsec packets that have been processed. The new `ODP_EVENT_IPSEC_STATUS`
event, in turn, is used to report IPsec status events such as completion
notifications associated with `odp_ipsec_sa_disable()` calls.

The `odp_ipsec_result()` API is used to obtain IPsec result metadata from
a packet that has event subtype `ODP_EVENT_

[lng-odp] API add queue hdl to odp_pktin_wait_time()

[Maxim Uvarov]

>From PR discission https://github.com/Linaro/odp/pull/341:

There is some reason to clean up odp_pktin_wait_time() api.

1.
There is suggestion to add queue to odp_pktin_wait_time() function.
I.e.:
uint64_t odp_pktin_wait_time(uint64_t nsec, odp_pktin_queue_t  queue);

Idea is that queue handler can be used to get access to pktio and his pktio
driver.
Driver can do transformation from nanosecond to some values which is more
suitable and return
this driver or adjust the queue. So return value can be different for
different drivers and we can
speed up code here.

2.
Second idea is to completely remove wait parameter from
odp_pktin_recv_tmo() and queue handler to odp_pktin_wait_time() as
describer before. If we assume that one thread calls odp_pktin_recv_tmo()
and more likely with the same predefined timeout. Then there is no sense in
always passing it to odp_pktin_recv_tmo().

/**
 * Packet input wait time
 *
 * Converts nanoseconds to wait time values for packet input functions.
 *
 * @param nsec   Minimum number of nanoseconds to wait
 *
 * @return Wait parameter value for packet input functions
 */
uint64_t odp_pktin_wait_time(uint64_t nsec);


 * @param  wait   Wait time specified as as follows:
 ** ODP_PKTIN_NO_WAIT: Do not wait
 ** ODP_PKTIN_WAIT:Wait infinitely
 ** Other values specify the minimum time to wait.
 *  Use odp_pktin_wait_time() to convert nanoseconds
 *  to a valid parameter value. Wait time may be
 *  rounded up a small, platform specific amount.

int odp_pktin_recv_tmo(odp_pktin_queue_t queue, odp_packet_t packets[],
   int num, uint64_t wait);


best regards,
Maxim.

Re: [lng-odp] ODP development process proposal

[Maxim Uvarov]

Both 1 and 2 are workable models which are more easy to maintain.
Unfortunately we did not agree to use it at the beginning. I would be
happy if we can reconsider our work-flow. One direction will make it
more easy to work.

Maxim.

On 12/27/17 21:16, Bala Manoharan wrote:
> My two cents
>
> I personally prefer Proposal 1, since it provides a single branch
> (api-next)  which gives me a snapshot of the future of master branch.
> In case of proposal 2, let's say there are two different branches/PR
> for API changes in pktio and queue we will not know how they will look
> together until both get merged into the master.
>
> Regards,
> Bala
>
> On 27 December 2017 at 19:52, Bill Fischofer 
> wrote:
>
>> Thanks Dmitry. This is a good and timely topic, given both the Tiger Moth
>> RC series now starting as well as the Caterpillar development work that
>> we're going to start absorbing.
>>
>> I suspect Proposal 2 is the more flexible one, but we need to define the
>> scope of these "topics" better than we've done in the past. We should get
>> initial thoughts here and discuss next week when we resume the ARCH calls.
>>
>> On Wed, Dec 27, 2017 at 8:10 AM, Dmitry Eremin-Solenikov <
>> dmitry.ereminsoleni...@linaro.org> wrote:
>>
>>> Hello colleagues,
>>>
>>> Basing on issues we had with TigerMoth next branch, I have summarized
>>> two following proposals to ease api-next/master/next relations.
>>>
>>> Main goals:
>>>  - Remove need to merge regularly master to api-next, which complicates
>>> development of api-next
>>>  - Streamline patch flow. They should follow one direction, not multiple
>>> controversial directions
>>>  - Let everybody easily get list of changes pending for next release
>>>
>>> Proposal 1
>>> ==
>>>
>>>  - All changes get posted via GitHub pull requests or patch series on
>>> mail list
>>>  - Once approved, change is applied to 'api-next' branch
>>>  - If change is applicable to current release and is not an API change,
>>> it can get backported to 'master' branch via cherry-picking
>>>  - Before release 'next' branch is spawned from 'master' branch
>>>  - 'next' branch receives changes from 'api-next' that are mature enough
>>> to go to next release
>>>  - For release changes from 'next' are merged into 'master', commit is
>>> tagged
>>>  - After that api-next gets rebased on top of 'master' branch
>>>
>>> Proposal 2
>>> ==
>>>
>>>  - All changes get posted via GitHub pull requests or patch series on
>>> mail list
>>>  - All non-API changes are merged into 'master' branch
>>>  - All API changes live in topic development branches/PRs till they are
>>> thought to be mature enough to get merged into 'master' branch
>>>  - Release happens directly from 'master' branch
>>>
>>> --
>>> With best wishes
>>> Dmitry
>>>
>>

Re: [lng-odp] IPsec and crypto performance and OpenSSL

[Maxim Uvarov]

odp_init_global() allocates shm, then odp_init_local() / odp_term_local()
allocates/destroys per thread contexts in array in that shm. I think that
has to work.

Maxim.

On 11 December 2017 at 17:02, Francois Ozog 
wrote:

> I favor finishing ODP (ex 2.0) integration rather than optimizing
> linux-generic at this stage.
>
> On 11 December 2017 at 14:39, Peltonen, Janne (Nokia - FI/Espoo) <
> janne.pelto...@nokia.com> wrote:
>
> > Hi,
> >
> > When playing with IPsec I noticed that the Linux generic
> > ODP implementation creates a separate OpenSSL crypto context
> > for each crypto-operation as opposed to doing it at ODP
> > crypto session creation. With IPsec this adds a lot of
> > overhead for every packet processed and significantly
> > reduces packet throughput.
> >
> > I wonder what, if anything, should be done about it.
> >
> > I already almost sent a patch to create and initialize
> > crypto contexts only once per session but realized that
> > it is not that easy.
> >
> > Here are some alternatives that came to my mind, but all
> > of them have their own problems:
> >
> > a) Create per-thread OpenSSL contexts at crypto session
> >creation time.
> >- Does not work with ODP threads that do not share
> >  their address space since OpenSSL is allocating
> >  memory through malloc() during context creation.
> >
> > b) Do a) plus provide OpenSSL a custom memory allocator
> >on top of shared memory.
> >- There is no generic heap allocator in ODP code base.
> >
> > c) Create per-thread contexts lazily when needed.
> >- Creation would work as it would happen in the right
> >  thread but there would be no way to delete the
> >  contexts. The thread destroying the ODP crypto
> >  session cannot delete the per-thread contexts that
> >  might reside in a different address spaces. That
> >  thread could ask every other thread to do the
> >  per-thread cleanup, except that there is no mechanism
> >  for that without application assistance or big
> >  changes in the generic ODP code.
> >
> > d) Create a limited-size cache of per-thread contexts.
> >- This would allow postponing the deletion of each
> >  context either to the point the cache slot needs
> >  to be reused or all the way to ODP termination,
> >  both occuring in the right thread. But this is
> >  getting complicated and sizing the cache is nasty.
> >
> > Any thoughts?
> >
> > Janne
> >
> >
> >
>
>
> --
> [image: Linaro] 
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>

Re: [lng-odp] New API to convert user area ptr to odp_packet_t

[Maxim Uvarov]

I did not understand one moment there.

What I understand is:
1. you created pool with some size of meta data.
2. you get or alloc packet and send it to VPP.
3. VPP returns back pointer to user data.

Why you can not place packet handle inside user area then? Is it cache
line problem?

If VPP allocates some packet memory which is has pointer to user area
then it wants to send it to ODP. Then how this memory was allocated?

Best regards,
Maxim.

On 12/09/17 15:53, Francois Ozog wrote:
> I'd like to have SoC vendors feedback on the discussion and on the
> following:
> 
> This ODP user area is used by VPP to put a vlib_buffer information. VPP is
> just one of the applications that will use this simple mechanism and that
> is certainly a design pattern.
> 
> A user area can exist when an odp packet is in the host, that is it has
> been received on a special queue.
> The odp_packet_t must be from a pool whose user_area size is big enough to
> hold such meta-data
> 
> today we have
> void *odp_packet_user_area(odp_packet_t pkt);
> uint32_t odp_packet_user_area_size(odp_packet_t pkt);
> 
> So the question is, can we have:
> odp_packet_t pkt odp_packet_from_user_area(void * user_area);
> 
> 
> 
> 1) I wonder though if all user area calls should't be associated to the
> mempool that was configured with the desired user_area size.
> 2) implementation assessment:
> 
>- Cavium and NXP have formed odp_packet_t as physical address and
>additional bits. So their implementation can be fairly optimized by
>calculation if user_area is allocated consecutively to the packet buffer
>- linux generic can have its own way of dealing with it.
>- odp_dpdk can implement it the way Michal mentioned
>- ODP with DDF can use calculation of odp_buffer_t the same way DPDK does
> 
> 
> I strongly think that the proposed API is a must in the design pattern
> related to user_areas. That is, it is NOT specific to VPP.
> 
> There cannot be a single way to implement way due to the ODP nature, every
> implementation have to deal with it in its own way.
> 
> I guess it it is not possible under some implementations to do it by
> calculation. In that case the new API impose an implementation change that
> may be based on a hash table (because user area may not be contiguous to
> buffer). That looks bad but at least that is generic implementation.
> Alternatively, it may be said that this function can return NULL on some
> platforms. It will just prevent some applications to run on those
> platforms. Which is also a design choice that would push the upper layers
> to add the information (odp_packet_t in our case) in their meta data
> (blib_buffer in the case of VPP) to be compatible.
> 
> FF
> 
> On 8 December 2017 at 22:55, Bill Fischofer 
> wrote:
> 
>> On Fri, Dec 8, 2017 at 2:49 PM, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> wrote:
>>
>>> On 8 December 2017 at 13:40, Bill Fischofer 
>>> wrote:


 On Fri, Dec 8, 2017 at 1:06 PM, Honnappa Nagarahalli
  wrote:
>
> On 7 December 2017 at 22:36, Bill Fischofer <
>> bill.fischo...@linaro.org>
> wrote:
>>
>>
>> On Thu, Dec 7, 2017 at 10:12 PM, Honnappa Nagarahalli
>>  wrote:
>>>
>>> On 7 December 2017 at 17:36, Bill Fischofer <
>>> bill.fischo...@linaro.org>
>>> wrote:


 On Thu, Dec 7, 2017 at 3:17 PM, Honnappa Nagarahalli
  wrote:
>
> This experiment clearly shows the need for providing an API in
>>> ODP.
>
> On ODP2.0 implementations such an API will be simple enough
> (constant
> subtraction), requiring no additional storage in VLIB.
>
> Michal, can you send a PR to ODP for the API so that we can
>> debate
> the
> feasibility of the API for Cavium/NXP platforms.


 That's the point. An API that is tailored to a specific
 implementation
 or
 application is not what ODP is about.

>>> How are the requirements coming to ODP APIs currently? My
>>> understanding is, it is coming from OFP and Petri's requirements.
>>> Similarly, VPP is also an application of ODP. Recently, Arm
>> community
>>> (Arm and partners) prioritized on the open source projects that are
>>> of
>>> importance and came up with top 50 (or 100) projects. If I remember
>>> correct VPP is among top single digits (I am trying to get the
>> exact
>>> details). So, it is an application of significant interest.
>>
>>
>> VPP is important, but what's important is for VPP to perform
>> significantly
>> better on at least one ODP implementation than it does today using
>>> DPDK.
>> If
>> we can't demonstrate that then there's no point to the ODP4VPP
>>> project.
>> That's not going to happen on x86 since we can assume that VPP/DPDK
>> is
>> optimal here since VPP has been tuned to DPDK internals. So we need
>> to
>> foc

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

On 7 December 2017 at 17:01, Bogdan Pricope 
wrote:

> TX is at line rate. Probably will get RX at line rate in direct mode, too.
> Problem is how can you see the performance increase/degradation if you
> can process more than line rate with one core?
>
> I guess .. enable csum option... ?
>
>

one question when people download odp, run and see line rate and happy and
other is what we will use in tests.
We can check that line rate is till line rate and scheduler on both ends is
some value bellow line rate.




> On 7 December 2017 at 15:46, Maxim Uvarov  wrote:
> > nice. TX is on line rate,  right?  Next step probably to add RX path
> without
> > scheduler. And we will have good testing environment.
> >
> >
> > On 7 December 2017 at 16:12, Bogdan Pricope 
> > wrote:
> >>
> >> More results with odp_generator in lava setup:
> >>
> >>  7.6 mpps  (TX) /  5.9 mpps (RX) - api-next with PR313 (Petri):
> >>  8.3 mpps  (TX) /  6.3 mpps (RX) - api-next with PR313 (Petri) +
> >> remove 1m sleep + replace atomic counters
> >> 14.8 mpps (TX) /  6.5 mpps (RX) - api-next with PR313 (Petri) + remove
> >> 1m sleep + replace atomic counters + remove csum
> >> calculation/validation
> >> 14.8 mpps (TX) /  6.8 mpps (RX) - master with PR327 (remove 1m sleep +
> >> replace atomic counters + remove csum calculation/validation)
> >>
> >> /Bogdan
> >>
> >>
> >> On 6 December 2017 at 13:49, Maxim Uvarov 
> wrote:
> >> > small update. Double checked that increasing num of desc does not give
> >> > any
> >> > effect in odp_generator.
> >> >
> >> > Disable check sums in odp_generator increases TX from 7M to 13M pps
> and
> >> > RX
> >> > from 5.9M to 6.1M pps.
> >> > Because of generator uses predefined packets with calculated checksum
> -
> >> > there is no need to enable checksum inside generator.
> >> >
> >> > It looks like problem inside DPDK driver itself.
> >> >
> >> > For this PR I think we need to merge it together with changes to
> >> > odp_generator (the same as for l2fwd) to enable hw check sum,
> >> > which has to be disabled by default.
> >> >
> >> > Maxim.
> >> >
> >> >
> >> > On 6 December 2017 at 10:46, Maxim Uvarov 
> >> > wrote:
> >> >>
> >> >> skip this message. I will recheck. Pushed to lava wrong branch.
> >> >>
> >> >> On 6 December 2017 at 10:42, Maxim Uvarov 
> >> >> wrote:
> >> >>>
> >> >>> Ilias was right yesterday. If number of descriptors increased to
> 1024
> >> >>> then TX became again 10M.
> >> >>>
> >> >>> +   ret = rte_eth_tx_queue_setup(port_id, i,
> >> >>> +
> >> >>> dev_info.tx_desc_lim.nb_max
> >> >>> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
> >> >>>
> >> >>> rte_eth_dev_socket_id(port_id),
> >> >>>  txconf);
> >> >>>
> >> >>> +   ret = rte_eth_rx_queue_setup(port_id, i,
> >> >>> +
> >> >>> dev_info.rx_desc_lim.nb_max
> >> >>> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
> >> >>>
> >> >>> rte_eth_dev_socket_id(port_id),
> >> >>>  NULL,
> >> >>> pkt_dpdk->pkt_pool);
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> Maxim.
> >> >>>
> >> >>> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo)
> >> >>>  wrote:
> >> >>>>
> >> >>>> When I tested enabling HW checksum with Fortville NICs (i40e) the
> >> >>>> slower
> >> >>>> driver path alone caused ~20% throughput drop on l2fwd test. This
> was
> >> >>>> without actually calculating the checksums, I simply forced the
> >> >>>> slower
> >> >>>> driver path (no vectorization).
> >> >>>>
> >> >>>> -Matias
> >> >>>>
> >> >>>>
> >> >>>> > On 5 Dec 2017, at 8:59, Bogdan Pricope <
> bogdan.pric...@linaro.org>
> >> >>>>

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

nice. TX is on line rate,  right?  Next step probably to add RX path
without  scheduler. And we will have good testing environment.


On 7 December 2017 at 16:12, Bogdan Pricope 
wrote:

> More results with odp_generator in lava setup:
>
>  7.6 mpps  (TX) /  5.9 mpps (RX) - api-next with PR313 (Petri):
>  8.3 mpps  (TX) /  6.3 mpps (RX) - api-next with PR313 (Petri) +
> remove 1m sleep + replace atomic counters
> 14.8 mpps (TX) /  6.5 mpps (RX) - api-next with PR313 (Petri) + remove
> 1m sleep + replace atomic counters + remove csum
> calculation/validation
> 14.8 mpps (TX) /  6.8 mpps (RX) - master with PR327 (remove 1m sleep +
> replace atomic counters + remove csum calculation/validation)
>
> /Bogdan
>
>
> On 6 December 2017 at 13:49, Maxim Uvarov  wrote:
> > small update. Double checked that increasing num of desc does not give
> any
> > effect in odp_generator.
> >
> > Disable check sums in odp_generator increases TX from 7M to 13M pps and
> RX
> > from 5.9M to 6.1M pps.
> > Because of generator uses predefined packets with calculated checksum -
> > there is no need to enable checksum inside generator.
> >
> > It looks like problem inside DPDK driver itself.
> >
> > For this PR I think we need to merge it together with changes to
> > odp_generator (the same as for l2fwd) to enable hw check sum,
> > which has to be disabled by default.
> >
> > Maxim.
> >
> >
> > On 6 December 2017 at 10:46, Maxim Uvarov 
> wrote:
> >>
> >> skip this message. I will recheck. Pushed to lava wrong branch.
> >>
> >> On 6 December 2017 at 10:42, Maxim Uvarov 
> wrote:
> >>>
> >>> Ilias was right yesterday. If number of descriptors increased to 1024
> >>> then TX became again 10M.
> >>>
> >>> +   ret = rte_eth_tx_queue_setup(port_id, i,
> >>> +
> dev_info.tx_desc_lim.nb_max
> >>> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
> >>>
> >>> rte_eth_dev_socket_id(port_id),
> >>>  txconf);
> >>>
> >>> +   ret = rte_eth_rx_queue_setup(port_id, i,
> >>> +
> dev_info.rx_desc_lim.nb_max
> >>> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
> >>>
> >>> rte_eth_dev_socket_id(port_id),
> >>>  NULL, pkt_dpdk->pkt_pool);
> >>>
> >>>
> >>>
> >>>
> >>> Maxim.
> >>>
> >>> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo)
> >>>  wrote:
> >>>>
> >>>> When I tested enabling HW checksum with Fortville NICs (i40e) the
> slower
> >>>> driver path alone caused ~20% throughput drop on l2fwd test. This was
> >>>> without actually calculating the checksums, I simply forced the slower
> >>>> driver path (no vectorization).
> >>>>
> >>>> -Matias
> >>>>
> >>>>
> >>>> > On 5 Dec 2017, at 8:59, Bogdan Pricope 
> >>>> > wrote:
> >>>> >
> >>>> > 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

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

small update. Double checked that increasing num of desc does not give any
effect in odp_generator.

Disable check sums in odp_generator increases TX from 7M to 13M pps and RX
from 5.9M to 6.1M pps.
Because of generator uses predefined packets with calculated checksum -
there is no need to enable checksum inside generator.

It looks like problem inside DPDK driver itself.

For this PR I think we need to merge it together with changes to
odp_generator (the same as for l2fwd) to enable hw check sum,
which has to be disabled by default.

Maxim.


On 6 December 2017 at 10:46, Maxim Uvarov  wrote:

> skip this message. I will recheck. Pushed to lava wrong branch.
>
> On 6 December 2017 at 10:42, Maxim Uvarov  wrote:
>
>> Ilias was right yesterday. If number of descriptors increased to 1024
>> then TX became again 10M.
>>
>> +   ret = rte_eth_tx_queue_setup(port_id, i,
>> +dev_info.tx_desc_lim.nb_max
>> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
>>
>> rte_eth_dev_socket_id(port_id),
>>  txconf);
>>
>> +   ret = rte_eth_rx_queue_setup(port_id, i,
>> +dev_info.rx_desc_lim.nb_max
>> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
>>
>> rte_eth_dev_socket_id(port_id),
>>  NULL, pkt_dpdk->pkt_pool);
>>
>>
>>
>>
>> Maxim.
>>
>> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo) <
>> matias@nokia.com> wrote:
>>
>>> When I tested enabling HW checksum with Fortville NICs (i40e) the slower
>>> driver path alone caused ~20% throughput drop on l2fwd test. This was
>>> without actually calculating the checksums, I simply forced the slower
>>> driver path (no vectorization).
>>>
>>> -Matias
>>>
>>>
>>> > On 5 Dec 2017, at 8:59, Bogdan Pricope 
>>> wrote:
>>> >
>>> > 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:
>>> >>&g

[lng-odp] api to disable/enale flow control

[Maxim Uvarov]

Until we did not do release  I have a question if we need api to
enable/disable flow control on pktio.
dpdk has it disabled by default. It can be configured with api:
+   /* disable flow control */
+   struct rte_eth_fc_conf fc_conf;
+
+   rte_eth_dev_flow_ctrl_get(pkt_dpdk->port_id, &fc_conf);
+   fc_conf.mode = RTE_FC_NONE;
+   fc_conf.low_water = 0;
+   fc_conf.high_water = 0;
+   rte_eth_dev_flow_ctrl_set(pkt_dpdk->port_id, &fc_conf);


Maxim.

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

skip this message. I will recheck. Pushed to lava wrong branch.

On 6 December 2017 at 10:42, Maxim Uvarov  wrote:

> Ilias was right yesterday. If number of descriptors increased to 1024 then
> TX became again 10M.
>
> +   ret = rte_eth_tx_queue_setup(port_id, i,
> +dev_info.tx_desc_lim.nb_max
> > 1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
>
> rte_eth_dev_socket_id(port_id),
>  txconf);
>
> +   ret = rte_eth_rx_queue_setup(port_id, i,
> +dev_info.rx_desc_lim.nb_max
> > 1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
>
> rte_eth_dev_socket_id(port_id),
>  NULL, pkt_dpdk->pkt_pool);
>
>
>
>
> Maxim.
>
> On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo) <
> matias@nokia.com> wrote:
>
>> When I tested enabling HW checksum with Fortville NICs (i40e) the slower
>> driver path alone caused ~20% throughput drop on l2fwd test. This was
>> without actually calculating the checksums, I simply forced the slower
>> driver path (no vectorization).
>>
>> -Matias
>>
>>
>> > On 5 Dec 2017, at 8:59, Bogdan Pricope 
>> wrote:
>> >
>> > 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 P

Re: [lng-odp] odp dpdk

[Maxim Uvarov]

Ilias was right yesterday. If number of descriptors increased to 1024 then
TX became again 10M.

+   ret = rte_eth_tx_queue_setup(port_id, i,
+dev_info.tx_desc_lim.nb_max >
1024 ? 1024 : dev_info.tx_desc_lim.nb_max,
 rte_eth_dev_socket_id(port_id),
 txconf);

+   ret = rte_eth_rx_queue_setup(port_id, i,
+dev_info.rx_desc_lim.nb_max >
1024 ? 1024 : dev_info.rx_desc_lim.nb_max,
 rte_eth_dev_socket_id(port_id),
 NULL, pkt_dpdk->pkt_pool);




Maxim.

On 5 December 2017 at 11:20, Elo, Matias (Nokia - FI/Espoo) <
matias@nokia.com> wrote:

> When I tested enabling HW checksum with Fortville NICs (i40e) the slower
> driver path alone caused ~20% throughput drop on l2fwd test. This was
> without actually calculating the checksums, I simply forced the slower
> driver path (no vectorization).
>
> -Matias
>
>
> > On 5 Dec 2017, at 8:59, Bogdan Pricope 
> wrote:
> >
> > 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 <
> bogdan.pric...@linaro.org>
> >>>>>> 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.
> >>>>>>
> >>&

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

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

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

[Maxim Uvarov]

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]

313 does not work also:
https://lng.validation.linaro.org/scheduler/job/23242.1
<https://www.google.com/url?q=https%3A%2F%2Flng.validation.linaro.org%2Fscheduler%2Fjob%2F23242.1&sa=D&sntz=1&usg=AFQjCNEsQmMQuPpbnJWtu_0-P8DCOlVKGg>

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

[lng-odp] odp dpdk

[Maxim Uvarov]

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] Preparing for ODP 2.0

[Maxim Uvarov]

If patch is suitable for master or api-next (like cache line optimizations)
it has to go to master/api-next first. As well as all bug fixes for master
branch should go directly to master.
Only than patch can be taken to development branch.

Maxim.


On 28 November 2017 at 12:43, Dmitry Eremin-Solenikov <
dmitry.ereminsoleni...@linaro.org> wrote:

> On 28/11/17 00:57, Bill Fischofer wrote:
> > As a way of easing the sync burden on the 2.0 development branch, what do
> > folks think of the idea of asking that new PRs being posted to api-next
> > also be posted to 2.0? The contributions to api-next should be winding
> down
> > as we approach Tiger Moth freeze, so this will help keep things in sync
> as
> > we transition back into a single development target post-Tiger Moth.
> >
> > Please share your views on this.
>
> No, current '2.0' should be refactored as a set of PRs against
> master/api-next. When its development was started, it was promised that
> 2.0 will be reviewed before merging to master/api-next.
>
>
> --
> With best wishes
> Dmitry
>

Re: [lng-odp] Github shows commits in wrong order

[Maxim Uvarov]

On 11/20/17 13:16, Andriy Berestovskyy wrote:
> Hey guys,
> I guess it is a known GitHub "feature":
> 
> https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/
> 
> Andriy
> 

yep github team also replied with that link. And it's not clear if they
will fix it and when.

Maxim.

> On 20.11.2017 10:15, Maxim Uvarov wrote:
>> created ticked for this on github.
>>
>> On 20 November 2017 at 12:02, Savolainen, Petri (Nokia - FI/Espoo) <
>> petri.savolai...@nokia.com> wrote:
>>
>>>> -Original Message-
>>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>>> Savolainen, Petri (Nokia - FI/Espoo)
>>>> Sent: Friday, November 17, 2017 10:24 AM
>>>> To: lng-odp@lists.linaro.org
>>>> Subject: [lng-odp] Github shows commits in wrong order
>>>>
>>>> Hi,
>>>>
>>>> Here's evidence that Github shows sometimes commits in a wrong
>>>> order. The
>>>> first commit of this patch set is "api: std_types: add odp_percent_t
>>>> data
>>>> type", but it shows in the Github web page as the last one!
>>>>
>>>> It's annoying and counterproductive that reviewers cannot trust on the
>>>> patch order.
>>>>
>>>>
>>>> -Petri
>>>
>>> Github has done another spin on the commit order lottery. Now, the first
>>> patch ("add odp_percent_t") is in the middle.
>>>
>>> -Petri
>>>

Re: [lng-odp] Github shows commits in wrong order

[Maxim Uvarov]

created ticked for this on github.

On 20 November 2017 at 12:02, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Savolainen, Petri (Nokia - FI/Espoo)
> > Sent: Friday, November 17, 2017 10:24 AM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] Github shows commits in wrong order
> >
> > Hi,
> >
> > Here's evidence that Github shows sometimes commits in a wrong order. The
> > first commit of this patch set is "api: std_types: add odp_percent_t data
> > type", but it shows in the Github web page as the last one!
> >
> > It's annoying and counterproductive that reviewers cannot trust on the
> > patch order.
> >
> >
> > -Petri
>
> Github has done another spin on the commit order lottery. Now, the first
> patch ("add odp_percent_t") is in the middle.
>
> -Petri
>

[lng-odp] api-next is ahead on 208 patches

[Maxim Uvarov]

I attached list of patches which are in api-next but are missing in
master branch. To total is 208 patches including merges.

Maxim.



git diff --stat master api-next ./include/
 include/Makefile.am  |3 +
 include/odp/api/spec/chksum.h|   53 ++
 include/odp/api/spec/classification.h|   91 +-
 include/odp/api/spec/crypto.h|  187 ++--
 include/odp/api/spec/event.h |   84 -
 include/odp/api/spec/ipsec.h | 1511
++
 include/odp/api/spec/packet.h|  218 
 include/odp/api/spec/packet_io.h |  115 +++--
 include/odp/api/spec/pool.h  |   30 
 include/odp/api/spec/queue.h |9 +-
 include/odp/api/spec/schedule.h  |   28 ++-
 include/odp/api/spec/schedule_types.h|2 +-
 include/odp/api/spec/shared_memory.h |   74 +---
 include/odp/api/spec/support.h   |   57 +++
 include/odp/api/spec/timer.h |   27 +++
 include/odp/arch/default/api/abi/event.h |9 +-
 include/odp_api.h|3 +
 17 files changed, 2426 insertions(+), 75 deletions(-)
16:54 /opt/Linaro/odp3.git (master)$
a908a4de linux-gen: crypto: add AES-CTR support
157234c0 validation: crypto: add tests for AES-CTR
ab19e58d api: crypto: add AES-CTR declarations
1ae234f5 example: generator: use L3/L4 checksum validation status functions
58bc3739 linux-gen: pktio: dpdk: set L3/L4 checksum validation flags
9b3a29dd linux-gen: packet: implement checksum validation status functions
a57dc0bc linux-gen: packet: add L3/L4 checksum validation flags
a1312ccf validation: packet: add call to ones complement
4da1cb60 linux-gen: packet: dummy ones complement implementation
f6d3bc30 api: packet: ones complement sum
6333b39f validation: packet: add parse tests
78ced32d validation: pktio: add parser test packet header
fbb6a7fe linux-gen: packet: add parse API
23b6eee8 api: ipsec: use common protocol layer enum
0ec5bc6b api: pktio: use common protocol layer enum
9c389e17 api: packet: add parse functions
fd192cba drv: remove remaining of files from api-next
d22c949c api: packet: change argument to insert for l3 and l4 chsums
ebdf6e27 validation: shmem: compare info page size to all supported huge page 
sizes
66b36363 api: pool: Return address range for pool objects
825f75ed linux-gen: shm: implement odp_shm_print
18977d06 linux-gen: shm: make odp_shm_print_all readable again
f4d54b88 api: shm: print shm block info
e733d6ba api: shm: style clean up
ec6510b3 linux-gen: ipsec: update git ignore
afa7e20a Merge remote-tracking branch 'origin/master' into merge-master
e3108af2 api: ipsec: move pipeline SA param to inbound substructrure
cd196cf1 linux-gen: pktio: tap: implement MAC address set operation
dee4a751 linux-gen: pktio: tap: implement link status operation
f70ff3bc linux-gen: pktio: tap: implement start/stop operations
700c0ac9 linux-gen: pktio: loop: support IPsec inbound inline
20aba9a1 linux-gen: pktio: loop: support IPsec outbound inline
ce4bd52a linux-generic: ipsec: draft IPsec implementation
01b5f7e0 linux-generic: ipsec: implement IPsec SAD
5e8f87ae linux-generic: ipsec: implement events handling
9e10a562 Revert "linux-gen: drop unused _odp_packet_cmp_data() function"
86d651b8 linux-gen: packet: add support for IP-in-IP (RFC 2003) encap
bc3cad50 linux-gen: packet: support parsing of just L3/L4 headers
9c747985 linux-gen: packet: factor out L2 header parsing
698f370e test: validation: add IPsec API testsuite
edca8cd1 api: ipsec: return maximum antireplay window size via capability
60a1a4f1 test: validation: pktio: validate MAC address set function
2fb72324 linux-gen: pktio: implement MAC address set function
90c3fdd7 api: packet_io: add MAC address set function
e943f821 validation: chksum: add long UDP packet test
a197b3ca linux-gen: chksum: correct uninitialized variable bug
a2e288f3 validation: chksum: add test chksum suite
7ea3096a linux-gen: chksum: implement ones complement sum
458683cb api: chksum: add ones complement sum function
506bf9dc linux-gen: more unification of arch-specific code
41472f58 linux-gen: update api-next to follow merged changes
e04e5f90 api: ipsec: document restrictions for odp_ipsec_config()
bfbe4f50 linux-generic: pktio: fix gcc7 build error in sched_cb_pktin_poll_one
c6ab55e8 linux-generic: pool: implementation for min and max headroom 
configuration
f2da0136 api: pool: add min and max headroom configuration in pool
e344e436 api: ipsec: rename odp_ipsec_mtu_update to follow odp_ipsec_sa_* 
pattern
f3fa10fa test: validation: schduler: change order lock function signature
4e6dbf3c test: validation: queue: change order lock data type
f172905f linux-generic: schedule: implement schedule order unlock lock api
7018fa1c linux-generic: 

[lng-odp] AF_PACKET V4

[Maxim Uvarov]

Looks like there is good progress on AF_PACKET V4
https://patchwork.ozlabs.org/cover/832448/

log says it can accept 33 Mpps on 2 cores.

Maxim.

[lng-odp] abi version support

[Maxim Uvarov]

I see that dpdk started to support abi versions in following ways:

DPDK_2.0 {
global:

rte_jobstats_context_finish;
rte_jobstats_context_init;
.
rte_jobstats_set_update_period_function;
rte_jobstats_start;

local: *;
};

DPDK_16.04 {
global:

rte_jobstats_abort;

} DPDK_2.0;

./dpdk/lib/librte_jobstats/Makefile:EXPORT_MAP := rte_jobstats_version.map
./dpdk/mk/rte.lib.mk:CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)

I.e. they describe in .map file which functions to expert and what ABI/API
level they are.
We can use something the same. But I'm not big fun of manually writing such
files. And maybe maintain different ABI versions in one source is not a
good idea. But we can try to generate .map and filter out all not "odp_"
functions, then specify this .map to linked.

Maxim.

Re: [lng-odp] issues with usage of mellanox 100G NICs with ODP & ODP-DPDK

[Maxim Uvarov]

Nice to see it working. I think we did not yet tested it with Mellanox
drivers.

For linux-generic refer to .travis.yaml or ./scripts/build-pktio-dpdk
scripts. Also all required steps are in README.

Maxim.

On 11/09/17 14:47, Elo, Matias (Nokia - FI/Espoo) wrote:
> Hi Gyanesh,
> 
> Pretty much the same steps should also work with odp linux-generic. The main 
> difference is configure script. With linux-generic you use 
> '--with-dpdk-path=' option and optionally --enable-dpdk-zero-copy 
> flag. The supported dpdk  version is v17.08.
> 
> -Matias
> 
>> On 9 Nov 2017, at 10:34, gyanesh patra  wrote:
>>
>> Hi Maxim,
>> Thanks for the help. I managed to figure out the configuration error and it
>> works fine for "ODP-DPDK". The MLX5 pmd was not included properly.
>>
>> But regarding "ODP" repo (not odp-dpdk), do i need to follow any steps to
>> be able to use MLX ???
>>
>>
>> P Gyanesh Kumar Patra
>>
>> On Wed, Nov 8, 2017 at 7:56 PM, Maxim Uvarov 
>> wrote:
>>
>>> On 11/08/17 19:32, gyanesh patra wrote:
>>>> I am not sure what you mean. Can you please elaborate?
>>>>
>>>> As i mentioned before I am able to run dpdk examples. Hence the drivers
>>>> are available and working fine.
>>>> I configured ODP & ODP-DPDK with "LDFLAGS=-libverbs" and compiled to
>>>> work with mellanox. I followed the same while compiling dpdk too.
>>>>
>>>> Is there anything i am missing?
>>>>
>>>> P Gyanesh Kumar Patra
>>>
>>>
>>> in general if CONFIG_RTE_LIBRTE_MLX5_PMD=y was specified then it has to
>>> work. I think we did test only with ixgbe. But in general it's common code.
>>>
>>> "Unable to init any I/O type." means it it called all open for all pktio
>>> in list here:
>>> ./platform/linux-generic/pktio/io_ops.c
>>>
>>> and setup_pkt_dpdk() failed for some reason.
>>>
>>> I do not like allocations errors in your log.
>>>
>>> Try to compile ODP with --enable-debug-print --enable-debug it will make
>>> ODP_DBG() macro work and it will be visible why it does not opens pktio.
>>>
>>> Maxim
>>>
>>>
>>>>
>>>> On Wed, Nov 8, 2017 at 5:22 PM, Maxim Uvarov >>> <mailto:maxim.uva...@linaro.org>> wrote:
>>>>
>>>>is Mellanox pmd compiled in?
>>>>
>>>>Maxim.
>>>>
>>>>On 11/08/17 17:58, gyanesh patra wrote:
>>>>> Hi,
>>>>> I am trying to run ODP & ODP-DPDK examples on our server with
>>>>mellanox 100G
>>>>> NICs. I am using the odp_l2fwd example. While running the example,
>>>>I am
>>>>> facing some issues.
>>>>> -> When I run "ODP" example using the if names given by kernel as
>>>>> arguments, I am not getting enough throughput.(the value is very
>>> low)
>>>>> -> And when I try "ODP-DPDK" example using port ID as "0,1", it
>>> can't
>>>>> create pktio. Whereas I am able to run the examples from "DPDK"
>>>>> repo with portID "0,1" for the same mellanox NICs. I tried running
>>>>with
>>>>> "81:00.0,81:00.1" and also with if-names too without any success.
>>>>Adding
>>>>> the whitelist using ODP_PLATFORM_PARAMS doesn't help either.
>>>>>
>>>>> Am I missing any steps to use mellanox NICs? OR is there a
>>>>different method
>>>>> to specify the device details to create pktio?
>>>>> I am providing the output of "odp_l2fwd" examples for ODP and
>>> ODP-DPDK
>>>>> repository here.
>>>>>
>>>>> The NICs being used:
>>>>>
>>>>> :81:00.0 'MT27700 Family [ConnectX-4]' if=enp129s0f0
>>> drv=mlx5_core
>>>>> unused=
>>>>> :81:00.1 'MT27700 Family [ConnectX-4]' if=enp129s0f1
>>> drv=mlx5_core
>>>>> unused=
>>>>>
>>>>> ODP l2fwd example run details:
>>>>> --
>>>>> root@ubuntu:/home/ubuntu/odp/test/performance# ./odp_l2fwd -i
>>>>> enp129s0f0,enp129s0f1
>>>>> HW time counter freq: 239886 
>>>><(239)%20999-9886> hz
>>>>>
>>&g

Re: [lng-odp] issues with usage of mellanox 100G NICs with ODP & ODP-DPDK

[Maxim Uvarov]

On 11/08/17 19:32, gyanesh patra wrote:
> I am not sure what you mean. Can you please elaborate?
> 
> As i mentioned before I am able to run dpdk examples. Hence the drivers
> are available and working fine.
> I configured ODP & ODP-DPDK with "LDFLAGS=-libverbs" and compiled to
> work with mellanox. I followed the same while compiling dpdk too.
> 
> Is there anything i am missing?
> 
> P Gyanesh Kumar Patra


in general if CONFIG_RTE_LIBRTE_MLX5_PMD=y was specified then it has to
work. I think we did test only with ixgbe. But in general it's common code.

"Unable to init any I/O type." means it it called all open for all pktio
in list here:
./platform/linux-generic/pktio/io_ops.c

and setup_pkt_dpdk() failed for some reason.

I do not like allocations errors in your log.

Try to compile ODP with --enable-debug-print --enable-debug it will make
ODP_DBG() macro work and it will be visible why it does not opens pktio.

Maxim


> 
> On Wed, Nov 8, 2017 at 5:22 PM, Maxim Uvarov  <mailto:maxim.uva...@linaro.org>> wrote:
> 
> is Mellanox pmd compiled in?
> 
> Maxim.
> 
> On 11/08/17 17:58, gyanesh patra wrote:
> > Hi,
> > I am trying to run ODP & ODP-DPDK examples on our server with
> mellanox 100G
> > NICs. I am using the odp_l2fwd example. While running the example,
> I am
> > facing some issues.
> > -> When I run "ODP" example using the if names given by kernel as
> > arguments, I am not getting enough throughput.(the value is very low)
> > -> And when I try "ODP-DPDK" example using port ID as "0,1", it can't
> > create pktio. Whereas I am able to run the examples from "DPDK"
> > repo with portID "0,1" for the same mellanox NICs. I tried running
> with
> > "81:00.0,81:00.1" and also with if-names too without any success.
> Adding
> > the whitelist using ODP_PLATFORM_PARAMS doesn't help either.
> >
> > Am I missing any steps to use mellanox NICs? OR is there a
> different method
> > to specify the device details to create pktio?
> > I am providing the output of "odp_l2fwd" examples for ODP and ODP-DPDK
> > repository here.
> >
> > The NICs being used:
> >
> > :81:00.0 'MT27700 Family [ConnectX-4]' if=enp129s0f0 drv=mlx5_core
> > unused=
> > :81:00.1 'MT27700 Family [ConnectX-4]' if=enp129s0f1 drv=mlx5_core
> > unused=
> >
> > ODP l2fwd example run details:
> > --
> > root@ubuntu:/home/ubuntu/odp/test/performance# ./odp_l2fwd -i
> > enp129s0f0,enp129s0f1
> > HW time counter freq: 239886 
> <(239)%20999-9886> hz
> >
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishm.c:880:_odp_ishm_reserve():No huge pages, fall back to normal
> pages.
> > check: /proc/sys/vm/nr_hugepages.
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> >  PKTIO: initialized loop interface.
> >  PKTIO: initialized pcap interface.
> >  PKTIO: initialized ipc interface.
> >  PKTIO: initialized socket mmap, use export
> ODP_PKTIO_DISABLE_SOCKET_MMAP=1
> > to disable.
> >  PKTIO: initialized socket mmsg,use export
> ODP_PKTIO_DISABLE_SOCKET_MMSG=1
> > to disable.
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> > _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> >
> > ODP system info
> > ---
> > ODP API version: 1.15.0
> > ODP impl name:   "odp-linux"
> > CPU model:       Intel(R) Xeon(R) CPU E5-2680 v4
> > CPU freq (hz):   33
> > Cache line size: 64
> > CPU count:       56
> >
> >
> > CPU features supported:
> > SSE3 PCLMULQDQ DTES64 MONITOR DS_CPL VMX SMX EIST TM2 SSSE3 FMA
> CMPXCHG16B
> > XTPR PDCM PCID DCA SSE4_1 SSE4_2 X2APIC MOVBE POPCNT TSC_DEADLINE
> AES XSAVE
> > OSXSAVE AVX F16C RDRAND FPU VME DE PSE TSC MSR PAE MCE CX8 APIC
> SEP MTRR
> > PGE MCA CMOV PAT PSE3

Re: [lng-odp] issues with usage of mellanox 100G NICs with ODP & ODP-DPDK

[Maxim Uvarov]

is Mellanox pmd compiled in?

Maxim.

On 11/08/17 17:58, gyanesh patra wrote:
> Hi,
> I am trying to run ODP & ODP-DPDK examples on our server with mellanox 100G
> NICs. I am using the odp_l2fwd example. While running the example, I am
> facing some issues.
> -> When I run "ODP" example using the if names given by kernel as
> arguments, I am not getting enough throughput.(the value is very low)
> -> And when I try "ODP-DPDK" example using port ID as "0,1", it can't
> create pktio. Whereas I am able to run the examples from "DPDK"
> repo with portID "0,1" for the same mellanox NICs. I tried running with
> "81:00.0,81:00.1" and also with if-names too without any success. Adding
> the whitelist using ODP_PLATFORM_PARAMS doesn't help either.
> 
> Am I missing any steps to use mellanox NICs? OR is there a different method
> to specify the device details to create pktio?
> I am providing the output of "odp_l2fwd" examples for ODP and ODP-DPDK
> repository here.
> 
> The NICs being used:
> 
> :81:00.0 'MT27700 Family [ConnectX-4]' if=enp129s0f0 drv=mlx5_core
> unused=
> :81:00.1 'MT27700 Family [ConnectX-4]' if=enp129s0f1 drv=mlx5_core
> unused=
> 
> ODP l2fwd example run details:
> --
> root@ubuntu:/home/ubuntu/odp/test/performance# ./odp_l2fwd -i
> enp129s0f0,enp129s0f1
> HW time counter freq: 239886 <(239)%20999-9886> hz
> 
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishm.c:880:_odp_ishm_reserve():No huge pages, fall back to normal pages.
> check: /proc/sys/vm/nr_hugepages.
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
>  PKTIO: initialized loop interface.
>  PKTIO: initialized pcap interface.
>  PKTIO: initialized ipc interface.
>  PKTIO: initialized socket mmap, use export ODP_PKTIO_DISABLE_SOCKET_MMAP=1
> to disable.
>  PKTIO: initialized socket mmsg,use export ODP_PKTIO_DISABLE_SOCKET_MMSG=1
> to disable.
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> 
> ODP system info
> ---
> ODP API version: 1.15.0
> ODP impl name:   "odp-linux"
> CPU model:   Intel(R) Xeon(R) CPU E5-2680 v4
> CPU freq (hz):   33
> Cache line size: 64
> CPU count:   56
> 
> 
> CPU features supported:
> SSE3 PCLMULQDQ DTES64 MONITOR DS_CPL VMX SMX EIST TM2 SSSE3 FMA CMPXCHG16B
> XTPR PDCM PCID DCA SSE4_1 SSE4_2 X2APIC MOVBE POPCNT TSC_DEADLINE AES XSAVE
> OSXSAVE AVX F16C RDRAND FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR
> PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE
> DIGTEMP TRBOBST ARAT PLN ECMD PTM MPERF_APERF_MSR ENERGY_EFF FSGSBASE HLE
> AVX2 BMI2 ERMS INVPCID RTM LAHF_SAHF SYSCALL XD 1GB_PG RDTSCP EM64T INVTSC
> 
> CPU features NOT supported:
> CNXT_ID PSN ACNT2 BMI1 SMEP AVX512F LZCNT
> 
> Running ODP appl: "odp_l2fwd"
> -
> IF-count:2
> Using IFs:   enp129s0f0 enp129s0f1
> Mode:PKTIN_DIRECT, PKTOUT_DIRECT
> 
> num worker threads: 32
> first CPU:  24
> cpu mask:   0x00
> 
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> _ishmphy.c:152:_odp_ishmphy_map():mmap failed:Cannot allocate memory
> 
> Pool info
> -
>   pool0
>   namepacket pool
>   pool type   packet
>   pool shm11
>   user area shm   0
>   num 8192
>   align   64
>   headroom128
>   seg len 8064
>   max data len65536
>   tailroom0
>   block size  8768
>   uarea size  0
>   shm size72143104
>   base addr   0x7f5fc1234000
>   uarea shm size  0
>   uarea base addr (nil)
> 
> pktio/socket_mmap.c:401:mmap_setup_ring():setsockopt(pkt mmap): Invalid
> argument
> pktio/socket_mmap.c:496:sock_mmap_close():mmap_unmap_sock() Invalid argument
> created pktio 1, dev: enp129s0f0, drv: socket
> Sharing 1 input queues between 16 workers
> Sharing 1 output queues between 16 workers
> created 1 input and 1 output queues on (enp129s0f0)
> pktio/socket_mmap.c:401:mmap_setup_ring():setsockopt(pkt mmap): Invalid
> argument
> pktio/socket_mmap.c:496:sock_mmap_close():mmap_unmap_sock() Invalid argument
> created pktio 2, dev: enp129s0f1, drv: socket
> Sharing 1 input queues between 16 workers
> Sharing 1 output queues between 16 workers
> created 1 input and 1 output queues on (enp129s0f1)
> 
> Queue binding (indexes)
> ---
> worker 0
>   rx: pktio 0, queue 0
>   tx: pktio 1, queue 0
> worker 1
>   rx: pktio 1, queue 0
>   tx: pktio 0, queue 0
> worker 2
>   rx: pktio 0, queue 0
>   tx: pktio 1, queue 0
> worker 3
>   rx: pktio 1, queue 0
>   tx: pkti

[lng-odp] OOO on Monday and Tuesday

[Maxim Uvarov]

Monday is official holiday in Russia.

On Tuesday I will be on HighLoad conference. Will take laptop and will
respond on emails. Depends on schedule may appear on ODP public call.



Best regards,
Maxim.

Re: [lng-odp] ODPH_IPPROTO_ICMPv4

[Maxim Uvarov]

On 11/01/17 21:10, Liron Himi wrote:
> Hi,
> 
> When I try to use either 'ODPH_IPPROTO_ICMPv4' in my code then checkpatch is 
> failing on
> 'CHECK: Avoid CamelCase: '.
> 
> Are those kind of 'check' errors can be ignored?
> Maybe it will be better if you change 'ODPH_IPPROTO_ICMPv4' to 
> 'ODPH_IPPROTO_ICMPV4' same as 'ODPH_ETHTYPE_IPV4'.
> 
> Thanks,
> Liron
> 

yes, it's better to change. We might skipped this on review.

Maxim.

Re: [lng-odp] drv api in api-next

[Maxim Uvarov]

as discussed today we will drop drv from master and api-next branch. 2.0
branch will need to revert this deletion commit.
So that drv will be in 2.0 before it's will be ready to merge to master.

Maxim.

[lng-odp] drv api in api-next

[Maxim Uvarov]

In api-next we have some drv apis which is a copy of linux-generic but
with drv prefix. I'm thinking what to do with them for Tiger Moth. Or
merge them or merge and revert. For now we do not use that api.

Maxim.

Re: [lng-odp] Relation between Enumerator class and Enumerator

[Maxim Uvarov]

On 10/27/17 17:56, Honnappa Nagarahalli wrote:
> We have to support both types of drivers as of now:
> 
> 1) Legacy all user space drivers - In this case, what Jianbo says is correct.
> 2) net-mdev drivers.
> 
> So, DDF has to support both the use cases.
> 
> Thank you,
> Honnappa
> 

Generic net-mdev kernel module will help here. I.e. if there is no
kernel driver but you need create mdev from pci device (i.e. map it
to user space) then you can link pci number with that driver which will
get netmdev and create dummy net device for it.

Maxim.

> 
> On 27 October 2017 at 04:47, Francois Ozog  wrote:
>> In the case of netmdev the device is still there. Please check with Ilias
>> for detailed behavior of this technology
>>
>> FF
>>
>> Le ven. 27 oct. 2017 à 10:29, Jianbo Liu  a écrit :
>>
>>> The 10/27/2017 10:25, Maxim Uvarov wrote:
>>>> yes, discovery is done by other tools like lspci, /proc  and /sys
>>>> interfaces. Also udev rules are there to make naming persistent.
>>>>
>>>> For pci it can be:
>>>>
>>>> odp_pktio_open("mdev:eth0")
>>>>
>>>> then you parse /proc/bus/pci/devices to find actual driver used for this
>>>> eth0. And if you have matching mdev pktio driver  - open it.
>>>
>>> There is no eth0 because the device is bound to vfio or uio driver.
>>>
>>>> That looks like very simply and clear.
>>>>
>>>> Maxim.
>>>>
>>>>
>>>> On 27 October 2017 at 01:03, Bill Fischofer 
>>>> wrote:
>>>>
>>>>> I think you've captured the distinction correctly. The larger question
>>> is
>>>>> what does ODP itself need to do with this? When an interface name is
>>>>> presented to odp_pktio_open() it is the application's responsibility to
>>>>> provide a name string that can be mapped to the device that should be
>>>>> opened. ODP uses that string to locate / load the driver that's needed
>>> to
>>>>> operate that device. The driver is then responsible to make the actual
>>>>> connection to the device.
>>>>>
>>>>> When a driver gets a "device string" is needs to translate that into
>>> either
>>>>> an appropriate Linux system call (for mdev) or to a set of PCI Bar or
>>> other
>>>>> HW register addresses (for dedicated I/O). So if there is a case of a
>>>>> southbound ODP API, it would be to assist with this latter translation.
>>>>>
>>>>> On Thu, Oct 26, 2017 at 12:38 PM, Honnappa Nagarahalli <
>>>>> honnappa.nagaraha...@linaro.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>I created a document to convert our discussion into pictures. I
>>>>>> will update this as we discuss other concepts like devio/driver etc.
>>>>>>
>>>>>> https://docs.google.com/a/linaro.org/document/d/1nzy-Qp6hYZU38DVi7_
>>>>>> ZnPiaf3jRqdMN6IQHmfO80Al4/edit?usp=sharing
>>>>>>
>>>>>> Thanks,
>>>>>> Honnappa
>>>>>>
>>>>>
>>>
>>> --
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you.
>>>
>> --
>> [image: Linaro] <http://www.linaro.org/>
>> François-Frédéric Ozog | *Director Linaro Networking Group*
>> T: +33.67221.6485 
>> francois.o...@linaro.org | Skype: ffozog

Re: [lng-odp] Relation between Enumerator class and Enumerator

[Maxim Uvarov]

yes, discovery is done by other tools like lspci, /proc  and /sys
interfaces. Also udev rules are there to make naming persistent.

For pci it can be:

odp_pktio_open("mdev:eth0")

then you parse /proc/bus/pci/devices to find actual driver used for this
eth0. And if you have matching mdev pktio driver  - open it.
That looks like very simply and clear.

Maxim.


On 27 October 2017 at 01:03, Bill Fischofer 
wrote:

> I think you've captured the distinction correctly. The larger question is
> what does ODP itself need to do with this? When an interface name is
> presented to odp_pktio_open() it is the application's responsibility to
> provide a name string that can be mapped to the device that should be
> opened. ODP uses that string to locate / load the driver that's needed to
> operate that device. The driver is then responsible to make the actual
> connection to the device.
>
> When a driver gets a "device string" is needs to translate that into either
> an appropriate Linux system call (for mdev) or to a set of PCI Bar or other
> HW register addresses (for dedicated I/O). So if there is a case of a
> southbound ODP API, it would be to assist with this latter translation.
>
> On Thu, Oct 26, 2017 at 12:38 PM, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
> > Hi,
> >I created a document to convert our discussion into pictures. I
> > will update this as we discuss other concepts like devio/driver etc.
> >
> > https://docs.google.com/a/linaro.org/document/d/1nzy-Qp6hYZU38DVi7_
> > ZnPiaf3jRqdMN6IQHmfO80Al4/edit?usp=sharing
> >
> > Thanks,
> > Honnappa
> >
>

Re: [lng-odp] DDF discussions taking time

[Maxim Uvarov]

Hello Honnappa,

I think we also need to take a look from bottom. I.e. from exact drivers to
implement. That it will be more clear which interface is needed to be
created.
Do you have some list of drivers which needed to be implemented? I.e. with
pci drivers I think we in a good way, but non pci drivers are under
question.
I think we should not over-complicate odp itself with huge discovery and
numeration of devices. Let's take a look what is the minimal interface to
support
devices.

Best regards,
Maxim.

On 26 October 2017 at 23:35, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Hi,
>Agree, we have taken 2 hours and the progress has been slow. But
> the discussions have been good and helpful to us at Arm. The goal is
> to identify the gaps and work items. I am not sure if it has been
> helpful to others, please let me know.
>
> To speed this up, I propose few options below, let me know your opinion:
>
> 1) Have 2 additional (along with regular ODP 2.0) calls next week - We
> can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
> time, GMT-6, one hour before the regular ODP-2.0)
>
> 2) Resolve the pending PRs on emails
>
> 3) Discuss the DDF slides on email - Not sure how effective it will be
>
> Any other solutions?
>
> Thank you,
> Honnappa
>

Re: [lng-odp] API-next branch

[Maxim Uvarov]

On 10/26/17 12:32, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> Hi,
> 
> It's not so trivial to draw a line what is a small change. E.g. one word 
> change in documentation may be a big change for an application: "ODP 
> maintains packet order during operation X" vs "... does not maintain order 
> ..."
> 
> So, it's much simpler if all API changes go through the same branch, and that 
> branch is released often.
> 
> One of the largest motivation to change to github was to enable easy (and 
> fast) release cycle, since all commits are always check automatically in 
> Travis. So, there should be now less work to make a release. 
> 
> Tomorrow is the last Friday of the month and a perfect day for making a 
> release (1.16) of everything that is ready in api-next... Maybe it's only 
> couple of new APIs and some typo corrections, but it still makes the delta 
> that much smaller.
> 

I pushed master to next. So we can stage ready patches there. If
somebody wants to help, please send pool requests.

Maxim.


> -Petri
> 
> 
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org] 
> Sent: Thursday, October 26, 2017 10:30 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bill Fischofer ; Dmitry Eremin-Solenikov 
> ; lng-odp-forward 
> 
> Subject: Re: [lng-odp] API-next branch
> 
> 1. we have api-next branch to collect all api changes with implementation in 
> tests in one places. A lot of people said that it's useful.
> 2. Yes it's hard to find patches which are in api-next and not in master.
> 3.  New API acceptance period is not very clean.  If we can improve that than 
> probably we will resolve merge issue.
> 
> I.e. my proposal is  - if feature is complete (api, impl, tests) and  
> accepted (members can implement it)  all patches for this feature should be 
> moved to master branch. No need to wait for release date.
> From other point there is no need for small api changes (like debug prints, 
> pktio capabilities, small improvements) stage in api-next. They can go 
> directly to master.
> The other deal is complex things which need several months for review.  This 
> should go to staging branch api-next .
> 
> To help with back port we can use github issues. Where one entry will be one 
> feature. And place in the comments all commit id's related to this feature. 
> It's also possible to do some automation for that.
> 
> How about that?
> 
> Maxim.
> 
> 
> On 26 October 2017 at 09:57, Savolainen, Petri (Nokia - FI/Espoo) 
> <mailto:petri.savolai...@nokia.com> wrote:
> We need one branch that holds all new API changes before those are released 
> (> 4 months currently): either it's master or api-next. If we change API 
> development to master, then applications would need follow the latest release 
> branch instead of master. At least previous there was resistance to change 
> master into API development branch.
> 
> Separate topic branches for API changes won't scale ... we would not have a 
> common view (e.g. for 4 months) what the API is before all those are merged 
> together. Implementation changes are easier in topic branches as there's less 
> dependency to other files and applications (other files and apps already 
> agree what the API is).
> 
> Api-next does not cause the problem (big delta), it's caused by the lack of 
> steady release cycle. The big  delta won't go away before we have a short 
> enough release cycle (merge often => small delta).
> 
> -Petri
> 
> 
> 
>> -Original Message-
>> From: lng-odp [mailto:mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
>> Bill
>> Fischofer
>> Sent: Wednesday, October 25, 2017 6:53 PM
>> To: Dmitry Eremin-Solenikov <mailto:dmitry.ereminsoleni...@linaro.org>
>> Cc: lng-odp-forward <mailto:lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] API-next branch
>>
>> I'm all for using topic branches, especially since we've switched to
>> GitHub
>> and most contributors are now familiar with it and using pull requests
>> rather than raw patches sent to the mailing list. The whole reason for
>> api-next was to separate in-progress API changes from regular maintenance
>> patches since they were all mixed together on the mailing list. The PR
>> structure is much cleaner in that regard.
>>
>> IPsec in particular clearly could have been a separate branch. We've
>> talked
>> about doing this in the context of 2.0 as well since that's also going to
>> involve some major subsystems that could benefit from collaborative
>> development before being merged back into the 2.0 mai

Re: [lng-odp] Ingress Metering/Policing

[Maxim Uvarov]

Hello Liron,

does you hardware support TCM offload?

I see that both Juniper and Cisco have this settings on ports. But it's
not clear if they do it in software or hardware. I.e. if there any
reason for odp api for that or it can be just example app.

p.s.
I found here good explanation if somebody will be interested..
http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/

Regards,
Maxim.

On 10/25/17 23:33, Bill Fischofer wrote:
> There are no immediate plans for this feature. As an open source project,
> ODP moves in the direction of its contributors. If this is of importance to
> you, please consider submitting patches to add it.
> 
> On Wed, Oct 25, 2017 at 11:54 AM, Liron Himi  wrote:
> 
>> Hi,
>>
>> Is there any intention to add support for Ingress Metering/Policing (RFC
>> 2697, RFC2698) in future releases?
>>
>> Regards,
>> Liron
>>

Re: [lng-odp] API-next branch

[Maxim Uvarov]

1. we have api-next branch to collect all api changes with implementation
in tests in one places. A lot of people said that it's useful.

2. Yes it's hard to find patches which are in api-next and not in master.

3.  New API acceptance period is not very clean.  If we can improve that
than probably we will resolve merge issue.

I.e. my proposal is  - if feature is complete (api, impl, tests) and
accepted (members can implement it)  all patches for this feature should be
moved to master branch. No need to wait for release date.

>From other point there is no need for small api changes (like debug prints,
pktio capabilities, small improvements) stage in api-next. They can go
directly to master.

The other deal is complex things which need several months for review.
This should go to staging branch api-next .

To help with back port we can use github issues. Where one entry will be
one feature. And place in the comments all commit id's related to this
feature. It's also possible to do some automation for that.

How about that?

Maxim.


On 26 October 2017 at 09:57, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> We need one branch that holds all new API changes before those are
> released (> 4 months currently): either it's master or api-next. If we
> change API development to master, then applications would need follow the
> latest release branch instead of master. At least previous there was
> resistance to change master into API development branch.
>
> Separate topic branches for API changes won't scale ... we would not have
> a common view (e.g. for 4 months) what the API is before all those are
> merged together. Implementation changes are easier in topic branches as
> there's less dependency to other files and applications (other files and
> apps already agree what the API is).
>
> Api-next does not cause the problem (big delta), it's caused by the lack
> of steady release cycle. The big  delta won't go away before we have a
> short enough release cycle (merge often => small delta).
>
> -Petri
>
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Bill
> > Fischofer
> > Sent: Wednesday, October 25, 2017 6:53 PM
> > To: Dmitry Eremin-Solenikov 
> > Cc: lng-odp-forward 
> > Subject: Re: [lng-odp] API-next branch
> >
> > I'm all for using topic branches, especially since we've switched to
> > GitHub
> > and most contributors are now familiar with it and using pull requests
> > rather than raw patches sent to the mailing list. The whole reason for
> > api-next was to separate in-progress API changes from regular maintenance
> > patches since they were all mixed together on the mailing list. The PR
> > structure is much cleaner in that regard.
> >
> > IPsec in particular clearly could have been a separate branch. We've
> > talked
> > about doing this in the context of 2.0 as well since that's also going to
> > involve some major subsystems that could benefit from collaborative
> > development before being merged back into the 2.0 main development
> branch.
> >
> >
> > On Wed, Oct 25, 2017 at 10:39 AM, Dmitry Eremin-Solenikov <
> > dmitry.ereminsoleni...@linaro.org> wrote:
> >
> > > Hello,
> > >
> > > I tried to actually check, which patches are sitting in the api-next.
> > > And actually I failed
> > > to do that in a timely manner. git cherry produces a list of patches,
> > > that contains a lot of patches, which already landed to the master.
> > >
> > > Quick proposal would be to stop using api-next as a long-lived branch
> > > which received updates from master and rather use it as a branch being
> > > regularly rebased on top of current master.
> > >
> > > Another possiblity would be to abandon api-next completely, develop
> > > features on topic branches, which get merged to master, rather than to
> > > api-next. At least this would save us from situations, when there is
> > > API definition (or change), but no actual implementation behind.
> > >
> > > --
> > > With best wishes
> > > Dmitry
> > >
>

Re: [lng-odp] odp api to query free/tottal ram

[Maxim Uvarov]

On 10/23/17 18:23, Francois Ozog wrote:
> Hi Maxim,
> 
> Is this regular memory or DMA capable memory?
> 
> This would mean application would know how, for instance, to handle things
> when memory is lower than a threshold or something similar; or it may
> decide to use a percentage of memory for packet pools; or many other
> policies.  I don't see that feature in "mature" applications like VPP.
> 
> Applications that want do that may still use platform information directly
> but I think it is too early work on an ODP API for that. An ODP memory API
> will also have to deal with NUMA...
> 
> FF


I came to that question after Petri's api to print ODP shm info.

We have pool capabilities which how many pools with which size can be
created. DMA memory should connected to pool capabilities info.

But odp_shm_reserve() (which is also connected to pool resources) does
not have maximum value for reserve. On some platforms not all system RAM
can be used as shared memory. So to run apps there you will need to
specify somewhere amount of available RAM for ODP application.

If query of total/free memory for odp_shm_reserve() is platform specific
than single binary will not work on different platforms. Or will require
some start up script to specify this amount. If it will be script than
it will have bunch of 'if platform' conditions. If we place it inside
ODP then it will be easy to get this number.

Maxim.


In general we need allocated
> 
> On 23 October 2017 at 14:26, Bill Fischofer 
> wrote:
> 
>> Applications should request the amount of storage they need (possibly as
>> configured) rather than trying to grab everything they can find "just in
>> case". Especially in an NFV environment that's not very neighborly
>> behavior.
>>
>> On Mon, Oct 23, 2017 at 2:44 AM, Dmitry Eremin-Solenikov <
>> dmitry.ereminsoleni...@linaro.org> wrote:
>>
>>> On 23/10/17 10:39, Maxim Uvarov wrote:
>>>> It might be reasonable to add also api call to get return free memory.
>> So
>>>> that application can adjust pools /buffers size according to hardware
>> or
>>> VM
>>>> settings. Which might be good fit for NFV set up.
>>>> Any opinions on that?
>>>
>>> It would depend on the platform too much. Also remember, that in some
>>> cases buffers/packets will use separate memory, not main RAM.
>>>
>>> --
>>> With best wishes
>>> Dmitry
>>>
>>
> 
> 
> 

[lng-odp] odp api to query free/tottal ram

[Maxim Uvarov]

It might be reasonable to add also api call to get return free memory. So
that application can adjust pools /buffers size according to hardware or VM
settings. Which might be good fit for NFV set up.
Any opinions on that?

Maxim.

Re: [lng-odp] api-next merge with ODP 2.0

[Maxim Uvarov]

(gdb) bt
#0  0x7fbe66d26c37 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x7fbe66d2a028 in __GI_abort () at abort.c:89
#2  0x0042e279 in odp_override_abort () at odp_weak.c:42
#3  0x00424604 in llq_enqueue (node=, llq=) at ./include/odp_llqueue.h:220
#4  schedq_push (elem=, schedq=) at
schedule/scalable.c:175
#5  _schedule (from=from@entry=0x0, ev=ev@entry=0x7fffd51030b8,
num_evts=num_evts@entry=1) at schedule/scalable.c:910
#6  0x004249da in schedule (from=0x0, wait=0) at
schedule/scalable.c:1310
#7  0x00406485 in flush_input_queue (pktio=,
imode=imode@entry=ODP_PKTIN_MODE_SCHED) at pktio.c:397
#8  0x00408f00 in test_txrx
(in_mode=in_mode@entry=ODP_PKTIN_MODE_SCHED,
num_pkts=num_pkts@entry=4,
mode=mode@entry=TXRX_MODE_MULTI) at pktio.c:731
#9  0x00409508 in pktio_test_sched_multi () at pktio.c:763
#10 0x7fbe670c0482 in run_single_test () from
/usr/local/lib/libcunit.so.1
#11 0x7fbe670c00b2 in run_single_suite () from
/usr/local/lib/libcunit.so.1
#12 0x7fbe670bdd55 in CU_run_all_tests () from
/usr/local/lib/libcunit.so.1
#13 0x7fbe670c2245 in basic_run_all_tests () from
/usr/local/lib/libcunit.so.1
#14 0x7fbe670c1fe7 in CU_basic_run_tests () from
/usr/local/lib/libcunit.so.1
#15 0x0040bc3b in odp_cunit_run () at odp_cunit_common.c:300
#16 0x7fbe66d11f45 in __libc_start_main (main=0x404480 , argc=1,
argv=0x7fffd5103548, init=,
fini=, rtld_fini=,
stack_end=0x7fffd5103538) at libc-start.c:287
#17 0x0040483d in _start ()
(gdb)


On 16 October 2017 at 22:34, Maxim Uvarov  wrote:

> ./configure --enable-schedule-scalable
> sudo make check
>
>   Test: pktio_test_sched_multi /include/odp_llqueue.h:
> 269:llq_dequeue_cond():node->next == SENTINEL
> Aborted
>
> full log is attached.
>
>
>
> On 16 October 2017 at 19:53, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
>> Dmitry had taken a look at these. He mentioned they can be ignored for
>> now.
>> Thanks,
>> Honnappa
>>
>> On 16 October 2017 at 03:52, Maxim Uvarov 
>> wrote:
>>
>>> bootstrap generates a lot of errors, I can reproduce them locally also
>>>
>>> https://travis-ci.org/nagarahalli/odp/jobs/287783022
>>>
>>> On 16 October 2017 at 09:21, Maxim Uvarov 
>>> wrote:
>>>
>>>> I will take a look. But please check that you added this 3 commits.
>>>>
>>>>
>>>> c16af648 travis: purge dpdk cache on version change
>>>> 3cb45201 travis: build dpdk for general cpu
>>>> 73bc4619 travis: temporary turn off dpdk caching
>>>>
>>>> In general Travis stopped due to no output. You can make tests more
>>>> verbose with make check V=1
>>>>
>>>> But I would start with adding dpdk commits because without them result
>>>> was also unclear.
>>>>
>>>> Maxim.
>>>>
>>>>
>>>> On 16 October 2017 at 06:45, Honnappa Nagarahalli <
>>>> honnappa.nagaraha...@linaro.org> wrote:
>>>>
>>>>> Hi Maxim,
>>>>>  The test cases validation/api/pktio_run.sh and
>>>>> validation/api/pktio_run_tap.sh are failing on Travis for the
>>>>> following configurations:
>>>>>
>>>>> [image: Inline images 1]
>>>>>
>>>>> I am not able to reproduce these issues on my local machine. How do I
>>>>> debug these? Is there any more log information that I can get from Travis?
>>>>>
>>>>> The merge is available at: https://github.com/nagarah
>>>>> alli/odp/tree/2.0-api-next-merge-11Oct2017.
>>>>>
>>>>> Thank you,
>>>>> Honnappa
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [lng-odp] api-next merge with ODP 2.0

[Maxim Uvarov]

./configure --enable-schedule-scalable
sudo make check

  Test: pktio_test_sched_multi
/include/odp_llqueue.h:269:llq_dequeue_cond():node->next == SENTINEL
Aborted

full log is attached.



On 16 October 2017 at 19:53, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Dmitry had taken a look at these. He mentioned they can be ignored for now.
> Thanks,
> Honnappa
>
> On 16 October 2017 at 03:52, Maxim Uvarov  wrote:
>
>> bootstrap generates a lot of errors, I can reproduce them locally also
>>
>> https://travis-ci.org/nagarahalli/odp/jobs/287783022
>>
>> On 16 October 2017 at 09:21, Maxim Uvarov 
>> wrote:
>>
>>> I will take a look. But please check that you added this 3 commits.
>>>
>>>
>>> c16af648 travis: purge dpdk cache on version change
>>> 3cb45201 travis: build dpdk for general cpu
>>> 73bc4619 travis: temporary turn off dpdk caching
>>>
>>> In general Travis stopped due to no output. You can make tests more
>>> verbose with make check V=1
>>>
>>> But I would start with adding dpdk commits because without them result
>>> was also unclear.
>>>
>>> Maxim.
>>>
>>>
>>> On 16 October 2017 at 06:45, Honnappa Nagarahalli <
>>> honnappa.nagaraha...@linaro.org> wrote:
>>>
>>>> Hi Maxim,
>>>>  The test cases validation/api/pktio_run.sh and
>>>> validation/api/pktio_run_tap.sh are failing on Travis for the
>>>> following configurations:
>>>>
>>>> [image: Inline images 1]
>>>>
>>>> I am not able to reproduce these issues on my local machine. How do I
>>>> debug these? Is there any more log information that I can get from Travis?
>>>>
>>>> The merge is available at: https://github.com/nagarah
>>>> alli/odp/tree/2.0-api-next-merge-11Oct2017.
>>>>
>>>> Thank you,
>>>> Honnappa
>>>>
>>>
>>>
>>
>
running with pktio_main: 
pktio: using 'loop' device
_ishm.c:881:_odp_ishm_reserve():No huge pages, fall back to normal pages. check: /proc/sys/vm/nr_hugepages.
HW time counter freq: 2494233922 hz

 PKTIO: initialized ipc interface.
 PKTIO: initialized loop interface.
 PKTIO: initialized socket mmsg,use export ODP_PKTIO_DISABLE_SOCKET_MMSG=1 to disable.
 PKTIO: initialized socket mmap, use export ODP_PKTIO_DISABLE_SOCKET_MMAP=1 to disable.
 PKTIO: initialized pcap interface.
	ODP API version: 1.15.0
	ODP implementation name:linux-generic
	ODP implementation version: linux-generic 1.15.0-0 (v1.15.0) 1.15.0.0


 CUnit - A unit testing framework for C - Version 2.1-3
 http://cunit.sourceforge.net/

No interfaces specified, using default "loop".

Suite: Packet I/O Unsegmented
  Test: pktio_test_open ...pktio/socket.c:513:sock_setup_pkt():ioctl(SIOCGIFINDEX): No such device: "nothere".
pktio/socket.c:118:mac_addr_get_fd():ioctl(SIOCGIFHWADDR): No such device: "nothere".
odp_packet_io.c:204:setup_pktio_entry():Unable to init any I/O type.
passed
  Test: pktio_test_lookup ...passed
  Test: pktio_test_index ...passed
  Test: pktio_test_print ... 
pktio
  handle1
  name  loop
  type  loop
  state opened
  mac   02:e9:34:80:73:01
  mtu   2147483647
  promisc   no
  max input queues  1
  max output queues 1
 
passed
  Test: pktio_test_pktio_config ...passed
  Test: pktio_test_info ...pktio 0
  name   loop
  driver loop
passed
  Test: pktio_test_pktin_queue_config_direct ...passed
  Test: pktio_test_pktin_queue_config_sched ...passed
  Test: pktio_test_pktin_queue_config_queue ...passed
  Test: pktio_test_pktout_queue_config ...passed
  Test: pktio_test_plain_queue ...passed
  Test: pktio_test_plain_multi ...passed
  Test: pktio_test_sched_queue ...passed
  Test: pktio_test_sched_multi ...passed
  Test: pktio_test_recv ...passed
  Test: pktio_test_recv_multi ...passed
  Test: pktio_test_recv_queue ...passed
  Test: pktio_test_recv_tmo ...passed
  Test: pktio_test_recv_mq_tmo ...passed
  Test: pktio_test_recv_mtu ...passed
  Test: pktio_test_mtu ... 2147483647 passed
  Test: pktio_test_promisc ...passed
  Test: pktio_test_mac ...testing mac for loop
 2:E9:34:80:73:1 
 mac address set not supported for loop!
passed
  Test: pktio_test_start_stop ...passed
  Test: pktio_test_recv_on_wonly ...passed
  Test: pktio_test_send_on_ronly ...passed
  Test: pktio_test_plain_multi_event ...passed
  Test: pktio_test_sched_multi_event ...passed
  Test: pktio_test_recv_multi_event ...passed
  Test: pktio_test_statistics_counters ...passed
  Test: pktio_test_pktin_ts ...passedNo interfaces specified, using default "loop".

Suite: P

Re: [lng-odp] api-next merge with ODP 2.0

[Maxim Uvarov]

bootstrap generates a lot of errors, I can reproduce them locally also

https://travis-ci.org/nagarahalli/odp/jobs/287783022

On 16 October 2017 at 09:21, Maxim Uvarov  wrote:

> I will take a look. But please check that you added this 3 commits.
>
>
> c16af648 travis: purge dpdk cache on version change
> 3cb45201 travis: build dpdk for general cpu
> 73bc4619 travis: temporary turn off dpdk caching
>
> In general Travis stopped due to no output. You can make tests more
> verbose with make check V=1
>
> But I would start with adding dpdk commits because without them result was
> also unclear.
>
> Maxim.
>
>
> On 16 October 2017 at 06:45, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
>> Hi Maxim,
>>  The test cases validation/api/pktio_run.sh and
>> validation/api/pktio_run_tap.sh are failing on Travis for the following
>> configurations:
>>
>> [image: Inline images 1]
>>
>> I am not able to reproduce these issues on my local machine. How do I
>> debug these? Is there any more log information that I can get from Travis?
>>
>> The merge is available at: https://github.com/nagarah
>> alli/odp/tree/2.0-api-next-merge-11Oct2017.
>>
>> Thank you,
>> Honnappa
>>
>
>

Re: [lng-odp] api-next merge with ODP 2.0

[Maxim Uvarov]

I will take a look. But please check that you added this 3 commits.


c16af648 travis: purge dpdk cache on version change
3cb45201 travis: build dpdk for general cpu
73bc4619 travis: temporary turn off dpdk caching

In general Travis stopped due to no output. You can make tests more verbose
with make check V=1

But I would start with adding dpdk commits because without them result was
also unclear.

Maxim.


On 16 October 2017 at 06:45, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Hi Maxim,
>  The test cases validation/api/pktio_run.sh and
> validation/api/pktio_run_tap.sh are failing on Travis for the following
> configurations:
>
> [image: Inline images 1]
>
> I am not able to reproduce these issues on my local machine. How do I
> debug these? Is there any more log information that I can get from Travis?
>
> The merge is available at: https://github.com/
> nagarahalli/odp/tree/2.0-api-next-merge-11Oct2017.
>
> Thank you,
> Honnappa
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

On 6 October 2017 at 22:26, Bill Fischofer 
wrote:

> PR #225 [1] is a good example of the sort of packaging/distro problem ODP
> wants to solve. DPDK currently requires special compile flags to determine
> the microarchitecture it's running on. As a result, Travis broke when they
> deployed new test machines that had a different microarchitecture. To get
> around this we need to compile DPDK to disable any such optimizations so it
> uses its least-common-denominator code. That's exactly what we don't want
> in ODP.
>
>
even more than that dpdk will not compile at all without SSE instructions.
Minimum cpu
level is core2 (-march=core2). They even do not have "generic" platform
(code without -march will not compile).
So it's why hack to make it work on any hardware. It will be great feature
that you can run application
without thinking to configure it to specific cpu, i.e. not care if it's
Ivybridge, Sandybridge,
some other x86_64 and etc.

Maxim.



> So ODP needs to determine this at run time and adapt accordingly, as
> François mentions.
>
> ---
> [1] https://github.com/Linaro/odp/pull/225
>
> On Fri, Oct 6, 2017 at 12:42 PM, Francois Ozog 
> wrote:
>
> > Hi Petri,
> >
> > DPDK modules are not allowing DPDK to adapt to underlying architecture.
> It
> > is just pugable HW.
> > The DDF will  deal with that.
> >
> > The problem we need to solve is architecture adaptation. where the CORE
> of
> > the application changes. there is a single DPDK core with drivers. ODP
> has
> > different CORES (one for each SoC implementation) and several plugable
> > driver through DDF.
> >
> > So the DPDK model is not comparable.
> >
> > The Xorg model is closer but still Xorg CORE does not change based on the
> > GPU/FrameBuffer plugins.
> >
> > ANd last, but not least, all those things are INSTALL time stuff. Which
> we
> > care for NEPs as I mentioned in the use cases, but is not enough to deal
> > with arbitrary INSTANTIATION.
> >
> > Cordially,
> >
> > FF
> >
> > On 6 October 2017 at 15:36, Savolainen, Petri (Nokia - FI/Espoo) <
> > petri.savolai...@nokia.com> wrote:
> >
> > > > > No, I'm pointing that the more there's common core SW, the more
> there
> > > > > are trade-offs and the less direct HW access == less  performance.
> > For
> > > > > optimal performance, the amount of common core SW is zero.
> > > >
> > > > Yes this is sort of the ideal but I doubt this type of installation
> > > > will be accepted by e.g. Red Hat for inclusion in server-oriented
> > > > Linux distributions. Jon Masters seems to be strongly against this
> > > > (although I have only heard this second hand). So that's why I
> > > > proposed the common (generic) core + platform specific drivers model
> > > > that is used by e.g. Xorg and DPDK. Since DPDK is actually a user
> > > > space framework (unlike Xorg), this should be a good model for ODP
> and
> > > > something that Red Hat cannot object against.
> > > >
> > >
> > > If every line of code is maintained properly, why a distro would care
> > > about the ratio between common core SW and HW specific driver SW?
> > >
> > > If they care, what is an acceptable ratio? Is it 90% common SW : 10% HW
> > > specific SW, 80:20, 50:50, 10:90 and why not 0:100? How this ratio
> should
> > > be calculated?
> > >
> > > DPDK is in Ubuntu already. Have anyone calculated what this ratio is
> for
> > > it?
> > >
> > > I'd be interested to see ODP as part of any distro first, and only
> after
> > > that speculate what other distros may or may not say. E.g. Ubuntu seem
> to
> > > accept  packages that are only for single arch, e.g.:
> > > librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red
> > > Rock Canyon net driver, provided only for x86
> > >
> > > -Petri
> > >
> > >
> > >
> >
> >
> > --
> > [image: Linaro] 
> > François-Frédéric Ozog | *Director Linaro Networking Group*
> > T: +33.67221.6485
> > francois.o...@linaro.org | Skype: ffozog
> >
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

http://pkgs.fedoraproject.org/cgit/rpms/dpdk.git/tree/dpdk.spec

On 6 October 2017 at 20:17, Maxim Uvarov  wrote:

>
>
> On 6 October 2017 at 20:05, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
>> Any experts on how is the packaging done for DPDK?
>>
>>
> ./pkg/dpdk.spec  ?
>
>
>> On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>> >> > No, I'm pointing that the more there's common core SW, the more there
>> >> > are trade-offs and the less direct HW access == less  performance.
>> For
>> >> > optimal performance, the amount of common core SW is zero.
>> >>
>> >> Yes this is sort of the ideal but I doubt this type of installation
>> >> will be accepted by e.g. Red Hat for inclusion in server-oriented
>> >> Linux distributions. Jon Masters seems to be strongly against this
>> >> (although I have only heard this second hand). So that's why I
>> >> proposed the common (generic) core + platform specific drivers model
>> >> that is used by e.g. Xorg and DPDK. Since DPDK is actually a user
>> >> space framework (unlike Xorg), this should be a good model for ODP and
>> >> something that Red Hat cannot object against.
>> >>
>> >
>> > If every line of code is maintained properly, why a distro would care
>> about the ratio between common core SW and HW specific driver SW?
>> >
>> > If they care, what is an acceptable ratio? Is it 90% common SW : 10% HW
>> specific SW, 80:20, 50:50, 10:90 and why not 0:100? How this ratio should
>> be calculated?
>> >
>> > DPDK is in Ubuntu already. Have anyone calculated what this ratio is
>> for it?
>> >
>> > I'd be interested to see ODP as part of any distro first, and only
>> after that speculate what other distros may or may not say. E.g. Ubuntu
>> seem to accept  packages that are only for single arch, e.g.:
>> > librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red
>> Rock Canyon net driver, provided only for x86
>> >
>> > -Petri
>> >
>> >
>>
>
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

On 6 October 2017 at 20:05, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Any experts on how is the packaging done for DPDK?
>
>
./pkg/dpdk.spec  ?


> On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
> >> > No, I'm pointing that the more there's common core SW, the more there
> >> > are trade-offs and the less direct HW access == less  performance. For
> >> > optimal performance, the amount of common core SW is zero.
> >>
> >> Yes this is sort of the ideal but I doubt this type of installation
> >> will be accepted by e.g. Red Hat for inclusion in server-oriented
> >> Linux distributions. Jon Masters seems to be strongly against this
> >> (although I have only heard this second hand). So that's why I
> >> proposed the common (generic) core + platform specific drivers model
> >> that is used by e.g. Xorg and DPDK. Since DPDK is actually a user
> >> space framework (unlike Xorg), this should be a good model for ODP and
> >> something that Red Hat cannot object against.
> >>
> >
> > If every line of code is maintained properly, why a distro would care
> about the ratio between common core SW and HW specific driver SW?
> >
> > If they care, what is an acceptable ratio? Is it 90% common SW : 10% HW
> specific SW, 80:20, 50:50, 10:90 and why not 0:100? How this ratio should
> be calculated?
> >
> > DPDK is in Ubuntu already. Have anyone calculated what this ratio is for
> it?
> >
> > I'd be interested to see ODP as part of any distro first, and only after
> that speculate what other distros may or may not say. E.g. Ubuntu seem to
> accept  packages that are only for single arch, e.g.:
> > librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red
> Rock Canyon net driver, provided only for x86
> >
> > -Petri
> >
> >
>

Re: [lng-odp] [PATCH v2 1/1] api & linux-generic: fixing typos

[Maxim Uvarov]

any patch which touch api spec has to be named:
api: and be considered for api-next branch first.

please split this patch on 2 patches (api: and linux-gen:)

Maxim.

On 10/05/17 15:00, Github ODP bot wrote:
> From: Mykyta Iziumtsev 
> 
> Signed-off-by: Mykyta Iziumtsev 
> ---
> /** Email created from pull request 215 (MykytaI:fixing-typos)
>  ** https://github.com/Linaro/odp/pull/215
>  ** Patch: https://github.com/Linaro/odp/pull/215.patch
>  ** Base sha: 52cfe7ba6d2541cf5ee464e46e91b2da5efe1497
>  ** Merge commit sha: 15f371d667f5de257a7f87d952ed6478c9986ff2
>  **/
>  include/odp/api/spec/packet.h| 4 ++--
>  include/odp/api/spec/traffic_mngr.h  | 6 +++---
>  platform/linux-generic/doc/platform_specific.dox | 2 +-
>  platform/linux-generic/include/odp/api/plat/traffic_mngr_types.h | 2 +-
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/include/odp/api/spec/packet.h b/include/odp/api/spec/packet.h
> index 79d8773e9..fbac33cf7 100644
> --- a/include/odp/api/spec/packet.h
> +++ b/include/odp/api/spec/packet.h
> @@ -904,7 +904,7 @@ odp_packet_t odp_packet_ref_static(odp_packet_t pkt);
>   * dynamic references must not be mixed. Results are undefined if these
>   * restrictions are not observed.
>   *
> - * The packet handle 'pkt' may itself by a (dynamic) reference to a packet.
> + * The packet handle 'pkt' may itself be a (dynamic) reference to a packet.
>   *
>   * If the caller does not intend to modify either the packet or the new
>   * reference to it, odp_packet_ref_static() may be used to create
> @@ -931,7 +931,7 @@ odp_packet_t odp_packet_ref(odp_packet_t pkt, uint32_t 
> offset);
>   * packet consists metadata and data of the 'hdr' packet, followed by the
>   * shared part of packet 'pkt'.
>   *
> - * The packet handle ('pkt') may itself by a (dynamic) reference to a packet,
> + * The packet handle ('pkt') may itself be a (dynamic) reference to a packet,
>   * but the header packet handle ('hdr') must be unique. Both packets must be
>   * have been allocated from the same pool and the handles must not refer to
>   * the same packet. Results are undefined if these restrictions are not
> diff --git a/include/odp/api/spec/traffic_mngr.h 
> b/include/odp/api/spec/traffic_mngr.h
> index 3a748cef7..c9134e8e4 100644
> --- a/include/odp/api/spec/traffic_mngr.h
> +++ b/include/odp/api/spec/traffic_mngr.h
> @@ -75,7 +75,7 @@ extern "C" {
>  
>  /**
>   * @def ODP_TM_MAX_TM_QUEUES
> - * The largest number of tm_queues that can handled by any one TM system.
> + * The largest number of tm_queues that can be handled by any one TM system.
>   */
>  
>  /**
> @@ -97,7 +97,7 @@ extern "C" {
>  
>  /**
>   * @def ODP_TM_MIN_SHAPER_BW
> - * The largest amount of bandwidth that any shaper's peak or commit rate can
> + * The lowest amount of bandwidth that any shaper's peak or commit rate can
>   * be set to. It is in units of 1000 bytes/second.
>   */
>  
> @@ -143,7 +143,7 @@ extern "C" {
>  
>  /**
>   * @typedef odp_tm_node_t
> - * Each odp_tm_queue_t value is an opaque ODP handle representing a specific
> + * Each odp_tm_node_t value is an opaque ODP handle representing a specific
>   * tm node within a specific TM system.
>   */
>  
> diff --git a/platform/linux-generic/doc/platform_specific.dox 
> b/platform/linux-generic/doc/platform_specific.dox
> index e116ec617..c26661484 100644
> --- a/platform/linux-generic/doc/platform_specific.dox
> +++ b/platform/linux-generic/doc/platform_specific.dox
> @@ -28,7 +28,7 @@
>   *   to odp_init_local() is actually fully defined by these
>   *   requirements: It has to be the value returned by the
>   *   unique call to odp_init_global() made by one single
> - *   acsendant of the current process.
> + *   ascendant of the current process.
>   */
>  
>  /**
> diff --git a/platform/linux-generic/include/odp/api/plat/traffic_mngr_types.h 
> b/platform/linux-generic/include/odp/api/plat/traffic_mngr_types.h
> index f47a13f6f..be3926d46 100644
> --- a/platform/linux-generic/include/odp/api/plat/traffic_mngr_types.h
> +++ b/platform/linux-generic/include/odp/api/plat/traffic_mngr_types.h
> @@ -56,7 +56,7 @@ extern "C" {
>  #define ODP_TM_MAX_SCHED_WEIGHT  255
>  
>  /** The ODP_TM_MAX_TM_QUEUES constant is the largest number of tm_queues
> - * that can handled by any one TM system.
> + * that can be handled by any one TM system.
>   */
>  #define ODP_TM_MAX_TM_QUEUES  (16 * 1024 * 1024)
>  
> 

Re: [lng-odp] DPDK pktio tests failure

[Maxim Uvarov]

2 issues with dpdk pktio found yesterday:

1) Krishnas update of dpdk version did something wrong with Travis
cache. So I had to clear it.

2) Zero copy dpdk has some issues now. We need to understand what is it.

Maxim.


On 10/05/17 08:56, Bogdan Pricope wrote:
> ... or dpdk tests are really failing...
> 
> 
> # ./test/linux-generic/validation/api/pktio/pktio_run_dpdk.sh
> running with pktio_main:
> pktio: setting up test interfaces pktiop0p1, pktiop1p0, pktiop2p3, pktiop3p2.
> HW time counter freq: 3092977409 hz
> 
>  PKTIO: initialized loop interface.
>  PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to 
> disable.
>  PKTIO: initialized pcap interface.
>  PKTIO: initialized ipc interface.
>  PKTIO: initialized socket mmap, use export
> ODP_PKTIO_DISABLE_SOCKET_MMAP=1 to disable.
>  PKTIO: initialized socket mmsg,use export
> ODP_PKTIO_DISABLE_SOCKET_MMSG=1 to disable.
> ODP API version: 1.15.0
> ODP implementation name:"odp-linux"
> ODP implementation version: "odp-linux" 1.15.0-0 (v1.15.0) 1.15.0.0
> 
> 
>  CUnit - A unit testing framework for C - Version 2.1-2
>  http://cunit.sourceforge.net/
> 
> Using paired interfaces: 0 1
> EAL: Detected 4 lcore(s)
> PMD: Initializing pmd_pcap for eth_pcap0
> PMD: Creating pcap-backed ethdev on numa socket 0
> PMD: Initializing pmd_pcap for eth_pcap1
> PMD: Creating pcap-backed ethdev on numa socket 0
> 
> Suite: Packet I/O Unsegmented
>   Test: pktio_test_open ...pktio/dpdk.c:1163:dpdk_open():Invalid dpdk
> netdev: nothere
> pktio/socket.c:119:mac_addr_get_fd():ioctl(SIOCGIFHWADDR): No such
> device: "nothere".
> pktio/socket.c:511:sock_setup_pkt():ioctl(SIOCGIFINDEX): No such
> device: "nothere".
> odp_packet_io.c:229:setup_pktio_entry():Unable to init any I/O type.
> passed
>   Test: pktio_test_lookup ...passed
>   Test: pktio_test_index ...passed
>   Test: pktio_test_print ...
> pktio
>   handle1
>   name  0
>   type  dpdk
>   state opened
>   mac   00:00:00:01:02:03
>   mtu   8064
>   promisc   no
>   max input queues  1
>   max output queues 1
> 
> 
> pktio
>   handle1
>   name  1
>   type  dpdk
>   state opened
>   mac   00:00:00:01:02:03
>   mtu   8064
>   promisc   no
>   max input queues  1
>   max output queues 1
> 
> passed
>   Test: pktio_test_pktio_config ...passed
>   Test: pktio_test_info ...pktio 0
>   name   0
>   driver dpdk
> pktio 1
>   name   1
>   driver dpdk
> passed
>   Test: pktio_test_pktin_queue_config_direct ...passed
>   Test: pktio_test_pktin_queue_config_sched ...passed
>   Test: pktio_test_pktin_queue_config_queue ...passed
>   Test: pktio_test_pktout_queue_config ...passed
>   Test: pktio_test_plain_queue ...error: header magic invalid 8650752
> error: header magic invalid 393473
> error: header magic invalid 0
> error: header magic invalid 0
> error: header magic invalid 393473
> FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_plain_multi ...error: header magic invalid 0
> error: header magic invalid 393473
> FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_sched_queue ...error: header magic invalid 393473
> error: header magic invalid 393473
> FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_sched_multi ...FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_recv ...FAILED
> 1. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_recv_multi ...error: header magic invalid 393473
> FAILED
> 1. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_recv_queue ...FAILED
> 1. pktio.c:890  - num_rx == TX_BATCH_LEN
>   Test: pktio_test_recv_tmo ...passed
>   Test: pktio_test_recv_mq_tmo ...passed
>   Test: pktio_test_recv_mtu ...error: header magic invalid 0
> error: header magic invalid 0
> error: header magic invalid 0
> error: header magic invalid 0
> FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_mtu ... 8064 passed
>   Test: pktio_test_promisc ...passed
>   Test: pktio_test_mac ...testing mac for 0
>  0:0:0:1:2:3 passed
>   Test: pktio_test_start_stop ...passed
>   Test: pktio_test_recv_on_wonly ...passed
>   Test: pktio_test_send_on_ronly ...passed
>   Test: pktio_test_plain_multi_event ...FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_sched_multi_event ...FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_recv_multi_event ...FAILED
> 1. pktio.c:661  - num_rx == num_pkts
> 2. pktio.c:661  - num_rx == num_pkts
>   Test: pktio_test_statistics_counters