Re: [lng-odp] [API-NEXT PATCH] linux-gen: queue: clean up after modular interface

On 12 June 2017 at 06:11, Petri Savolainen wrote: > Clean up function and parameter naming after modular interface > patch. Queue_t type is referred as "queue internal": queue_int or > q_int. Term "handle" is reserved for API level handles (e.g. > odp_queue_t,

[lng-odp] [Linaro/odp] 25e989: test: l2fwd pass under coverage

Branch: refs/heads/next Home: https://github.com/Linaro/odp Commit: 25e9897154f52f196b452ace7aa6a01899685c18 https://github.com/Linaro/odp/commit/25e9897154f52f196b452ace7aa6a01899685c18 Author: Maxim Uvarov Date: 2017-06-16 (Fri, 16 Jun 2017)

Re: [lng-odp] [PATCH v4 0/2] GCC 7 fixes

On 15 June 2017 at 16:20, Maxim Uvarov wrote: > On 06/15/17 11:50, Dmitry Eremin-Solenikov wrote: >> On 15.06.2017 11:47, shally verma wrote: >>> Does it mean that going further there would be certain limitation on >>> gcc version to be used? I just tried to compile next

[lng-odp] [Linaro/odp] 974e44: test: l2fwd pass under coverage

Branch: refs/heads/api-next Home: https://github.com/Linaro/odp Commit: 974e4477a35742b8021e25692a458d16cd2087f1 https://github.com/Linaro/odp/commit/974e4477a35742b8021e25692a458d16cd2087f1 Author: Maxim Uvarov Date: 2017-06-16 (Fri, 16 Jun 2017)

[lng-odp] [Linaro/odp] aadd1d: configure.ac: do not trap if libatomic is not foun...

Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: aadd1d62084191bf2fb909a7dbedee628b197929 https://github.com/Linaro/odp/commit/aadd1d62084191bf2fb909a7dbedee628b197929 Author: Maxim Uvarov Date: 2017-06-15 (Thu, 15 Jun 2017)

[lng-odp] [PATCH API-NEXT v1 0/1] api: schedule: add thread removal correction

Clarify thread removal status from scheduler group before calling odp_schedule_group_destroy. Signed-off-by: Honnappa Nagarahalli honnappa.nagaraha...@arm.com Reviewed-by: Brian Brooks brian.bro...@arm.com Reviewed-by: Ola Liljedahl ola.liljed...@arm.com

[lng-odp] [PATCH API-NEXT v1 1/1] api: schedule: add thread removal correction

From: Honnappa Nagarahalli Clarify thread removal status from scheduler group before calling odp_schedule_group_destroy. Signed-off-by: Honnappa Nagarahalli Reviewed-by: Brian Brooks Reviewed-by: Ola Liljedahl

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Honnappa Nagarahalli Sent: Friday, June 16, 2017 12:51 AM To: Bala Manoharan Cc: lng-odp-forward Subject: Re: [lng-odp] Mem pool creation in

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

On 15 June 2017 at 13:02, Bala Manoharan wrote: > > > Regards, > Bala > > On 15 June 2017 at 23:20, Honnappa Nagarahalli > wrote: >> >> On 15 June 2017 at 10:58, Bala Manoharan >> wrote: >> > On 15 June 2017

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

Regards, Bala On 15 June 2017 at 23:20, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> wrote: > On 15 June 2017 at 10:58, Bala Manoharan > wrote: > > On 15 June 2017 at 20:00, Francois Ozog > wrote: > > > >> I wonder then how packet

Re: [lng-odp] [PATCH API-NEXT v1 4/4] travis: add scalable scheduler in CI

This is fixed. My api-next branch had these extra commits from somewhere. It is corrected now. On 15 June 2017 at 01:40, Dmitry Eremin-Solenikov wrote: > On 15.06.2017 05:53, Honnappa Nagarahalli wrote: >> This should be the only patch to review. Don't know why

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

On 15 June 2017 at 10:58, Bala Manoharan wrote: > On 15 June 2017 at 20:00, Francois Ozog wrote: > >> I wonder then how packet receive in HW driven packet buffers is handled, >> may be with device memory >> >> Can you explain the cases of

[lng-odp] [PATCH v1 0/1] configure.ac: do not trap if libatomic is not found

Idea if check was to detect if libatomic is needed or not, not trap configure on not case Fixes Linaro CI compilation for: gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabih Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org github /** Email created from

[lng-odp] [PATCH v1 1/1] configure.ac: do not trap if libatomic is not found

From: Maxim Uvarov Idea if check was to detect if libatomic is needed or not, not trap configure on not case Fixes Linaro CI compilation for: gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabih Signed-off-by: Maxim Uvarov --- /** Email created

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

I think I do now. So antoher question: from device memory to host memory, is it a DMA transfer for some other SoC specific technology? Cordially, FF On 15 June 2017 at 17:58, Bala Manoharan wrote: > > On 15 June 2017 at 20:00, Francois Ozog

[lng-odp] [PATCH API-NEXT v2 0/1] Add scalable scheduler for travis CI

github /** Email created from pull request 50 (nagarahalli:api-next-travis) ** https://github.com/Linaro/odp/pull/50 ** Patch: https://github.com/Linaro/odp/pull/50.patch ** Base sha: 4f97e500a097928e308a415c32a88465adc5f5cc ** Merge commit sha:

[lng-odp] [PATCH API-NEXT v2 1/1] travis: add scalable scheduler in CI

From: Honnappa Nagarahalli Added running tests with scalable scheduler to CI Signed-off-by: Honnappa Nagarahalli Reviewed-by: Brian Brooks --- /** Email created from pull request 50 (nagarahalli:api-next-travis)

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

On 15 June 2017 at 20:00, Francois Ozog wrote: > I wonder then how packet receive in HW driven packet buffers is handled, > may be with device memory > > Can you explain the cases of packet receive with ODP application supplied > (through packetio open) mempools? >

[lng-odp] [PATCH API-NEXT v4 3/4] travis: add sudo run make check

From: Maxim Uvarov make check has to be under root to validate pktio like raw sockets. Also odp temporary files can overlap with previous root run and permission to overwrite that files is needed. Signed-off-by: Maxim Uvarov --- /** Email

[lng-odp] [PATCH API-NEXT v4 1/4] test: l2fwd pass under coverage

From: Maxim Uvarov env variable TEST=coverage is set, use it to not fail under gcov run which is really slow. Signed-off-by: Maxim Uvarov --- /** Email created from pull request 49 (muvarov:api-next_travis_fixes) **

[lng-odp] [PATCH API-NEXT v4 0/4] travis: add sudo for missing tests

Add sudo to make tests run which require root. Also do not run tests in parallel for coverage case. It's already very slow and performance tests eat all cpu time. So the is situation where tests can not fit in any reasonable limit frames. Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org

[lng-odp] [PATCH API-NEXT v4 4/4] travis: do not run performance test in parallel under coverage

From: Maxim Uvarov Performance tests have some limits to detect if they pass or fail but under coverage execution is slow, running tests in parallel is also very slow. Without that patch scheduler test simetimes fails. Signed-off-by: Maxim Uvarov

[lng-odp] [PATCH API-NEXT v4 2/4] build: fix order of test execution

From: Maxim Uvarov l2fwd perf test requires odp_generator from examples. Make sure that examples already build when make check is run. https://bugs.linaro.org/show_bug.cgi?id=2938 Signed-off-by: Maxim Uvarov --- /** Email created from pull

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

I wonder then how packet receive in HW driven packet buffers is handled, may be with device memory Can you explain the cases of packet receive with ODP application supplied (through packetio open) mempools? FF On 15 June 2017 at 15:42, Bala Manoharan wrote: >

[lng-odp] [API-NEXT PATCH v3] api: pool: additional packet length configuration

Added packet pool parameters for more fine grained pool configuration. The basic usage of the parameters is not changed, except that implementation may now round up 'num' by default. Application can limit the round up with new 'max_num' parameter. Another new parameter (opt) allows application

[lng-odp] [PATCH API-NEXT v3 3/3] travis: add sudo run make check

From: Maxim Uvarov make check has to be under root to validate pktio like raw sockets. Also odp temporary files can overlap with previous root run and permission to overwrite that files is needed. Signed-off-by: Maxim Uvarov --- /** Email

[lng-odp] [PATCH API-NEXT v3 2/3] build: fix order of test execution

From: Maxim Uvarov l2fwd perf test requires odp_generator from examples. Make sure that examples already build when make check is run. https://bugs.linaro.org/show_bug.cgi?id=2938 Signed-off-by: Maxim Uvarov --- /** Email created from pull

[lng-odp] [PATCH API-NEXT v3 1/3] test: l2fwd pass under coverage

From: Maxim Uvarov env variable TEST=coverage is set, use it to not fail under gcov run which is really slow. Signed-off-by: Maxim Uvarov --- /** Email created from pull request 49 (muvarov:api-next_travis_fixes) **

[lng-odp] [PATCH API-NEXT v3 0/3] travis: add sudo for missing tests

Add sudo to make tests run which require root. Also do not run tests in parallel for coverage case. It's already very slow and performance tests eat all cpu time. So the is situation where tests can not fit in any reasonable limit frames. Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

Add on. It is also possible that the pool might not be linked to any pktio eg buffer pools, hence in implementation we can not wait for the pool to be linked to pktio. Regards, Bala On 15 June 2017 at 18:11, Bill Fischofer wrote: > A pool may be associated with a

Re: [lng-odp] [PATCH v4 0/2] GCC 7 fixes

On 06/15/17 11:50, Dmitry Eremin-Solenikov wrote: > On 15.06.2017 11:47, shally verma wrote: >> Does it mean that going further there would be certain limitation on >> gcc version to be used? I just tried to compile next branch and >> ./configure throws an error >> >> ./configure: line 22786:

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

A pool may be associated with a pktio at open time, but this association is not exclusive. In theory an ODP implementation could defer actual pool creation until it was first used, but such an approach would be unlikely to yield any real benefits while creating a lot of complications along the way

Re: [lng-odp] [PATCH API-NEXT 1/2] linux-generic: events subtype implementation

> index d71f4464af48..3cd4a73cbefb 100644 > --- a/platform/linux-generic/odp_event.c > +++ b/platform/linux-generic/odp_event.c > @@ -19,6 +19,11 @@ odp_event_type_t odp_event_type(odp_event_t event) > return _odp_buffer_event_type(odp_buffer_from_event(event)); > } > >

Re: [lng-odp] [API-NEXT PATCH v2 1/3] api: event: add subtype to expand event type

> > /** > > - * Get event type > > + * @typedef odp_event_subtype_t > > + * Event subtype > > * > > - * @param eventEvent handle > > + * Event subtype expands event type specification by providing more > detailed > > + * purpose and format of an event. It can be checked with >

Re: [lng-odp] [PATCH v4 0/2] GCC 7 fixes

On 15.06.2017 11:47, shally verma wrote: > Does it mean that going further there would be certain limitation on > gcc version to be used? I just tried to compile next branch and > ./configure throws an error > > ./configure: line 22786: syntax error near unexpected token >

Re: [lng-odp] [PATCH v4 0/2] GCC 7 fixes

Does it mean that going further there would be certain limitation on gcc version to be used? I just tried to compile next branch and ./configure throws an error ./configure: line 22786: syntax error near unexpected token `-Wimplicit-fallthrough=0,' ./configure: line 22786:

[lng-odp] [PATCH API-NEXT v1 0/1] linux-generic: crypto: adapt HMAC code to OpenSSL 1.1.x

OpenSSL 1.1.x has changed HMAC API in an incompatible way. Let's adapt to it by providing version-dependent wrapper around HMAC calculation. Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org github /** Email created from pull request

[lng-odp] [PATCH API-NEXT v1 1/1] linux-generic: crypto: adapt HMAC code to OpenSSL 1.1.x

From: Dmitry Eremin-Solenikov OpenSSL 1.1.x has changed HMAC API in an incompatible way. Let's adapt to it by providing version-dependent wrapper around HMAC calculation. Signed-off-by: Dmitry Eremin-Solenikov --- /** Email

Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v2 0/2] IPsec API update

Ping. > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Savolainen, Petri (Nokia - FI/Espoo) > Sent: Thursday, June 08, 2017 4:07 PM > To: Bill Fischofer > Cc: lng-odp-forward > Subject:

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: change IPSEC result to packet

> -Original Message- > From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] > Sent: Wednesday, June 14, 2017 8:54 PM > To: Petri Savolainen ; lng- > o...@lists.linaro.org > Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: change

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

Same here. Pool is created during odp_pool_create API. Regards, Bala On 15 June 2017 at 12:36, Nikhil Agarwal wrote: > Pool is created at odp_pool_create only. You can allocate packets form it > even before pktio_open. > > Regards > Nikhil > > -Original

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

Pool is created at odp_pool_create only. You can allocate packets form it even before pktio_open. Regards Nikhil -Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Honnappa Nagarahalli Sent: Thursday, June 15, 2017 9:27 AM To: lng-odp-forward

Re: [lng-odp] [PATCH API-NEXT v1 4/4] travis: add scalable scheduler in CI

On 15.06.2017 05:53, Honnappa Nagarahalli wrote: > This should be the only patch to review. Don't know why GitHub sent > other patches in this series. Because scripts will resend whole patch series when PR is updated. -- With best wishes Dmitry