date:20170302

[lng-odp] [Bug 2812] helper/test/process fails on a single core system

2017-03-02 Thread bugzilla-daemon

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

Maxim Uvarov  changed:

   What|Removed |Added

 CC||maxim.uva...@linaro.org

--- Comment #3 from Maxim Uvarov  ---
unable reproduce it on current master 88dbb006 v1.14.0.0+
Please check that bug exist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Bug 2407] test odp_l2fwd_run.sh contains todo items

2017-03-02 Thread bugzilla-daemon

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

--- Comment #5 from Maxim Uvarov  ---
bug todo comment gone. New todo appears:


./test/common_plat/performance/odp_l2fwd_run.sh-# Max 4 workers
./test/common_plat/performance/odp_l2fwd_run.sh:# @todo: ensure that
generator and l2fwd workers are not allocated to
./test/common_plat/performance/odp_l2fwd_run.sh-# the same CPUs

-- 
You are receiving this mail because:
You are the assignee for the bug.

[lng-odp] [Bug 2411] linux-generic/odp_schedule_sp.c contains todo items

2017-03-02 Thread bugzilla-daemon

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

--- Comment #4 from Maxim Uvarov  ---
still exist

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Bug 2826] CID 174664: Unchecked return in pool.c

2017-03-02 Thread bugzilla-daemon

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

Maxim Uvarov  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED
 CC||maxim.uva...@linaro.org

--- Comment #2 from Maxim Uvarov  ---
88dbb006  linux-generic: pool: add odp_pool_capability() rc check

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Linaro/odp] 88dbb0: linux-generic: pool: add odp_pool_capability() rc ...

2017-03-02 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 88dbb00623102878f2e0e1dd720a942fdd980ca3
  
https://github.com/Linaro/odp/commit/88dbb00623102878f2e0e1dd720a942fdd980ca3
  Author: Bill Fischofer 
  Date:   2017-03-02 (Thu, 02 Mar 2017)

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

  Log Message:
  ---
  linux-generic: pool: add odp_pool_capability() rc check

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2826 by adding
an explicit check of the rc from odp_pool_capability() for consistency
with other code that calls this routine.

Signed-off-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov

[lng-odp] [Bug 2889] Unused helper extension code does not build, and is not tested in CI

2017-03-02 Thread bugzilla-daemon

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

Maxim Uvarov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |NON REPRODUCIBLE

--- Comment #1 from Maxim Uvarov  ---
2bac2dbf
unable to reproduce with commit above

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [lng-odp] [API-NEXT PATCH 0/4] Add sha-1 and sha-512

2017-03-02 Thread Maxim Uvarov

Merged,
Will be in the repo soon.

Maxim.

On 1 March 2017 at 14:42, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia-bell-labs.com> wrote:

>
>
> > -Original Message-
> > From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
> > Sent: Tuesday, February 28, 2017 8:21 PM
> > To: Maxim Uvarov 
> > Cc: Petri Savolainen 
> > Subject: Re: [lng-odp] [API-NEXT PATCH 0/4] Add sha-1 and sha-512
> >
> > On 28 February 2017 at 20:04, Maxim Uvarov 
> > wrote:
> > > On 02/28/17 19:35, Dmitry Eremin-Solenikov wrote:
> > >> Hello,
> > >>
> > >> On 23.02.2017 16:06, Dmitry Eremin-Solenikov wrote:
> > >>> On 22.02.2017 18:08, Petri Savolainen wrote:
> >  Add new algorithm enumerations so that vendor IPSEC implementations
> > and IPSEC
> >  test applications can proceed. Odp-linux crypto implementation and
> > validation
> >  tests follow later.
> > 
> >  Petri Savolainen (4):
> >    abi: event: add ODP_EVENT_IPSEC_RESULT
> >    api: crypto: add sha-1 and sha-512 enumerations
> >    linux-gen: crypto: sha-1 and sha-512 not implemented yet
> >    validation: crypto: add stubs for sha-1 and sha-512 tests
> > >>>
> > >>> Reviewed-by: Dmitry Eremin-Solenikov
> > 
> > >>
> > >> Just wondering, is there any issue with this patchset, that stops it
> > >> from being merged?
> > >>
> > >
> > > Dmitri, you said
> > > """
> > > If nobody steps up, I will take a look onto implementing funcionality
> > > and tests. I have several issues with the current code anyway.
> > > """
> > >
> > > so I'm waiting for feedback.
> >
> > Ah. But is there any reason for holding back the API without
> > implementation?
> > Sorry for maybe dump question, I'm still diving in development process.
> >
> > --
> > With best wishes
> > Dmitry
>
> There's no reason to wait for implementation. API spec can go into
> api-next branch before the implementation and tests.
>
> Nikhil asked/suggested if SHA-2 should be used instead of SHA-256,
> SHA-512, etc. I still think that it's better to use the same names for the
> algorithms, as the standards and industry (SDKs, HW manuals) use. E.g. FIPS
> standard for SHA (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.
> pdf and http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf ) and
> RFCs use these names for the algorithms: SHA-1, SHA-256, SHA-512, SHA3-256,
> SHA3-512, SHAKE128. SHA-2 and SHA-3 are family names, but not individual
> algorithm names. SHA-1 is single algorithm (not a family).
>
> So, Maxim please merge this as is. Dmitry then adds implementation changes
> on top.
>
> -Petri
>
>

[lng-odp] [Linaro/odp] 20dd99: api: packet: add support for packet references

2017-03-02 Thread GitHub

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 20dd9920a9666adbbc5700a0c5f91539f36748e0
  
https://github.com/Linaro/odp/commit/20dd9920a9666adbbc5700a0c5f91539f36748e0
  Author: Petri Savolainen 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

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

  Log Message:
  ---
  api: packet: add support for packet references

Introduce new APIs that support efficient sharing of portions of
packets:
 * odp_packet_ref_static() creates a new static reference
   for a packet
 * odp_packet_ref() creates a new dynamic reference to a packet
 * odp_packet_ref_pkt() creates a reference to a packet with
   a supplied header packet
 * odp_packet_has_ref() checks if a packet has multiple
   references to it
 * odp_packet_unshared_len() returns the unshared data length of
   a reference

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


  Commit: 7f67f9c82f0d8454a17c57480e0d042ce4d02c2b
  
https://github.com/Linaro/odp/commit/7f67f9c82f0d8454a17c57480e0d042ce4d02c2b
  Author: Petri Savolainen 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

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

  Log Message:
  ---
  api: packet: references may be implemented as copy

Some implementations may implement new references as packet copy.
odp_packet_has_ref() will return 0 for copies, since those are
unique packets.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 4d2965368138f5980598bff84bb8a5bb23b764ef
  
https://github.com/Linaro/odp/commit/4d2965368138f5980598bff84bb8a5bb23b764ef
  Author: Bill Fischofer 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

  Changed paths:
M test/common_plat/validation/api/packet/packet.c
M test/common_plat/validation/api/packet/packet.h

  Log Message:
  ---
  validation: packet: add packet reference tests

Add validation tests for the new packet reference APIs:
- odp_packet_ref_static()
- odp_packet_ref()
- odp_packet_ref_pkt()
- odp_packet_has_ref()
- odp_packet_unshared_len()

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


  Commit: 6d0a57c69bd41ad152a6366b0563edd2f39381f5
  
https://github.com/Linaro/odp/commit/6d0a57c69bd41ad152a6366b0563edd2f39381f5
  Author: Petri Savolainen 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

  Changed paths:
M test/common_plat/validation/api/packet/packet.c

  Log Message:
  ---
  validation: packet: remove non compatible tests

Tests for bad inputs are not compatible to the spec.
Out-of-range values cause undefined results and must not
be tested in validation suite.

Remove reference checks that do not comply anymore to
the new odp_packet_has_ref() specification.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: ce8fb2e5d86dd2b041d8bd17f7ed46035b516094
  
https://github.com/Linaro/odp/commit/ce8fb2e5d86dd2b041d8bd17f7ed46035b516094
  Author: Petri Savolainen 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

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

  Log Message:
  ---
  linux-gen: packet: implement references as copy

Implement packet references API as packet copy. This is the
simplest way to support the API, as other packet functions
are not affected at all.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: a26219abfccbd1148a1ccbf9648039dd6a790a6e
  
https://github.com/Linaro/odp/commit/a26219abfccbd1148a1ccbf9648039dd6a790a6e
  Author: Yi He 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

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

  Log Message:
  ---
  linux-gen: sched: fix SP scheduler hang in process mode

SP scheduler hangs in process mode performance test
due to global data structure were not created in shared
memory region.

Signed-off-by: Yi He 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 34f63c0cb6421ce32fac1a409cbc75fd1cc8fdbc
  
https://github.com/Linaro/odp/commit/34f63c0cb6421ce32fac1a409cbc75fd1cc8fdbc
  Author: Yi He 
  Date:   2017-03-01 (Wed, 01 Mar 2017)

  Changed paths:
M platform/linux-generic/include/odp_schedule_if.h
M platform/linux-generic/odp_queue.c
M platform/linux-generic/odp_schedule.c
M platform/linux-generic/odp_schedule_sp.c

  Log Message:
  ---
  linux-gen: sched: solve ordered context inversion

For ordered queue, a thread consumes events (dequeue) and
acquires its unique sequential context in two steps, non
atomic and preemptable.

This leads to potential ordered context inversion in case
the thread consumes prior events acquired subsequent context,
while the thread consumes subsequent events but acquired
prior context.

This patch insert the ordered context acquisit

Re: [lng-odp] [PATCH 1/3] helper: linux: add common linux helper file

2017-03-02 Thread Maxim Uvarov

Merged,
Maxim.

On 02/28/17 11:13, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> Ping. This needs to be merged to API next also, so that OFP can build against 
> both branches.
> 
> -Petri
> 
> 
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org] 
> Sent: Wednesday, February 22, 2017 1:54 AM
> To: Petri Savolainen 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] [PATCH 1/3] helper: linux: add common linux helper file
> 
> For this series: 
> 
> Reviewed-and-tested-by: Bill Fischofer 
> 
> On Tue, Feb 21, 2017 at 6:51 AM, Petri Savolainen 
>  wrote:
> Added common helper file for backwards compatibility. This file
> includes all headers under helper/linux directory. It's installed
> only with --enable-helper-linux configuration option.
> 
> Signed-off-by: Petri Savolainen 
> ---
>  helper/Makefile.am|  3 +++
>  helper/include/odp/helper/linux.h | 27 +++
>  2 files changed, 30 insertions(+)
>  create mode 100644 helper/include/odp/helper/linux.h
> 
> 
>

[lng-odp] [Linaro/odp] 39f85b: helper: linux: add common linux helper file

2017-03-02 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 39f85bc6cab329b4ae41ba2ec922370c24254325
  
https://github.com/Linaro/odp/commit/39f85bc6cab329b4ae41ba2ec922370c24254325
  Author: Petri Savolainen 
  Date:   2017-03-02 (Thu, 02 Mar 2017)

  Changed paths:
M helper/Makefile.am
A helper/include/odp/helper/linux.h

  Log Message:
  ---
  helper: linux: add common linux helper file

Added common helper file for backwards compatibility. This file
includes all headers under helper/linux directory. It's installed
only with --enable-helper-linux configuration option.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: e93df7d7b3b278dfadba4a9b7c01afc0dd411f13
  
https://github.com/Linaro/odp/commit/e93df7d7b3b278dfadba4a9b7c01afc0dd411f13
  Author: Petri Savolainen 
  Date:   2017-03-02 (Thu, 02 Mar 2017)

  Changed paths:
M configure.ac
M helper/Makefile.am
R pkgconfig/libodphelper-linux-generic.pc.in
A pkgconfig/libodphelper.pc.in

  Log Message:
  ---
  helper: pkgconfig: remove linux-generic from helper lib name

Helper library should be built ABI compatible when it's part of
a distro. There's no need to have implementation specific helper
libs. Those would be needed only if non-ABI compat helper
libraries need to be distributed.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 2bac2dbfd7a7c55e588a6b72af22ae7b810558f7
  
https://github.com/Linaro/odp/commit/2bac2dbfd7a7c55e588a6b72af22ae7b810558f7
  Author: Petri Savolainen 
  Date:   2017-03-02 (Thu, 02 Mar 2017)

  Changed paths:
M DEPENDENCIES

  Log Message:
  ---
  linux-gen: dependencies: update cunit install instructions

Add missing commands and update instructions for installing into
default location for 'make distcheck'.

Signed-off-by: Petri Savolainen 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/a652887cfeba...2bac2dbfd7a7

Re: [lng-odp] Maintaner change

2017-03-02 Thread Bill Fischofer

Thanks Nicolas, and best wishes. And welcome Jérôme.

On Thu, Mar 2, 2017 at 6:48 AM, Nicolas Morey-Chaisemartin  wrote:

> Hi everyone,
>
> Just to let you know that this is my last week at Kalray.
> Jérome Reybert (I think he's subscribing to this ML already) will be in
> charge of the ODP MPPA port.
>
> If you have any questions on Kalray's port or need some feedback, please
> contact him from now on.
>
> Regards
>
> Nicolas
>
>

Re: [lng-odp] Generic handle in ODP

2017-03-02 Thread Francois Ozog

Thank you for the proposal. I look forward to other ideas you may have.

Cordially

FF

Le jeu. 2 mars 2017 à 13:28, Verma, Shally  a
écrit :

> Humm. I see that a valid point. Yes I agree this proposal will add
> limitations on implementations and app.
>
>
>
> Thanks everyone for your time.
>
>
>
> *From:* Francois Ozog [mailto:francois.o...@linaro.org]
> *Sent:* 02 March 2017 14:44
> *To:* Verma, Shally 
> *Cc:* Maxim Uvarov ; lng-odp@lists.linaro.org
>
>
> *Subject:* Re: [lng-odp] Generic handle in ODP
>
>
>
> Hi Shally,
>
>
>
> I think Bill stated an important aspect. Due to the abstract nature of
> odp_packet_t and odp_buffer_t that can represent VERY different things
> depending on the underlying hardware, we want a strongly typed ODP.
>
>
>
> So regardless of advantages of a common piece of code, your proposal
> contradicts this strong typed objective.
>
>
>
> And if I look at it from a performance perspective, where the specialized
> function would just do the work, may be even inlined, your proposal would
> need type checks and other "safety" checks to perform the task.
>
>
>
> Cordially,
>
>
>
> FF
>
>
>
>
>
>
>
> On 2 March 2017 at 08:30, Verma, Shally  wrote:
>
> Please see my response inline.
>
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Maxim Uvarov
> Sent: 01 March 2017 18:38
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Generic handle in ODP
>
> btw,
>
> if you need to get pool you can use functions:
>
> odp_pool_t odp_packet_pool(odp_packet_t pkt); odp_pool_t
> odp_buffer_pool(odp_buffer_t buf);
>
> If you know event type and pool then you should be able do all you need.
>
> Maxim.
>
> On 03/01/17 15:47, Bill Fischofer wrote:
> > ODP handles are by design abstract types that may have very different
> > internal representations between different ODP implementations. When
> > asking for a generic handle type the question is which types would you
> > expect that to encompass?
> >
> > When we originally started defining the ODP type system we avoided
> > having a generic odp_handle_t supertype specifically to avoid C's
> > issues with weak typing. We wanted ODP to be strongly typed so that,
> > for example, trying to pass an odp_queue_t to an API that expects an
> > odp_packet_t would be flagged at compile time.
> >
> Shally ≫ So you mean doing ' handle=(odp_handle_t) pkt; ' is not
> desirable in example code snippet below.
> It maintains strong typing at API level, but letting app to use it
> int odp_xxx_process_data(odp_handle_t handle, );
>
> main()
> {
>  odp_buffer_t buf=odp_buffer_alloc(buf_pool);
>  odp_packet_t pkt=odp_packet_alloc(pkt_pool);
>
> odp_handle_t handle;
>
>  //process pkt
>  handle=(odp_handle_t) pkt; // is this allowed?
>  odp_xxx_process_data(handle,...);
>
>  //process buffer
>  handle=(odp_handle_t)buf; // is this allowed?
>  odp_xx_process_buf(handle,...)
>
> }
> > As noted in this thread odp_event_t is a generic type that is used to
> > represent entities that can be transmitted through queues and ODP
> > provides type conversion APIs to and from this container type to the
> > specific types (buffer, packet, timeout, crypto completions) that are
> > able to be carried by an event. The intent is that as different event
> > types are added they will similarly be added to this container along
> > with converter APIs. But trying to fit all types into this model seems
> > unnecessary. If you have a use case for wanting to treat some other
> > type as an event we'd be interested in hearing that.
> >
> Shally≫ Event module carry a different purpose in system. They are raised
> as an outcome of an actions initiated on different modules (and thus carry
> need to have convertor APIs). However I didn’t had same purpose and would
> not like to use or extend event for same. Mine was simple use case to
> initiate some common action on different kinds of data and avoiding code
> duplicity.
>
> Thanks
> Shally
>
>
> > On Wed, Mar 1, 2017 at 5:56 AM, Verma, Shally
> > 
> > wrote:
> >
> >> Francois
> >>
> >> It is base assumption that an ODP Interface/implementation supporting
> >> generic handle concept takes due care and record keeping to find out
> >> proper type casting and keeping pool info is one such of them.
> >>
> >> Petri
> >> memcpy() is just an example to explain use case.
> >>
> >> packet APIs are good for interface which always and only process data
> >> of type odp_packet_t however  if anyone would want to extend same API
> >> to support plain buffer type memory as well (thus avoiding
> >> packet_copy_to/from_mem()), then generic handle concept may be helpful.
> >>
> >>
> >> Though it does not come as a MUST requirement but thinking if
> >> flexibility of having generic handle in ODP helps in flexible
> >> implementation where ever it is desirable / needed (of course with due
> care).
> >>
> >> Thanks
> >> Shally
> >>
> >>
> >> From: Francois Ozog [mailto:francois.o...@linaro.org]
> >> Sent: 01 Mar

[lng-odp] Maintaner change

2017-03-02 Thread Nicolas Morey-Chaisemartin

Hi everyone,

Just to let you know that this is my last week at Kalray.
Jérome Reybert (I think he's subscribing to this ML already) will be in charge 
of the ODP MPPA port.

If you have any questions on Kalray's port or need some feedback, please 
contact him from now on.

Regards

Nicolas

Re: [lng-odp] Generic handle in ODP

2017-03-02 Thread Verma, Shally

Humm. I see that a valid point. Yes I agree this proposal will add limitations 
on implementations and app.

Thanks everyone for your time.

From: Francois Ozog [mailto:francois.o...@linaro.org]
Sent: 02 March 2017 14:44
To: Verma, Shally 
Cc: Maxim Uvarov ; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Generic handle in ODP

Hi Shally,

I think Bill stated an important aspect. Due to the abstract nature of 
odp_packet_t and odp_buffer_t that can represent VERY different things 
depending on the underlying hardware, we want a strongly typed ODP.

So regardless of advantages of a common piece of code, your proposal 
contradicts this strong typed objective.

And if I look at it from a performance perspective, where the specialized 
function would just do the work, may be even inlined, your proposal would need 
type checks and other "safety" checks to perform the task.

Cordially,

FF



On 2 March 2017 at 08:30, Verma, Shally 
mailto:shally.ve...@cavium.com>> wrote:
Please see my response inline.

-Original Message-
From: lng-odp 
[mailto:lng-odp-boun...@lists.linaro.org]
 On Behalf Of Maxim Uvarov
Sent: 01 March 2017 18:38
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Generic handle in ODP

btw,

if you need to get pool you can use functions:

odp_pool_t odp_packet_pool(odp_packet_t pkt); odp_pool_t 
odp_buffer_pool(odp_buffer_t buf);

If you know event type and pool then you should be able do all you need.

Maxim.

On 03/01/17 15:47, Bill Fischofer wrote:
> ODP handles are by design abstract types that may have very different
> internal representations between different ODP implementations. When
> asking for a generic handle type the question is which types would you
> expect that to encompass?
>
> When we originally started defining the ODP type system we avoided
> having a generic odp_handle_t supertype specifically to avoid C's
> issues with weak typing. We wanted ODP to be strongly typed so that,
> for example, trying to pass an odp_queue_t to an API that expects an
> odp_packet_t would be flagged at compile time.
>
Shally ≫ So you mean doing ' handle=(odp_handle_t) pkt; ' is not desirable in 
example code snippet below.
It maintains strong typing at API level, but letting app to use it
int odp_xxx_process_data(odp_handle_t handle, );

main()
{
 odp_buffer_t buf=odp_buffer_alloc(buf_pool);
 odp_packet_t pkt=odp_packet_alloc(pkt_pool);

odp_handle_t handle;

 //process pkt
 handle=(odp_handle_t) pkt; // is this allowed?
 odp_xxx_process_data(handle,...);

 //process buffer
 handle=(odp_handle_t)buf; // is this allowed?
 odp_xx_process_buf(handle,...)

}
> As noted in this thread odp_event_t is a generic type that is used to
> represent entities that can be transmitted through queues and ODP
> provides type conversion APIs to and from this container type to the
> specific types (buffer, packet, timeout, crypto completions) that are
> able to be carried by an event. The intent is that as different event
> types are added they will similarly be added to this container along
> with converter APIs. But trying to fit all types into this model seems
> unnecessary. If you have a use case for wanting to treat some other
> type as an event we'd be interested in hearing that.
>
Shally≫ Event module carry a different purpose in system. They are raised as an 
outcome of an actions initiated on different modules (and thus carry need to 
have convertor APIs). However I didn’t had same purpose and would not like to 
use or extend event for same. Mine was simple use case to initiate some common 
action on different kinds of data and avoiding code duplicity.

Thanks
Shally

> On Wed, Mar 1, 2017 at 5:56 AM, Verma, Shally
> mailto:shally.ve...@cavium.com>>
> wrote:
>
>> Francois
>>
>> It is base assumption that an ODP Interface/implementation supporting
>> generic handle concept takes due care and record keeping to find out
>> proper type casting and keeping pool info is one such of them.
>>
>> Petri
>> memcpy() is just an example to explain use case.
>>
>> packet APIs are good for interface which always and only process data
>> of type odp_packet_t however  if anyone would want to extend same API
>> to support plain buffer type memory as well (thus avoiding
>> packet_copy_to/from_mem()), then generic handle concept may be helpful.
>>
>>
>> Though it does not come as a MUST requirement but thinking if
>> flexibility of having generic handle in ODP helps in flexible
>> implementation where ever it is desirable / needed (of course with due care).
>>
>> Thanks
>> Shally
>>
>>
>> From: Francois Ozog 
>> [mailto:francois.o...@linaro.org]
>> Sent: 01 March 2017 16:22
>> To: Verma, Shally mailto:shally.ve...@cavium.com>>
>> Cc: Savolainen, Petri (Nokia - FI/Espoo)
>> http://labs.com>>; 
>> lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] Generic handle in ODP
>>
>> I se

[lng-odp] Fwd: Re: [PATCH 2/5] test: generator: send UDP packets in bursts

2017-03-02 Thread Bogdan Pricope

CC Linaro.



 Forwarded Message 
Subject:Re: [lng-odp] [PATCH 2/5] test: generator: send UDP packets in 
bursts
Date:   Thu, 2 Mar 2017 13:29:30 +0200
From:   Bogdan Pricope 
Reply-To:   bogdan.pric...@linaro.org
Organization:   Linaro
To: Yi He 



My comments, inline.


On 03/01/2017 08:59 AM, Yi He wrote:
>
>
> On 13 February 2017 at 22:14, Bogdan Pricope  > wrote:
>
> Signed-off-by: Bogdan Pricope  >
> ---
>  example/generator/odp_generator.c | 77 
> +++
>  1 file changed, 53 insertions(+), 24 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index d1e3ecc..158bddf 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -26,6 +26,7 @@
>  #define POOL_NUM_PKT   2048  /* Number of packets in packet pool 
> */
>  #define POOL_PKT_LEN   1856  /* Max packet length */
>  #define DEFAULT_PKT_INTERVAL   1000  /* Interval between each packet */
> +#define MAX_UDP_TX_BURST   32
>
>  #define APPL_MODE_UDP0 /**< UDP mode */
>  #define APPL_MODE_PING   1 /**< ping mode */
> @@ -57,6 +58,8 @@ typedef struct {
> int timeout;/**< wait time */
> int interval;   /**< wait interval ms between sending
>  each packet */
> +   int udp_tx_burst;   /**< number of udp packets to send with 
> one
> + API call */
>  } appl_args_t;
>
>  /**
> @@ -432,11 +435,13 @@ static odp_pktio_t create_pktio(const char *dev, 
> odp_pool_t pool)
>  static int gen_send_thread(void *arg)
>  {
> int thr;
> -   int ret;
> +   int ret, i;
> odp_pktio_t pktio;
> thread_args_t *thr_args;
> odp_pktout_queue_t pktout;
> -   odp_packet_t pkt;
> +   odp_packet_t pkt_array[MAX_UDP_TX_BURST];
> +   int pkt_array_size;
> +   int burst_start, burst_size;
> odp_packet_t pkt_ref = ODP_PACKET_INVALID;
>
> thr = odp_thread_id();
> @@ -454,11 +459,13 @@ static int gen_send_thread(void *arg)
> return -1;
> }
>
> -   if (args->appl.mode == APPL_MODE_UDP)
> +   if (args->appl.mode == APPL_MODE_UDP) {
> pkt_ref = setup_udp_pkt_ref(thr_args->pool);
> -   else if (args->appl.mode == APPL_MODE_PING)
> +   pkt_array_size = args->appl.udp_tx_burst;
> +   } else if (args->appl.mode == APPL_MODE_PING) {
> pkt_ref = setup_icmp_pkt_ref(thr_args->pool);
> -   else {
> +   pkt_array_size = 1;
> +   } else {
> EXAMPLE_ERR("  [%02i] Error: invalid processing mode 
> %d\n",
> thr, args->appl.mode);
> return -1;
> @@ -479,32 +486,43 @@ static int gen_send_thread(void *arg)
> (unsigned int)args->appl.number)
> break;
>
> -   pkt = ODP_PACKET_INVALID;
> +   if (args->appl.mode == APPL_MODE_UDP) {
> +   for (i = 0; i < pkt_array_size; i++) {
> +   pkt_array[i] = 
> pack_udp_pkt(thr_args->pool, pkt_ref);
> +   if (!odp_packet_is_valid(pkt_array[i]))
> +   break;
> +   }
> +   if (i != pkt_array_size) {
> +   EXAMPLE_ERR("  [%2i] alloc_multi 
> failed\n", thr);
> +   break;
> +   }
> +   } else if (args->appl.mode == APPL_MODE_PING) {
> +   pkt_array[0] = pack_icmp_pkt(thr_args->pool, 
> pkt_ref);
> +   if (!odp_packet_is_valid(pkt_array[0])) {
> +   EXAMPLE_ERR("  [%2i] alloc_single 
> failed\n", thr);
> +   break;
> +   }
> +   } else
> +   break;
>
> -   if (args->appl.mode == APPL_MODE_UDP)
> -   pkt = pack_udp_pkt(thr_args->pool, pkt_ref);
> -   else if (args->appl.mode == APPL_MODE_PING)
> -   pkt = pack_icmp_pkt(thr_args->pool, pkt_ref);
>
> -   if (pkt == ODP_PACKET_INVALID) {
> -   /* Thread gives up as soon as it sees the pool 
> empty.
> -* Depending on pool size and transmit latency, 
> it may
> -* be norm

Re: [lng-odp] [PATCH 1/5] test: generator: compose sending packets from reference packet plus differences

2017-03-02 Thread Bogdan Pricope

My comments, inline.


On 03/01/2017 08:59 AM, Yi He wrote:
> Comments on 1/5 and 2/5, other patches in this series look OK to me.
>
> On 13 February 2017 at 20:49, Bogdan Pricope  > wrote:
>
> Signed-off-by: Bogdan Pricope  >
> ---
>  example/generator/odp_generator.c | 131 
> +-
>  1 file changed, 114 insertions(+), 17 deletions(-)
>
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index 8062d87..d1e3ecc 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -170,21 +170,20 @@ static int scan_ip(char *buf, unsigned int *paddr)
>  }
>
>  /**
> - * set up an udp packet
> + * set up an udp packet reference
>   *
>   * @param pool Buffer pool to create packet in
>   *
>   * @return Handle of created packet
>   * @retval ODP_PACKET_INVALID  Packet could not be created
>   */
> -static odp_packet_t pack_udp_pkt(odp_pool_t pool)
> +static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
>  {
> odp_packet_t pkt;
> char *buf;
> odph_ethhdr_t *eth;
> odph_ipv4hdr_t *ip;
> odph_udphdr_t *udp;
> -   unsigned short seq;
>
> pkt = odp_packet_alloc(pool, args->appl.payload + ODPH_UDPHDR_LEN 
> +
>ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
> @@ -200,8 +199,10 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
> memcpy((char *)eth->src.addr, args->appl.srcmac.addr, 
> ODPH_ETHADDR_LEN);
> memcpy((char *)eth->dst.addr, args->appl.dstmac.addr, 
> ODPH_ETHADDR_LEN);
> eth->type = odp_cpu_to_be_16(ODPH_ETHTYPE_IPV4);
> +
> /* ip */
> odp_packet_l3_offset_set(pkt, ODPH_ETHHDR_LEN);
> +   odp_packet_has_ipv4_set(pkt, 1);
> ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
> ip->dst_addr = odp_cpu_to_be_32(args->appl.dstip);
> ip->src_addr = odp_cpu_to_be_32(args->appl.srcip);
> @@ -209,12 +210,13 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
> ip->tot_len = odp_cpu_to_be_16(args->appl.payload + 
> ODPH_UDPHDR_LEN +
>ODPH_IPV4HDR_LEN);
> ip->proto = ODPH_IPPROTO_UDP;
> -   seq = odp_atomic_fetch_add_u64(&counters.seq, 1) % 0x;
> -   ip->id = odp_cpu_to_be_16(seq);
> +   ip->id = 0;
> +   ip->ttl = 64;
> ip->chksum = 0;
> -   odph_ipv4_csum_update(pkt);
> +
> /* udp */
> odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> +   odp_packet_has_udp_set(pkt, 1);
> udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
> udp->src_port = 0;
> udp->dst_port = 0;
> @@ -226,27 +228,60 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
>  }
>
>  /**
> - * Set up an icmp packet
> + * set up an udp packet
> + *
> + * @param pool Buffer pool to create packet in
> + * @param pkt_ref Reference UDP packet
> + *
> + * @return Handle of created packet
> + * @retval ODP_PACKET_INVALID  Packet could not be created
> + */
> +static odp_packet_t pack_udp_pkt(odp_pool_t pool, odp_packet_t pkt_ref)
> +{
> +   odp_packet_t pkt;
> +   char *buf;
> +   odph_ipv4hdr_t *ip;
> +   unsigned short seq;
> +
> +   pkt = odp_packet_alloc(pool, args->appl.payload + ODPH_UDPHDR_LEN 
> +
> +  ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
> +
> +   if (pkt == ODP_PACKET_INVALID)
> +   return pkt;
> +
> +   buf = (char *)odp_packet_data(pkt);
> +   odp_memcpy(buf, odp_packet_data(pkt_ref),
> +   args->appl.payload + ODPH_UDPHDR_LEN +
> +   ODPH_IPV4HDR_LEN + ODPH_ETHHDR_LEN);
> +
> +   /*Update IP ID and checksum*/
> +   ip = (odph_ipv4hdr_t *)(buf + ODPH_ETHHDR_LEN);
> +   seq = odp_atomic_fetch_add_u64(&counters.seq, 1) % 0x;
> +   ip->id = odp_cpu_to_be_16(seq);
> +   ip->chksum = odph_chksum(ip, ODPH_IPV4HDR_LEN);
> +
> +   return pkt;
> +}
> +
> +/**
> + * Set up an icmp packet reference
>   *
>   * @param pool Buffer pool to create packet in
>   *
>   * @return Handle of created packet
>   * @retval ODP_PACKET_INVALID  Packet could not be created
>   */
> -static odp_packet_t pack_icmp_pkt(odp_pool_t pool)
> +static odp_packet_t setup_icmp_pkt_ref(odp_pool_t pool)
>  {
> odp_packet_t pkt;
> char *buf;
> odph_ethhdr_t *eth;
> odph_ipv4hdr_t *ip;
> odph_icmphdr_t *icmp;
> -

[lng-odp] Fwd: [PATCHv3 1/1] test: generator: Updated global statistics calculation to provide useful/easy-to-parse information

2017-03-02 Thread Bogdan Pricope

Ping.


 Forwarded Message 
Subject:[PATCHv3 1/1] test: generator: Updated global statistics 
calculation to provide useful/easy-to-parse information
Date:   Tue, 7 Feb 2017 14:10:59 +0200
From:   Bogdan Pricope 
To: lng-odp@lists.linaro.org
CC: Bogdan Pricope 



Signed-off-by: Bogdan Pricope 
---
 example/generator/odp_generator.c | 57 ---
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 6ac8f2d..b1f549f 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -565,7 +565,10 @@ static int gen_recv_thread(void *arg)
 static void print_global_stats(int num_workers)
 {
odp_time_t cur, wait, next;
-   uint64_t pkts, pkts_prev = 0, pps, maximum_pps = 0;
+   uint64_t pkts_snd = 0, pkts_snd_prev = 0;
+   uint64_t pps_snd = 0, maximum_pps_snd = 0;
+   uint64_t pkts_rcv = 0, pkts_rcv_prev = 0;
+   uint64_t pps_rcv = 0, maximum_pps_rcv = 0;
int verbose_interval = 20;
odp_thrmask_t thrd_mask;
 
@@ -586,30 +589,40 @@ static void print_global_stats(int num_workers)
continue;
 
next = odp_time_sum(cur, wait);
-
-   if (args->appl.mode == APPL_MODE_RCV) {
-   pkts = odp_atomic_load_u64(&counters.udp);
-   printf(" total receive(UDP: %" PRIu64 ")\n", pkts);
+   switch (args->appl.mode) {
+   case APPL_MODE_RCV:
+   pkts_rcv = odp_atomic_load_u64(&counters.ip);
+   break;
+   case APPL_MODE_PING:
+   pkts_snd = odp_atomic_load_u64(&counters.seq);
+   pkts_rcv = odp_atomic_load_u64(&counters.icmp);
+   break;
+   case APPL_MODE_UDP:
+   pkts_snd = odp_atomic_load_u64(&counters.seq);
+   break;
+   default:
continue;
}
 
-   if (args->appl.mode == APPL_MODE_PING) {
-   pkts = odp_atomic_load_u64(&counters.icmp);
-   printf(" total receive(ICMP: %" PRIu64 ")\n", pkts);
-   }
-
-   pkts = odp_atomic_load_u64(&counters.seq);
-   printf(" total sent: %" PRIu64 ", drops: %" PRIu64 "\n", pkts,
-  odp_atomic_load_u64(&counters.tx_drops));
-
-   if (args->appl.mode == APPL_MODE_UDP) {
-   pps = (pkts - pkts_prev) / verbose_interval;
-   if (pps > maximum_pps)
-   maximum_pps = pps;
-   printf(" %" PRIu64 " pps, %" PRIu64 " max pps\n",
-  pps, maximum_pps);
-   pkts_prev = pkts;
-   }
+   pps_snd = (pkts_snd - pkts_snd_prev) / verbose_interval;
+   pkts_snd_prev = pkts_snd;
+   if (pps_snd > maximum_pps_snd)
+   maximum_pps_snd = pps_snd;
+
+   pps_rcv = (pkts_rcv - pkts_rcv_prev) / verbose_interval;
+   pkts_rcv_prev = pkts_rcv;
+   if (pps_rcv > maximum_pps_rcv)
+   maximum_pps_rcv = pps_rcv;
+
+   printf("sent: %" PRIu64 ", drops: %" PRIu64 ", "
+   "send rate: %" PRIu64 " pps, "
+   "max send rate: %" PRIu64 " pps, "
+   "rcv: %" PRIu64 ", "
+   "recv rate: %" PRIu64 " pps, "
+   "max recv rate: %" PRIu64 " pps\n",
+   pkts_snd, odp_atomic_load_u64(&counters.tx_drops),
+   pps_snd, maximum_pps_snd,
+   pkts_rcv, pps_rcv, maximum_pps_rcv);
}
 }
 
-- 
1.9.1

Re: [lng-odp] Generic handle in ODP

2017-03-02 Thread Francois Ozog

Hi Shally,

I think Bill stated an important aspect. Due to the abstract nature of
odp_packet_t and odp_buffer_t that can represent VERY different things
depending on the underlying hardware, we want a strongly typed ODP.

So regardless of advantages of a common piece of code, your proposal
contradicts this strong typed objective.

And if I look at it from a performance perspective, where the specialized
function would just do the work, may be even inlined, your proposal would
need type checks and other "safety" checks to perform the task.

Cordially,

FF



On 2 March 2017 at 08:30, Verma, Shally  wrote:

> Please see my response inline.
>
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Maxim Uvarov
> Sent: 01 March 2017 18:38
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Generic handle in ODP
>
> btw,
>
> if you need to get pool you can use functions:
>
> odp_pool_t odp_packet_pool(odp_packet_t pkt); odp_pool_t
> odp_buffer_pool(odp_buffer_t buf);
>
> If you know event type and pool then you should be able do all you need.
>
> Maxim.
>
> On 03/01/17 15:47, Bill Fischofer wrote:
> > ODP handles are by design abstract types that may have very different
> > internal representations between different ODP implementations. When
> > asking for a generic handle type the question is which types would you
> > expect that to encompass?
> >
> > When we originally started defining the ODP type system we avoided
> > having a generic odp_handle_t supertype specifically to avoid C's
> > issues with weak typing. We wanted ODP to be strongly typed so that,
> > for example, trying to pass an odp_queue_t to an API that expects an
> > odp_packet_t would be flagged at compile time.
> >
> Shally ≫ So you mean doing ' handle=(odp_handle_t) pkt; ' is not desirable
> in example code snippet below.
> It maintains strong typing at API level, but letting app to use it
> int odp_xxx_process_data(odp_handle_t handle, );
>
> main()
> {
>  odp_buffer_t buf=odp_buffer_alloc(buf_pool);
>  odp_packet_t pkt=odp_packet_alloc(pkt_pool);
>
> odp_handle_t handle;
>
>  //process pkt
>  handle=(odp_handle_t) pkt; // is this allowed?
>  odp_xxx_process_data(handle,...);
>
>  //process buffer
>  handle=(odp_handle_t)buf; // is this allowed?
>  odp_xx_process_buf(handle,...)
>
> }
> > As noted in this thread odp_event_t is a generic type that is used to
> > represent entities that can be transmitted through queues and ODP
> > provides type conversion APIs to and from this container type to the
> > specific types (buffer, packet, timeout, crypto completions) that are
> > able to be carried by an event. The intent is that as different event
> > types are added they will similarly be added to this container along
> > with converter APIs. But trying to fit all types into this model seems
> > unnecessary. If you have a use case for wanting to treat some other
> > type as an event we'd be interested in hearing that.
> >
> Shally≫ Event module carry a different purpose in system. They are raised
> as an outcome of an actions initiated on different modules (and thus carry
> need to have convertor APIs). However I didn’t had same purpose and would
> not like to use or extend event for same. Mine was simple use case to
> initiate some common action on different kinds of data and avoiding code
> duplicity.
>
> Thanks
> Shally
>
> > On Wed, Mar 1, 2017 at 5:56 AM, Verma, Shally
> > 
> > wrote:
> >
> >> Francois
> >>
> >> It is base assumption that an ODP Interface/implementation supporting
> >> generic handle concept takes due care and record keeping to find out
> >> proper type casting and keeping pool info is one such of them.
> >>
> >> Petri
> >> memcpy() is just an example to explain use case.
> >>
> >> packet APIs are good for interface which always and only process data
> >> of type odp_packet_t however  if anyone would want to extend same API
> >> to support plain buffer type memory as well (thus avoiding
> >> packet_copy_to/from_mem()), then generic handle concept may be helpful.
> >>
> >>
> >> Though it does not come as a MUST requirement but thinking if
> >> flexibility of having generic handle in ODP helps in flexible
> >> implementation where ever it is desirable / needed (of course with due
> care).
> >>
> >> Thanks
> >> Shally
> >>
> >>
> >> From: Francois Ozog [mailto:francois.o...@linaro.org]
> >> Sent: 01 March 2017 16:22
> >> To: Verma, Shally 
> >> Cc: Savolainen, Petri (Nokia - FI/Espoo)
> >> ; lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] Generic handle in ODP
> >>
> >> I see the point but still, I don't feel comfortable with the approach
> >> as we don't know if we have access to the pool originating the handle
> >> when you want to do the copy.
> >>
> >> It is good to avoid code duplication but in that particular case, it
> >> looks opening dangerous directions. (a gut feel for the moment, not a
> >> documented statement).
> >>
> >> FF
> >>
> >> On 1 March 2017 at

[lng-odp] [Bug 2812] helper/test/process fails on a single core system

[lng-odp] [Bug 2407] test odp_l2fwd_run.sh contains todo items

[lng-odp] [Bug 2411] linux-generic/odp_schedule_sp.c contains todo items

[lng-odp] [Bug 2826] CID 174664: Unchecked return in pool.c

[lng-odp] [Linaro/odp] 88dbb0: linux-generic: pool: add odp_pool_capability() rc ...

[lng-odp] [Bug 2889] Unused helper extension code does not build, and is not tested in CI

Re: [lng-odp] [API-NEXT PATCH 0/4] Add sha-1 and sha-512

[lng-odp] [Linaro/odp] 20dd99: api: packet: add support for packet references

Re: [lng-odp] [PATCH 1/3] helper: linux: add common linux helper file

[lng-odp] [Linaro/odp] 39f85b: helper: linux: add common linux helper file

Re: [lng-odp] Maintaner change

Re: [lng-odp] Generic handle in ODP

[lng-odp] Maintaner change

Re: [lng-odp] Generic handle in ODP

[lng-odp] Fwd: Re: [PATCH 2/5] test: generator: send UDP packets in bursts

Re: [lng-odp] [PATCH 1/5] test: generator: compose sending packets from reference packet plus differences

[lng-odp] Fwd: [PATCHv3 1/1] test: generator: Updated global statistics calculation to provide useful/easy-to-parse information

Re: [lng-odp] Generic handle in ODP

18 matches

Site Navigation

Mail list logo

Footer information