date:20170203

[lng-odp] [Bug 2873] New: code coverage odp_timer_wheel.c

2017-02-03 Thread bugzilla-daemon

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

Bug ID: 2873
   Summary: code coverage odp_timer_wheel.c
   Product: OpenDataPlane - linux- generic reference
   Version: v1.13.0.0
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: Traffic Manager
  Assignee: lng-odp@lists.linaro.org
  Reporter: mike.hol...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

https://codecov.io/gh/Linaro/odp/src/342ee768598add3e595da5dbce1c4613895616cb/platform/linux-generic/odp_timer_wheel.c

timer_blk_list_search not called

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

Re: [lng-odp] [API-NEXT PATCH] doc: userguide: add section on application portability

2017-02-03 Thread Mike Holmes

This builds and reads well to me, I think that when the ABI an other
issues on what helpers are gets ironed out, we will need to have some
words about what the helpers are in relation to the ODP API. Helpers
are part of the interface we present in outside world, our examples
and tests use them.

I think in a cloud case they are quite important and for embedded you
are free to do what you like, perhaps the meat of that discussion
lives in the helpers documentation and is only mentioned here.

On 30 January 2017 at 15:38, Bill Fischofer  wrote:
> Add a section to the ODP User Guide discussing application portability
> considerations and the use of source and binary portability options
> provided by ODP.
>
> Signed-off-by: Bill Fischofer 

Reviewed-by: Mike Holmes 

> ---
>  doc/users-guide/users-guide.adoc | 120 
> +++
>  1 file changed, 120 insertions(+)
>
> diff --git a/doc/users-guide/users-guide.adoc 
> b/doc/users-guide/users-guide.adoc
> index 41c57d1..ead8da5 100755
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -589,6 +589,126 @@ lookup. The lookup function is particularly useful to 
> allow an ODP application
>  that is divided into multiple processes to obtain the handle for the common
>  resource.
>
> +== Application Portability Considerations
> +ODP is designed to support the creation of portable data plane applications
> +that can easily be run on multiple target platforms while at the same time
> +fully exploit hardware acceleration capabilities native to whatever platform
> +it is running on. This section discusses tradeoffs that application writers
> +should consider when using ODP.
> +
> +First, it should be noted that portability is not an absolute good nor is it 
> a
> +single-valued attribute (application is portable or is not portable). While
> +any application can be ported from one platform to another the real question
> +is: _at what cost?_ Costs can be measured in two dimensions: The level of
> +effort needed to port, and the resulting performance differences seen due to
> +the port. Ideally an application should be portable between platforms with
> +minimal effort and equally minimal performance impact. While ODP is designed
> +to support this ideal, each application must assess what its goals are in 
> this
> +area and how best to use ODP to achieve these goals.
> +
> +=== Portability and Coexistence
> +Because ODP offers a programming _framework_ rather than a programming
> +_environment_, it is designed to be able to work alongside APIs offered by
> +other frameworks with minimual interference. Therefore when we speak of
> +portability in an ODP context, we of necessity speak of portability of those
> +portions of the application that make use of ODP APIs. If an application uses
> +non-ODP APIs then those must be taken into consideration as well when
> +assessing the portability of the entire application. For many applications, 
> it
> +suffices to isolate certain non-portable code to a few areas of the 
> application
> +with the result that the application is significantly more portable than it
> +would be without using ODP. Especially when dealing with existing 
> applications
> +that run in production environments, ODP may well be introduced in an
> +incremental manner with the result being that the application becomes more
> +portable only over time.
> +
> +=== Source vs. Binary Portability
> +ODP has been designed to support both source and binary portability. Source
> +portability is intrinsic to the ODP API specification itself. Any application
> +written to the ODP API specification will be source portable between any
> +conforming ODP implementation with at most a recompile. This is because ODP
> +APIs do not expose implementation details or internal structures that may 
> vary
> +from platform to platform.
> +
> +For platforms that share a common Instruction Set Architecture (ISA), ODP can
> +also offer binary portability via the specification of an Application Binary
> +Interface (ABI). This is especially useful in a Network Function
> +Virtualization (NFV) environment where a data plane application may be
> +developed and compiled on one platform for distribution and then deployed on
> +many different platforms by an NFV Orchestrator function.
> +
> +=== ODP Application Profiles
> +To assist in meeting these needs, ODP offers two distinct _application
> +profiles_ that are designed to characterize the needs of different types of
> +data plane applications: the _Embedded Profile_ and the _Cloud Profile_.
> +
> + Embedded Profile
> +The ODP Embedded Profile is designed to support applications that wish to
> +target a specific platform and achieve optimal performance on that platform
> +and where source code portability is sufficient. If such applications need to
> +support more than one platform then they simply need to be recompiled against
> +the ODP implementation for that platform.
> +
>

Re: [lng-odp] Fwd: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file

2017-02-03 Thread Mike Holmes

On 3 February 2017 at 12:11, Maxim Uvarov  wrote:
> Will it be ok that instead of reply to email thread that patch was
> merged, there will me automatic merge messages like bellow?
> Does somebody have objections?

This is assured to automatically give an indication to the list which
is good. The links it includes make it very easy to know more about
what has been accepted also a plus.
But it is nice to have a thread "closed" with a "merged" message,
however I dont mind this format

>
> Maxim.
>
>
>
>
>  Forwarded Message 
> Subject: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file
> Date: Fri, 03 Feb 2017 09:00:27 -0800
> From: GitHub 
> Reply-To: GitHub 
> To: maxim.uva...@linaro.org
>
>   Branch: refs/heads/master
>   Home:   https://github.com/Linaro/odp
>   Commit: 25ed19ceb50d77614644f6d4a28a0b23dbf1e94f
>
> https://github.com/Linaro/odp/commit/25ed19ceb50d77614644f6d4a28a0b23dbf1e94f
>   Author: Petri Savolainen 
>   Date:   2017-02-03 (Fri, 03 Feb 2017)
>
>   Changed paths:
> M configure.ac
> M example/Makefile.inc
> M helper/Makefile.am
> M helper/test/Makefile.am
> A include/odp/arch/arm32-linux/odp/api/abi/event.h
> A include/odp/arch/arm64-linux/odp/api/abi/event.h
> A include/odp/arch/default/api/abi/event.h
> A include/odp/arch/mips64-linux/odp/api/abi/event.h
> A include/odp/arch/power64-linux/odp/api/abi/event.h
> A include/odp/arch/x86_32-linux/odp/api/abi/event.h
> A include/odp/arch/x86_64-linux/odp/api/abi/event.h
> M platform/Makefile.inc
> M platform/linux-generic/Makefile.am
> M platform/linux-generic/include/odp/api/plat/event_types.h
> M platform/linux-generic/odp_event.c
> M test/Makefile.inc
> M test/linux-generic/Makefile.inc
>
>   Log Message:
>   ---
>   abi: event: added the first ABI spec file
>
> Used event API as the first example of an ABI spec file. Used
> the same default architecture file initially for all
> architectures. Default ABI files avoid multiple copies
> of the same definition.
>
> Signed-off-by: Petri Savolainen 
> Reviewed-and-tested-by: Bill Fischofer 
> Signed-off-by: Maxim Uvarov 
>
>
>   Commit: 4afed247a6ee3058aa6dc3e66ed0bd5acff9ce97
>
> https://github.com/Linaro/odp/commit/4afed247a6ee3058aa6dc3e66ed0bd5acff9ce97
>   Author: Petri Savolainen 
>   Date:   2017-02-03 (Fri, 03 Feb 2017)
>
>   Changed paths:
> A include/odp/arch/arm32-linux/odp/api/abi/buffer.h
> A include/odp/arch/arm64-linux/odp/api/abi/buffer.h
> A include/odp/arch/default/api/abi/buffer.h
> A include/odp/arch/mips64-linux/odp/api/abi/buffer.h
> A include/odp/arch/power64-linux/odp/api/abi/buffer.h
> A include/odp/arch/x86_32-linux/odp/api/abi/buffer.h
> A include/odp/arch/x86_64-linux/odp/api/abi/buffer.h
> M platform/Makefile.inc
> M platform/linux-generic/include/odp/api/plat/buffer_types.h
> M platform/linux-generic/odp_buffer.c
>
>   Log Message:
>   ---
>   abi: buffer: added initial definitions
>
> Initially, use the same default ABI file for all architectures.
> Default values match those defined in odp-linux implementation
> to minimize changes in this phase.
>
> Signed-off-by: Petri Savolainen 
> Reviewed-and-tested-by: Bill Fischofer 
> Signed-off-by: Maxim Uvarov 
>
>
>   Commit: 62108ed367a2718e0f0e2d7d8682b5c83d504670
>
> https://github.com/Linaro/odp/commit/62108ed367a2718e0f0e2d7d8682b5c83d504670
>   Author: Petri Savolainen 
>   Date:   2017-02-03 (Fri, 03 Feb 2017)
>
>   Changed paths:
> A include/odp/arch/arm32-linux/odp/api/abi/classification.h
> A include/odp/arch/arm64-linux/odp/api/abi/classification.h
> A include/odp/arch/default/api/abi/classification.h
> A include/odp/arch/mips64-linux/odp/api/abi/classification.h
> A include/odp/arch/power64-linux/odp/api/abi/classification.h
> A include/odp/arch/x86_32-linux/odp/api/abi/classification.h
> A include/odp/arch/x86_64-linux/odp/api/abi/classification.h
> M platform/Makefile.inc
> M platform/linux-generic/include/odp/api/classification.h
> M platform/linux-generic/include/odp/api/plat/classification_types.h
> M platform/linux-generic/include/odp_classification_datamodel.h
> M platform/linux-generic/odp_classification.c
>
>   Log Message:
>   ---
>   abi: classifier: added initial definitions
>
> Initially, use the same default ABI file for all architectures.
> Default values match those defined in odp-linux implementation
> to minimize changes in this phase. Removed unused type
> definitions, documentation of those need to be still removed
> for API spec.
>
> Signed-off-by: Petri Savolainen 
> Reviewed-and-tested-by: Bill Fischofer 
> Signed-off-by: Maxim Uvarov 
>
>
>   Commit: 0a62e1c5b92a5170aa807cc8803f42698b23f4c8
>
> https://github.com/Linaro/odp/commit/0a62e1c5b92a5170aa807cc8803f42698b23f4c8
>   Author: Petri Savolainen 
>   Date:   2017-02-03 (Fri, 03 Feb 2017)
>
>   Changed paths:
> A include

[lng-odp] Fwd: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file

2017-02-03 Thread Maxim Uvarov

Will it be ok that instead of reply to email thread that patch was
merged, there will me automatic merge messages like bellow?
Does somebody have objections?

Maxim.




 Forwarded Message 
Subject: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file
Date: Fri, 03 Feb 2017 09:00:27 -0800
From: GitHub 
Reply-To: GitHub 
To: maxim.uva...@linaro.org

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 25ed19ceb50d77614644f6d4a28a0b23dbf1e94f

https://github.com/Linaro/odp/commit/25ed19ceb50d77614644f6d4a28a0b23dbf1e94f
  Author: Petri Savolainen 
  Date:   2017-02-03 (Fri, 03 Feb 2017)

  Changed paths:
M configure.ac
M example/Makefile.inc
M helper/Makefile.am
M helper/test/Makefile.am
A include/odp/arch/arm32-linux/odp/api/abi/event.h
A include/odp/arch/arm64-linux/odp/api/abi/event.h
A include/odp/arch/default/api/abi/event.h
A include/odp/arch/mips64-linux/odp/api/abi/event.h
A include/odp/arch/power64-linux/odp/api/abi/event.h
A include/odp/arch/x86_32-linux/odp/api/abi/event.h
A include/odp/arch/x86_64-linux/odp/api/abi/event.h
M platform/Makefile.inc
M platform/linux-generic/Makefile.am
M platform/linux-generic/include/odp/api/plat/event_types.h
M platform/linux-generic/odp_event.c
M test/Makefile.inc
M test/linux-generic/Makefile.inc

  Log Message:
  ---
  abi: event: added the first ABI spec file

Used event API as the first example of an ABI spec file. Used
the same default architecture file initially for all
architectures. Default ABI files avoid multiple copies
of the same definition.

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


  Commit: 4afed247a6ee3058aa6dc3e66ed0bd5acff9ce97

https://github.com/Linaro/odp/commit/4afed247a6ee3058aa6dc3e66ed0bd5acff9ce97
  Author: Petri Savolainen 
  Date:   2017-02-03 (Fri, 03 Feb 2017)

  Changed paths:
A include/odp/arch/arm32-linux/odp/api/abi/buffer.h
A include/odp/arch/arm64-linux/odp/api/abi/buffer.h
A include/odp/arch/default/api/abi/buffer.h
A include/odp/arch/mips64-linux/odp/api/abi/buffer.h
A include/odp/arch/power64-linux/odp/api/abi/buffer.h
A include/odp/arch/x86_32-linux/odp/api/abi/buffer.h
A include/odp/arch/x86_64-linux/odp/api/abi/buffer.h
M platform/Makefile.inc
M platform/linux-generic/include/odp/api/plat/buffer_types.h
M platform/linux-generic/odp_buffer.c

  Log Message:
  ---
  abi: buffer: added initial definitions

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

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


  Commit: 62108ed367a2718e0f0e2d7d8682b5c83d504670

https://github.com/Linaro/odp/commit/62108ed367a2718e0f0e2d7d8682b5c83d504670
  Author: Petri Savolainen 
  Date:   2017-02-03 (Fri, 03 Feb 2017)

  Changed paths:
A include/odp/arch/arm32-linux/odp/api/abi/classification.h
A include/odp/arch/arm64-linux/odp/api/abi/classification.h
A include/odp/arch/default/api/abi/classification.h
A include/odp/arch/mips64-linux/odp/api/abi/classification.h
A include/odp/arch/power64-linux/odp/api/abi/classification.h
A include/odp/arch/x86_32-linux/odp/api/abi/classification.h
A include/odp/arch/x86_64-linux/odp/api/abi/classification.h
M platform/Makefile.inc
M platform/linux-generic/include/odp/api/classification.h
M platform/linux-generic/include/odp/api/plat/classification_types.h
M platform/linux-generic/include/odp_classification_datamodel.h
M platform/linux-generic/odp_classification.c

  Log Message:
  ---
  abi: classifier: added initial definitions

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase. Removed unused type
definitions, documentation of those need to be still removed
for API spec.

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


  Commit: 0a62e1c5b92a5170aa807cc8803f42698b23f4c8

https://github.com/Linaro/odp/commit/0a62e1c5b92a5170aa807cc8803f42698b23f4c8
  Author: Petri Savolainen 
  Date:   2017-02-03 (Fri, 03 Feb 2017)

  Changed paths:
A include/odp/arch/arm32-linux/odp/api/abi/crypto.h
A include/odp/arch/arm64-linux/odp/api/abi/crypto.h
A include/odp/arch/default/api/abi/crypto.h
A include/odp/arch/mips64-linux/odp/api/abi/crypto.h
A include/odp/arch/power64-linux/odp/api/abi/crypto.h
A include/odp/arch/x86_32-linux/odp/api/abi/crypto.h
A include/odp/arch/x86_64-linux/odp/api/abi/crypto.h
M platform/Makefile.inc
M platform/linux-generic/include/odp/api/plat/crypto_types.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  abi: crypto: a

[lng-odp] [Bug 2872] New: odp_pktio_ordered_run.sh: line 34: [: : integer expression expected

2017-02-03 Thread bugzilla-daemon

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

Bug ID: 2872
   Summary: odp_pktio_ordered_run.sh: line 34: [: : integer
expression expected
   Product: OpenDataPlane - linux- generic reference
   Version: v1.13.0.0
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: Packet IO
  Assignee: maxim.uva...@linaro.org
  Reporter: maxim.uva...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

../../../platform/linux-generic/pktio/socket_mmap.c:78:mmap_pkt_socket():socket(SOCK_RAW):
Operation not permitted

../../../platform/linux-generic/pktio/socket.c:512:sock_setup_pkt():socket():
Operation not permitted

../../../platform/linux-generic/odp_packet_io.c:224:setup_pktio_entry():Unable
to init any I/O type.

../../../../test/common_plat/performance/odp_pktio_ordered.c:601:create_pktio():Error:
failed to open pcap:in=:loops=1

../../../../test/common_plat/performance/odp_pktio_ordered_run.sh: line 34: [:
: integer expression expected

https://travis-ci.org/muvarov/odp/jobs/198068626

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

Re: [lng-odp] [PATCH v4 0/8] First ABI files

2017-02-03 Thread Maxim Uvarov

Merged,
Maxim.

On 02/03/17 10:46, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> Ping. I have next patch set ready (for packet accessor function inline), just 
> waiting for this to be merged first.
> 
> -Petri
> 
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Wednesday, February 01, 2017 3:11 AM
>> To: Petri Savolainen 
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] [PATCH v4 0/8] First ABI files
>>
>> Thanks, Petri. This now seems fully bisectable. For this series:
>>
>> Reviewed-and-tested-by: Bill Fischofer

Re: [lng-odp] rstp support on odp

2017-02-03 Thread Bill Fischofer

On Thu, Feb 2, 2017 at 1:00 PM, Maxim Uvarov  wrote:
> yes, the point it that classier or pktio should pass BPDUs and drop other
> packets without cpu load if that possible...
>

The ODP APIs are designed to be used by SW either to process packets
or to configure the system for autonomous packet processing. To the
extent that the ODP app is acting as a switch that needs to see and
process BDPUs, they are just another type of packet. To the extent
that the ODP app is acting at a higher level and simply needs to be
informed of link state configuration, then we may need additional
pktio APIs to manage these state changes and/or notifications
resulting from them.

Note that in the former case there will always be CPU load because ODP
APIs run on CPUs. When ODP APIs are used to configure various types of
autonomous processing (e.g., classification) then it is up to the ODP
implementation whether that processing is done in SW on visible or
invisible CPUs or some other HW path that doesn't involve any CPUs.

> On 2 February 2017 at 20:01, Brian Brooks  wrote:
>>
>> On Wed, Feb 1, 2017 at 9:41 AM, Bill Fischofer
>>  wrote:
>> > On Wed, Feb 1, 2017 at 9:29 AM, Maxim Uvarov 
>> > wrote:
>> >> I have some theoretical question to think...
>> >>
>> >>
>> >> rstp on hardware switches supported with moving port into disabled mode
>> >> where it do not accept packets but only stp packets can pass-thought to
>> >> rstp daemon app which decided which where path is shorter and
>> >> disables/enables certain ports.
>> >
>> > If the port is disabled the odp_pktio_t will never see any pkts until
>> > it is re-enabled. The question is does this appear simply as a link
>> > down indication or is there extra information that says it's down
>> > because it's in a special mode. Currently we treat link state as a
>> > boolean but it's clear that we'll want to extend that to en enum to
>> > support more than two possible states that have different behaviors
>> > associated with them.
>> >
>> >>
>> >> How that app can be done with odp?
>> >
>> > Currently ODP provides APIs for examining link state but not for
>> > manipulating it. That's one of the topics for the "production grade
>> > ODP" discussions.
>> >
>> >>
>> >> I think it might be classifier configuration or pktio settings.
>> >> It might be worth to add additional states to pktio itself.
>> >
>> > These sort of things are properly done in the pktio rather than the
>> > classifier, as they relate to the ability to see packets rather than
>> > how to process them.
>>
>> One view of link state is a combination of MAC and PHY and (optional)
>> pluggable transceiver link state. Some of these parts can be off-chip
>> accessible via e.g. a 2 wire interface. Even if the link state is
>> reported correctly by the off-chip device, there may be incorrect
>> configuration or bus corruption on this slower control path!
>>
>> For STP and friends, there is a difference between link state and port
>> state. The link must be up to receive the BPDUs. But, the port state
>> is one of forwarding, discarding, learning, ...  In some switch
>> pipelines the ingress ACL path can be set up to match against BPDUs
>> and send packet to the CPU (punt slow path)... and then drop every
>> thing else received from the port.  The control plane manages the
>> protocol state machine and configures the hardware accordingly.
>>
>> Mapping this to ODP, I think the Packet IO link state remains
>> untouched (if we think link state is something like link state as
>> described above).  Since what we call Classifier is kind of like the
>> Match portion of Match+Action, I think all traffic received on a STP
>> blocked port must be put on some queue to be received by the CPUs
>> where they are dropped (unless a BPDU).  To do better, there might
>> need to be a model that describes the separation between the data
>> plane and control plane; maybe scheduler is the interface between the
>> two.
>>
>> >>
>> >> Thanks,
>> >> Maxim.
>
>

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Friday, February 03, 2017 3:37 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)  labs.com>
> Cc: LNG ODP Mailman List 
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 3 February 2017 at 14:11, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> >> Sent: Friday, February 03, 2017 2:29 PM
> >> To: Petri Savolainen 
> >> Cc: LNG ODP Mailman List 
> >> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to
> >> linux helpers
> >>
> >> On 3 February 2017 at 12:23, Petri Savolainen
> >>  wrote:
> >> > There's no platform specific helpers. Helpers may depend on
> >> > Linux and make it easier to do common series of Linux system
> >> > calls. These kind of helpers are grouped into helper/linux
> >> > directory.
> >>
> >> This is getting really confusing to me! Haven't we defined a
> >> "platform" as being a couple {OS, HW}? That is any change in this
> >> couple makes a new platform...
> >> If we hold to this definition, then linux-helpers becomes platform
> >> helpers...
> >> Now, my humble opinion is that no-one is using these linux-only
> >> helpers and no one ever will unless to enforce their usage by example
> >> that people could copy/paste: why would a programmer want to replace a
> >> well known linux system call by an ODP helper call? to save a for
> >> loop?.
> >> We are hitting the same usual problem of lack of proper definition for
> >> things, but in this special case, my proposal is called "deletion".
> >> :-)
> >>
> >> Christophe
> >
> > This is needed by OFP, for example.
> >
> > The current ODP master (after v1.13) moved things backwards as linux
> helper (which create e.g. pthreads and call odp_local_init / _term() for
> those) was renamed as "linux-generic helper". That would need OFP to
> expose "helper/linux-generic/..." in its Makefiles, which is both ugly and
> wrong (in the sense that helper code is part application code, not
> implementation code).
> 
> I am really getting confused here...
> There are two sorts of things today in the helper (regarding ODPthread
> creation):
> 1)odph_odpthreads_create() familly of functions abstracts the ODP
> thread creation, i.e. will create OPD threads. Whether that is a
> pthread or linux process or anything else under the hood is hidden: It
> just creates a set of ODPthreads. (for those implementation which
> (should) supports different implemenation, a helper flag can be used
> to select what should be done)

Needed by (synthetic) validation test application that need to run on any 
environment to offer API verification.

> 
> 2)linux specific functions creating pthreads or processes. If the
> application uses those, the application is definitively binding itself
> to linux and is then using these functions instead of calling
> pthread_create() or fork() directely.

Most real world applications choose first an operating system and then the 
thread model within that OS. Linux is the largest data plane OS (ecosystem), so 
it's natural for ODP to offer helpers for that. Most real/production grade 
applications would not need OS abstraction layer (option 1) above) from ODP.


> 
> From Mikes comment, I understand that OFP is using functions from the
> second set. Do they have any reason for doing that? Possibly, if they
> share data allocated after the thread creatiion, not using
> odp_shm_reserve().
> If an application really binds itseft to linux, I don't see anything
> wrong if it is reflected in its Makefile ("helper/linux-generic/...").

... and
helper/odp-dpdk/
helper/odp-thunderx
helper/nxp
...

... gets ugly. A Linux application using ODP depends only on Linux and ODP 
APIs, not the ODP platform under ODP API.



> If OFP does not require any specific type of ODP thread (they just
> want concurrency but don't care how this is achieved) , then they
> should be using function from the first set.

OFP slow path is Linux, not "abstract OS" (as of today at least).

> 
> The Second set of function is not of much value in my eyes: They do
> not provide any kind of abstraction, but just some kind of shortcut
> avoiding a few things round fork() or pthread_create().

May be other common Linux data plane application patters will follow. Linux is 
not there only for threads. Debugging, file IO, logging, ...


> When I see the confusion that they generate, compared to the little
> gain they provide (avoiding to write about 100lines of code), I still
> feel those function should be part of the application. Most programmer
> knows much more about pthread_create() and fork(), and the price
> rewritting the little piece of code will probably been seen as lower
> than learning the helper API.
> 
> The role of the helpers becomes then clearer: Abstracting thing that
> can be done differentely

Re: [lng-odp] [PATCH] [RFC] API:update odp_schedle_multi to return events from multiple queues.

2017-02-03 Thread Ola Liljedahl

Do we have any performance comparison between using this new API
compared to using the existing API and the SW behind
odp_schedule_multi() sorts the events (if necessary) and only returns
events for one queue at a time (keeping the others as prescheduled
events)?

If we don't know that this new API actually improves performance
(significantly) compared to using the existing API enhanced with some
under-the-hood fixup, I don't think we have a good case for changing
the API.


On 3 February 2017 at 12:50, Nikhil Agarwal  wrote:
> Signed-off-by: Nikhil Agarwal 
> ---
>  include/odp/api/spec/schedule.h | 36 +++-
>  1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/include/odp/api/spec/schedule.h b/include/odp/api/spec/schedule.h
> index f8fed17..6e8d759 100644
> --- a/include/odp/api/spec/schedule.h
> +++ b/include/odp/api/spec/schedule.h
> @@ -118,8 +118,8 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t 
> wait);
>   * originate from the same source queue and share the same scheduler
>   * synchronization context.
>   *
> - * @param fromOutput parameter for the source queue (where the event was
> - *dequeued from). Ignored if NULL.
> + * @param fromOutput parameter for the source queues array (where the 
> event
> + *   were dequeued from). Ignored if NULL.
>   * @param waitMinimum time to wait for an event. Waits infinitely, if 
> set to
>   *ODP_SCHED_WAIT. Does not wait, if set to ODP_SCHED_NO_WAIT.
>   *Use odp_schedule_wait_time() to convert time to other wait
> @@ -129,7 +129,7 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t 
> wait);
>   *
>   * @return Number of events outputted (0 ... num)
>   */
> -int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t 
> events[],
> +int odp_schedule_multi(odp_queue_t from[], uint64_t wait, odp_event_t 
> events[],
>int num);
>
>  /**
> @@ -170,6 +170,17 @@ void odp_schedule_resume(void);
>  void odp_schedule_release_atomic(void);
>
>  /**
> + * Release the atomic context associated with the events specified by 
> evnets[].
> + *
> + * This call is similar to odp_schedule_release_atomic call which releases 
> context
> + * associated with the events defined by events.
> + * @param events  Input event array for which atomic context is to be 
> released
> + * @param num Number of events
> + *
> + */
> +void odp_schedule_release_atomic_contexts(odp_event_t events[], num);
> +
> +/**
>   * Release the current ordered context
>   *
>   * This call is valid only for source queues with ordered synchronization. It
> @@ -187,6 +198,17 @@ void odp_schedule_release_atomic(void);
>  void odp_schedule_release_ordered(void);
>
>  /**
> + * Release the ordered context associated with the events specified by 
> evnets[].
> + *
> + * This call is similar to odp_schedule_release_ordered call which releases 
> context
> + * associated with the events defined by events.
> + * @param events  Input event array for which ordered context is to be 
> released
> + * @param num Number of events
> + *
> + */
> +void odp_schedule_release_ordered_contexts(odp_event_t events[], num);
> +
> +/**
>   * Prefetch events for next schedule call
>   *
>   * Hint the scheduler that application is about to finish processing the 
> current
> @@ -348,11 +370,13 @@ int odp_schedule_group_info(odp_schedule_group_t group,
>   * allowing order to maintained on a more granular basis. If an ordered lock
>   * is used multiple times in the same ordered context results are undefined.
>   *
> + * @param source_queue Queue handle from which event is recieved and lock to 
> be
> + *aquired.
>   * @param lock_index Index of the ordered lock in the current context to be
>   *   acquired. Must be in the range 0..odp_queue_lock_count()
>   *   - 1
>   */
> -void odp_schedule_order_lock(unsigned lock_index);
> +void odp_schedule_order_lock(odp_queue_t source_queue, unsigned lock_index);
>
>  /**
>   * Release ordered context lock
> @@ -360,12 +384,14 @@ void odp_schedule_order_lock(unsigned lock_index);
>   * This call is valid only when holding an ordered synchronization context.
>   * Release a previously locked ordered context lock.
>   *
> + * @param source_queue Queue handle from which event is recieved and lock to 
> be
> + *aquired.
>   * @param lock_index Index of the ordered lock in the current context to be
>   *   released. Results are undefined if the caller does not
>   *   hold this lock. Must be in the range
>   *   0..odp_queue_lock_count() - 1
>   */
> -void odp_schedule_order_unlock(unsigned lock_index);
> +void odp_schedule_order_unlock(odp_queue_t source_queue, unsigned 
> lock_index);
>
>  /**
>   * @}
> --
> 2.9.3
>

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Christophe Milard

On 3 February 2017 at 14:11, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
>> Sent: Friday, February 03, 2017 2:29 PM
>> To: Petri Savolainen 
>> Cc: LNG ODP Mailman List 
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>> On 3 February 2017 at 12:23, Petri Savolainen
>>  wrote:
>> > There's no platform specific helpers. Helpers may depend on
>> > Linux and make it easier to do common series of Linux system
>> > calls. These kind of helpers are grouped into helper/linux
>> > directory.
>>
>> This is getting really confusing to me! Haven't we defined a
>> "platform" as being a couple {OS, HW}? That is any change in this
>> couple makes a new platform...
>> If we hold to this definition, then linux-helpers becomes platform
>> helpers...
>> Now, my humble opinion is that no-one is using these linux-only
>> helpers and no one ever will unless to enforce their usage by example
>> that people could copy/paste: why would a programmer want to replace a
>> well known linux system call by an ODP helper call? to save a for
>> loop?.
>> We are hitting the same usual problem of lack of proper definition for
>> things, but in this special case, my proposal is called "deletion".
>> :-)
>>
>> Christophe
>
> This is needed by OFP, for example.
>
> The current ODP master (after v1.13) moved things backwards as linux helper 
> (which create e.g. pthreads and call odp_local_init / _term() for those) was 
> renamed as "linux-generic helper". That would need OFP to expose 
> "helper/linux-generic/..." in its Makefiles, which is both ugly and wrong (in 
> the sense that helper code is part application code, not implementation code).

I am really getting confused here...
There are two sorts of things today in the helper (regarding ODPthread
creation):
1)odph_odpthreads_create() familly of functions abstracts the ODP
thread creation, i.e. will create OPD threads. Whether that is a
pthread or linux process or anything else under the hood is hidden: It
just creates a set of ODPthreads. (for those implementation which
(should) supports different implemenation, a helper flag can be used
to select what should be done)

2)linux specific functions creating pthreads or processes. If the
application uses those, the application is definitively binding itself
to linux and is then using these functions instead of calling
pthread_create() or fork() directely.

>From Mikes comment, I understand that OFP is using functions from the
second set. Do they have any reason for doing that? Possibly, if they
share data allocated after the thread creatiion, not using
odp_shm_reserve().
If an application really binds itseft to linux, I don't see anything
wrong if it is reflected in its Makefile ("helper/linux-generic/...").
If OFP does not require any specific type of ODP thread (they just
want concurrency but don't care how this is achieved) , then they
should be using function from the first set.

The Second set of function is not of much value in my eyes: They do
not provide any kind of abstraction, but just some kind of shortcut
avoiding a few things round fork() or pthread_create().
When I see the confusion that they generate, compared to the little
gain they provide (avoiding to write about 100lines of code), I still
feel those function should be part of the application. Most programmer
knows much more about pthread_create() and fork(), and the price
rewritting the little piece of code will probably been seen as lower
than learning the helper API.

The role of the helpers becomes then clearer: Abstracting thing that
can be done differentely on different platform.

Christophe

>
> -Petri
>
>
>
>
>

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Friday, February 03, 2017 2:29 PM
> To: Petri Savolainen 
> Cc: LNG ODP Mailman List 
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 3 February 2017 at 12:23, Petri Savolainen
>  wrote:
> > There's no platform specific helpers. Helpers may depend on
> > Linux and make it easier to do common series of Linux system
> > calls. These kind of helpers are grouped into helper/linux
> > directory.
> 
> This is getting really confusing to me! Haven't we defined a
> "platform" as being a couple {OS, HW}? That is any change in this
> couple makes a new platform...
> If we hold to this definition, then linux-helpers becomes platform
> helpers...
> Now, my humble opinion is that no-one is using these linux-only
> helpers and no one ever will unless to enforce their usage by example
> that people could copy/paste: why would a programmer want to replace a
> well known linux system call by an ODP helper call? to save a for
> loop?.
> We are hitting the same usual problem of lack of proper definition for
> things, but in this special case, my proposal is called "deletion".
> :-)
> 
> Christophe

This is needed by OFP, for example.

The current ODP master (after v1.13) moved things backwards as linux helper 
(which create e.g. pthreads and call odp_local_init / _term() for those) was 
renamed as "linux-generic helper". That would need OFP to expose 
"helper/linux-generic/..." in its Makefiles, which is both ugly and wrong (in 
the sense that helper code is part application code, not implementation code).

-Petri

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Mike Holmes

On 3 February 2017 at 07:59, Sorin Vultureanu  wrote:
> Hi Mike,
>
> My understanding is that you want to remove helper lib, so I have some points 
> why that would be a bad idea:

Not remove helpers, just remove the unused linux spcific API, the
abstract one will remain.

>
> 1. We use these helpers as abstraction layer. The fact that you remove them 
> will add load to change things in OFP. Probably, we will be forced to reuse 
> your deleted code as it provides some abstractization ! That code is still 
> required to run on a platform. We use that abstractization that is right for 
> us and we will be forced to invent other abstractization if you remove yours 
> (if not reuse your code).

But you are not useing the abstraction, you are using the original
linux only API I think.

>
> 2. I strongly believe ODP should provide this process/thread abstractization 
> as the ODP application should be portable! (be it in main ODP lib, or as is 
> now in helper lib)

It does, but you are not calling the abstract API I think

>
> 3. Backward compatibility of code and design (at major or concept level). 
> This means that you can't really remove things and expect ODP developers to 
> be happy with your design changes or the lack of commitment to maintain 
> backward compatibility of any API.

Indeed, and at the same time we have to evolve and move towards a more
cloud friendly configuration, thus the old API was made a compile
option, I am thinking now that a lib to support th old api can remian,
but I dont think it has a place in the general
test/example/perfromance metrics applications, they all use the
abstract helper api.

>
> So in conclusion, my point of view is that you need to make or keep some 
> concept of process/thread that are generic and still have multiple 
> implementations.
>
> I have added Janne and Jere that might have a different point of view, from 
> OFP perspective.
>
> BR,
> Sorin Vultureanu
> Software Engineer
> Linux R&D
> Email  sorin.vulture...@enea.com
> Phone  +40 723.651.943
>
> www.enea.com
>
>
>
> This message, including attachments, is CONFIDENTIAL. It may also be 
> privileged or otherwise protected by law. If you received this email by 
> mistake please let us know by reply and then delete it from your system; you 
> should not copy it or disclose its contents to anyone. All messages sent to 
> and from Enea may be monitored to ensure compliance with internal policies 
> and to protect our business. Emails are not secure and cannot be guaranteed 
> to be error free as they can be intercepted, a mended, lost or destroyed, or 
> contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of email transmission. Anyone who communicates with us by email accepts these 
> risks.
>
>
>> -Original Message-
>> From: Mike Holmes [mailto:mike.hol...@linaro.org]
>> Sent: Friday, February 03, 2017 2:41 PM
>> To: Christophe Milard 
>> Cc: Petri Savolainen ; LNG ODP Mailman List
>> ; Sorin Vultureanu 
>> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
>> linux helpers
>>
>> On 3 February 2017 at 07:28, Christophe Milard
>>  wrote:
>> > On 3 February 2017 at 12:23, Petri Savolainen
>> >  wrote:
>> >> There's no platform specific helpers. Helpers may depend on
>> >> Linux and make it easier to do common series of Linux system
>> >> calls. These kind of helpers are grouped into helper/linux
>> >> directory.
>> >
>> > This is getting really confusing to me! Haven't we defined a
>> > "platform" as being a couple {OS, HW}? That is any change in this
>> > couple makes a new platform...
>> > If we hold to this definition, then linux-helpers becomes platform 
>> > helpers...
>> > Now, my humble opinion is that no-one is using these linux-only
>> > helpers and no one ever will unless to enforce their usage by example
>> > that people could copy/paste: why would a programmer want to replace a
>> > well known linux system call by an ODP helper call? to save a for
>> > loop?.
>> > We are hitting the same usual problem of lack of proper definition for
>> > things, but in this special case, my proposal is called "deletion".
>> > :-)
>> >
>>
>> CC Sorin, I think OFP may be using them, but I am not sure that it
>> needs to, if OFP wants to be Linux specific its not hard to call
>> pthreads etc yourself.
>>
>> Have we established that these are not better off as tested examples /
>> docs rather than actually in a helpers lib. Given that we do not use
>> them in odp-linux at all it feels that they are just clutter.
>>
>> Another angle is that maybe this problem is due to having the tests
>> for all platforms and OS'es in the same repo as a specific linux
>> implimentation, perhaps with the tests all moved out it becomes much
>> clearer and odp-linux the implimentation is free to be entirely Linux
>> centric becasue the tests will use the agnostic API in a separate repo
>>
>> I am glad t

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Sorin Vultureanu

Hi Mike,

My understanding is that you want to remove helper lib, so I have some points 
why that would be a bad idea:

1. We use these helpers as abstraction layer. The fact that you remove them 
will add load to change things in OFP. Probably, we will be forced to reuse 
your deleted code as it provides some abstractization ! That code is still 
required to run on a platform. We use that abstractization that is right for us 
and we will be forced to invent other abstractization if you remove yours (if 
not reuse your code).

2. I strongly believe ODP should provide this process/thread abstractization as 
the ODP application should be portable! (be it in main ODP lib, or as is now in 
helper lib)

3. Backward compatibility of code and design (at major or concept level). This 
means that you can't really remove things and expect ODP developers to be happy 
with your design changes or the lack of commitment to maintain backward 
compatibility of any API.

So in conclusion, my point of view is that you need to make or keep some 
concept of process/thread that are generic and still have multiple 
implementations.

I have added Janne and Jere that might have a different point of view, from OFP 
perspective.

BR,
Sorin Vultureanu
Software Engineer
Linux R&D
Email  sorin.vulture...@enea.com
Phone  +40 723.651.943

www.enea.com

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

> -Original Message-
> From: Mike Holmes [mailto:mike.hol...@linaro.org]
> Sent: Friday, February 03, 2017 2:41 PM
> To: Christophe Milard 
> Cc: Petri Savolainen ; LNG ODP Mailman List
> ; Sorin Vultureanu 
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
> 
> On 3 February 2017 at 07:28, Christophe Milard
>  wrote:
> > On 3 February 2017 at 12:23, Petri Savolainen
> >  wrote:
> >> There's no platform specific helpers. Helpers may depend on
> >> Linux and make it easier to do common series of Linux system
> >> calls. These kind of helpers are grouped into helper/linux
> >> directory.
> >
> > This is getting really confusing to me! Haven't we defined a
> > "platform" as being a couple {OS, HW}? That is any change in this
> > couple makes a new platform...
> > If we hold to this definition, then linux-helpers becomes platform 
> > helpers...
> > Now, my humble opinion is that no-one is using these linux-only
> > helpers and no one ever will unless to enforce their usage by example
> > that people could copy/paste: why would a programmer want to replace a
> > well known linux system call by an ODP helper call? to save a for
> > loop?.
> > We are hitting the same usual problem of lack of proper definition for
> > things, but in this special case, my proposal is called "deletion".
> > :-)
> >
> 
> CC Sorin, I think OFP may be using them, but I am not sure that it
> needs to, if OFP wants to be Linux specific its not hard to call
> pthreads etc yourself.
> 
> Have we established that these are not better off as tested examples /
> docs rather than actually in a helpers lib. Given that we do not use
> them in odp-linux at all it feels that they are just clutter.
> 
> Another angle is that maybe this problem is due to having the tests
> for all platforms and OS'es in the same repo as a specific linux
> implimentation, perhaps with the tests all moved out it becomes much
> clearer and odp-linux the implimentation is free to be entirely Linux
> centric becasue the tests will use the agnostic API in a separate repo
> 
> I am glad that we are finally digging though the helpers to get them right
> 
> 
> > Christophe
> >
> >>
> >> Use --enable-helper-linux configuration option to enable
> >> support for Linux helpers.
> >>
> >> Signed-off-by: Petri Savolainen 
> >> ---
> >>  configure.ac   |  17 +-
> >>  example/Makefile.inc   |   2 +-
> >>  helper/Makefile.am |  18 +-
> >>  helper/include/odp/helper/linux/process.h  |  84 ++
> >>  helper/include/odp/helper/linux/pthread.h  |  66 +
> >>  .../helper/platform/linux-generic/threads_extn.h   | 112 
> >>  helper/linux/thread.c  | 239 
> >>  helper/m4/configure.m4

[lng-odp] [PATCHv3 2/2] validation: classification: add test case for ipv6 src and dst addr

2017-02-03 Thread Balasubramanian Manoharan

Adds test case for ipv6 source and destination address matching

Signed-off-by: Balasubramanian Manoharan 
---
 .../validation/api/classification/classification.h |  21 ++
 .../api/classification/odp_classification_common.c | 149 ++-
 .../classification/odp_classification_test_pmr.c   | 292 +++--
 .../api/classification/odp_classification_tests.c  |  42 ++-
 .../classification/odp_classification_testsuites.h |  14 +-
 5 files changed, 421 insertions(+), 97 deletions(-)

diff --git a/test/common_plat/validation/api/classification/classification.h 
b/test/common_plat/validation/api/classification/classification.h
index d73c821..0192e24 100644
--- a/test/common_plat/validation/api/classification/classification.h
+++ b/test/common_plat/validation/api/classification/classification.h
@@ -55,6 +55,27 @@
 #define DATA_MAGIC 0x01020304
 #define TEST_SEQ_INVALID   ((uint32_t)~0)
 
+/* Test packet Time-to-live */
+#define DEFAULT_TTL  128
+
+/* Test packet default DSCP value */
+#define LOW_DROP_PRECEDENCE  0x02
+#define MEDIUM_DROP_PRECEDENCE   0x04
+#define HIGH_DROP_PRECEDENCE 0x06
+#define DROP_PRECEDENCE_MASK 0x06
+#define DSCP_CLASS1  0x08
+#define DSCP_CLASS2  0x10
+#define DSCP_CLASS3  0x18
+#define DSCP_CLASS4  0x20
+#define DEFAULT_DSCP (DSCP_CLASS2 | LOW_DROP_PRECEDENCE)
+
+/* Test packet default ECN */
+#define DEFAULT_ECN  ODPH_IP_ECN_ECT0
+
+/* Test packet default TOS */
+#define DEFAULT_TOS  ((DEFAULT_DSCP << ODPH_IP_TOS_DSCP_SHIFT) | \
+   DEFAULT_ECN)
+
 /* test functions: */
 void classification_test_create_cos(void);
 void classification_test_destroy_cos(void);
diff --git 
a/test/common_plat/validation/api/classification/odp_classification_common.c 
b/test/common_plat/validation/api/classification/odp_classification_common.c
index f7ec6e5..0ca9083 100644
--- a/test/common_plat/validation/api/classification/odp_classification_common.c
+++ b/test/common_plat/validation/api/classification/odp_classification_common.c
@@ -14,6 +14,16 @@ typedef struct cls_test_packet {
odp_u32be_t seq;
 } cls_test_packet_t;
 
+static uint8_t IPV6_SRC_ADDR[ODPH_IPV6ADDR_LEN] = {
+   /* I.e. :::10.0.0.1 */
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xFF, 0xFF, 10, 0, 0, 1
+};
+
+static uint8_t IPV6_DST_ADDR[ODPH_IPV6ADDR_LEN] = {
+   /* I.e. :::10.0.0.100 */
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xFF, 0xFF, 10, 0, 0, 100
+};
+
 odp_pktio_t create_pktio(odp_queue_type_t q_type, odp_pool_t pool)
 {
odp_pktio_t pktio;
@@ -211,30 +221,30 @@ odp_pool_t pool_create(const char *poolname)
return odp_pool_create(poolname, ¶m);
 }
 
-odp_packet_t create_packet(odp_pool_t pool, bool vlan,
-  odp_atomic_u32_t *seq, bool flag_udp)
-{
-   return create_packet_len(pool, vlan, seq, flag_udp, 0);
-}
-
-odp_packet_t create_packet_len(odp_pool_t pool, bool vlan,
-  odp_atomic_u32_t *seq, bool flag_udp,
-  uint16_t len)
+odp_packet_t create_packet(cls_packet_info_t pkt_info)
 {
uint32_t seqno;
odph_ethhdr_t *ethhdr;
odph_udphdr_t *udp;
odph_tcphdr_t *tcp;
odph_ipv4hdr_t *ip;
+   odph_ipv6hdr_t *ipv6;
uint16_t payload_len;
uint64_t src_mac = CLS_DEFAULT_SMAC;
uint64_t dst_mac = CLS_DEFAULT_DMAC;
uint64_t dst_mac_be;
uint32_t addr = 0;
uint32_t mask;
-   int offset;
odp_packet_t pkt;
int packet_len = 0;
+   uint32_tversion, tc, flow, ver_tc_flow;
+   uint8_t *buf, next_hdr;
+   uint32_tl4_len, l3_len, l2_len, l3_offset, l4_offset;
+   uint16_t vlan_hdr_len = 0;
+   uint16_t l2_hdr_len = 0;
+   uint16_t l3_hdr_len = 0;
+   uint16_t l4_hdr_len = 0;
+   uint16_t eth_type;
 
/* 48 bit ethernet address needs to be left shifted for proper
value after changing to be*/
@@ -242,77 +252,85 @@ odp_packet_t create_packet_len(odp_pool_t pool, bool vlan,
if (dst_mac != dst_mac_be)
dst_mac_be = dst_mac_be >> (64 - 8 * ODPH_ETHADDR_LEN);
 
-   payload_len = sizeof(cls_test_packet_t) + len;
-   packet_len += ODPH_ETHHDR_LEN;
-   packet_len += ODPH_IPV4HDR_LEN;
-   if (flag_udp)
-   packet_len += ODPH_UDPHDR_LEN;
-   else
-   packet_len += ODPH_TCPHDR_LEN;
-   packet_len += payload_len;
-
-   if (vlan)
-   packet_len += ODPH_VLANHDR_LEN;
-
-   pkt = odp_packet_alloc(pool, packet_len);
+   payload_len = sizeof(cls_test_packet_t) + pkt_info.len;
+   seqno = odp_atomic_fetch_inc_u32(pkt_info.seq);
+
+   vlan_hdr_len = pkt_info.vlan ? ODPH_VLANHDR_LEN : 0;
+   l3_hdr_len = pkt_info.ipv6 ? ODPH_IPV6HDR_LEN : ODPH_IPV4HDR_LEN;
+   l4_hdr_len = pkt_info.udp ? ODPH_UDPHDR_LEN : ODP

[lng-odp] [PATCHv3 1/2] linux-generic: classification: implement ipv6 packet matching rule

2017-02-03 Thread Balasubramanian Manoharan

Adds test case for ipv6 source and destination address matching

Signed-off-by: Balasubramanian Manoharan 
---
v3: performance enhancement using bitwise AND for ip address mask

 .../include/odp_classification_datamodel.h | 11 -
 .../include/odp_classification_inlines.h   | 52 ++
 .../linux-generic/include/odp_packet_internal.h|  5 +++
 platform/linux-generic/include/protocols/ip.h  | 14 +-
 platform/linux-generic/odp_classification.c| 27 +++
 platform/linux-generic/odp_packet.c|  2 +-
 6 files changed, 99 insertions(+), 12 deletions(-)

diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index f6393ee..140f39e 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -25,6 +25,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 
 /* Maximum Class Of Service Entry */
 #define ODP_COS_MAX_ENTRY  64
@@ -43,7 +44,7 @@ extern "C" {
 /* Max L3 QoS Value */
 #define ODP_COS_MAX_L3_QOS (1 << ODP_COS_L3_QOS_BITS)
 /* Max PMR Term bits */
-#define ODP_PMR_TERM_BYTES_MAX 8
+#define ODP_PMR_TERM_BYTES_MAX 16
 
 /**
 Packet Matching Rule Term Value
@@ -67,6 +68,14 @@ typedef struct pmr_term_value {
/** End value of the range */
uint64_tval_end;
} range;
+   struct {
+   _odp_ipv6_addr_t addr;
+   _odp_ipv6_addr_t mask;
+   } match_ipv6;
+   struct {
+   _odp_ipv6_addr_t addr_start;
+   _odp_ipv6_addr_t addr_end;
+   } range_ipv6;
};
uint32_toffset; /**< Offset if term == ODP_PMR_CUSTOM_FRAME */
uint32_tval_sz; /**< Size of the value to be matched */
diff --git a/platform/linux-generic/include/odp_classification_inlines.h 
b/platform/linux-generic/include/odp_classification_inlines.h
index b839197..e6f9be9 100644
--- a/platform/linux-generic/include/odp_classification_inlines.h
+++ b/platform/linux-generic/include/odp_classification_inlines.h
@@ -25,6 +25,8 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* PMR term value verification function
 These functions verify the given PMR term value with the value in the packet
@@ -179,19 +181,53 @@ static inline int verify_pmr_dmac(const uint8_t *pkt_addr,
return 0;
 }
 
-static inline int verify_pmr_ipv6_saddr(const uint8_t *pkt_addr ODP_UNUSED,
-   odp_packet_hdr_t *pkt_hdr ODP_UNUSED,
-   pmr_term_value_t *term_value ODP_UNUSED)
+static inline int verify_pmr_ipv6_saddr(const uint8_t *pkt_addr,
+   odp_packet_hdr_t *pkt_hdr,
+   pmr_term_value_t *term_value)
 {
-   ODP_UNIMPLEMENTED();
+   const _odp_ipv6hdr_t *ipv6;
+   uint64_t addr[2];
+
+   if (!packet_hdr_has_ipv6(pkt_hdr))
+   return 0;
+
+   ipv6 = (const _odp_ipv6hdr_t *)(pkt_addr + pkt_hdr->p.l3_offset);
+
+   addr[0] = ipv6->src_addr.u64[0];
+   addr[1] = ipv6->src_addr.u64[1];
+
+   /* 128 bit address is processed as two 64 bit value
+   * for bitwise AND operation */
+   addr[0] = addr[0] & term_value->match_ipv6.mask.u64[0];
+   addr[1] = addr[1] & term_value->match_ipv6.mask.u64[1];
+
+   if (!memcmp(addr, term_value->match_ipv6.addr.u8, _ODP_IPV6ADDR_LEN))
+   return 1;
+
return 0;
 }
 
-static inline int verify_pmr_ipv6_daddr(const uint8_t *pkt_addr ODP_UNUSED,
-   odp_packet_hdr_t *pkt_hdr ODP_UNUSED,
-   pmr_term_value_t *term_value ODP_UNUSED)
+static inline int verify_pmr_ipv6_daddr(const uint8_t *pkt_addr,
+   odp_packet_hdr_t *pkt_hdr,
+   pmr_term_value_t *term_value)
 {
-   ODP_UNIMPLEMENTED();
+   const _odp_ipv6hdr_t *ipv6;
+   uint64_t addr[2];
+
+   if (!packet_hdr_has_ipv6(pkt_hdr))
+   return 0;
+   ipv6 = (const _odp_ipv6hdr_t *)(pkt_addr + pkt_hdr->p.l3_offset);
+   addr[0] = ipv6->dst_addr.u64[0];
+   addr[1] = ipv6->dst_addr.u64[1];
+
+   /* 128 bit address is processed as two 64 bit value
+   * for bitwise AND operation */
+   addr[0] = addr[0] & term_value->match_ipv6.mask.u64[0];
+   addr[1] = addr[1] & term_value->match_ipv6.mask.u64[1];
+
+   if (!memcmp(addr, term_value->match_ipv6.addr.u8, _ODP_IPV6ADDR_LEN))
+   return 1;
+
return 0;
 }
 
diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index e6e9d

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Mike Holmes

On 3 February 2017 at 07:28, Christophe Milard
 wrote:
> On 3 February 2017 at 12:23, Petri Savolainen
>  wrote:
>> There's no platform specific helpers. Helpers may depend on
>> Linux and make it easier to do common series of Linux system
>> calls. These kind of helpers are grouped into helper/linux
>> directory.
>
> This is getting really confusing to me! Haven't we defined a
> "platform" as being a couple {OS, HW}? That is any change in this
> couple makes a new platform...
> If we hold to this definition, then linux-helpers becomes platform helpers...
> Now, my humble opinion is that no-one is using these linux-only
> helpers and no one ever will unless to enforce their usage by example
> that people could copy/paste: why would a programmer want to replace a
> well known linux system call by an ODP helper call? to save a for
> loop?.
> We are hitting the same usual problem of lack of proper definition for
> things, but in this special case, my proposal is called "deletion".
> :-)
>

CC Sorin, I think OFP may be using them, but I am not sure that it
needs to, if OFP wants to be Linux specific its not hard to call
pthreads etc yourself.

Have we established that these are not better off as tested examples /
docs rather than actually in a helpers lib. Given that we do not use
them in odp-linux at all it feels that they are just clutter.

Another angle is that maybe this problem is due to having the tests
for all platforms and OS'es in the same repo as a specific linux
implimentation, perhaps with the tests all moved out it becomes much
clearer and odp-linux the implimentation is free to be entirely Linux
centric becasue the tests will use the agnostic API in a separate repo

I am glad that we are finally digging though the helpers to get them right


> Christophe
>
>>
>> Use --enable-helper-linux configuration option to enable
>> support for Linux helpers.
>>
>> Signed-off-by: Petri Savolainen 
>> ---
>>  configure.ac   |  17 +-
>>  example/Makefile.inc   |   2 +-
>>  helper/Makefile.am |  18 +-
>>  helper/include/odp/helper/linux/process.h  |  84 ++
>>  helper/include/odp/helper/linux/pthread.h  |  66 +
>>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>>  helper/linux/thread.c  | 239 
>>  helper/m4/configure.m4 |   8 +-
>>  helper/platform/linux-generic/thread.c | 313 
>> -
>>  helper/test/.gitignore |   1 +
>>  helper/test/Makefile.am|   9 +-
>>  helper/test/linux-generic/Makefile.am  |   5 -
>>  helper/test/linux-generic/process.c|  92 --
>>  helper/test/linux-generic/thread.c |  87 --
>>  helper/test/linux/Makefile.am  |   5 +
>>  helper/test/linux/process.c|  93 ++
>>  helper/test/linux/pthread.c|  87 ++
>>  test/Makefile.inc  |   2 +-
>>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>>  test/linux-generic/Makefile.inc|   2 +-
>>  20 files changed, 599 insertions(+), 645 deletions(-)
>>  create mode 100644 helper/include/odp/helper/linux/process.h
>>  create mode 100644 helper/include/odp/helper/linux/pthread.h
>>  delete mode 100644 
>> helper/include/odp/helper/platform/linux-generic/threads_extn.h
>>  create mode 100644 helper/linux/thread.c
>>  delete mode 100644 helper/platform/linux-generic/thread.c
>>  delete mode 100644 helper/test/linux-generic/Makefile.am
>>  delete mode 100644 helper/test/linux-generic/process.c
>>  delete mode 100644 helper/test/linux-generic/thread.c
>>  create mode 100644 helper/test/linux/Makefile.am
>>  create mode 100644 helper/test/linux/process.c
>>  create mode 100644 helper/test/linux/pthread.c
>>
>> diff --git a/configure.ac b/configure.ac
>> index daa9b31..b672a1a 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -138,18 +138,6 @@ AC_SUBST([with_platform])
>>  AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
>>
>>  ##
>> -# Determine which helper platform to build for
>> -##
>> -AC_ARG_WITH([helper_platform],
>> -[AS_HELP_STRING([--with-helper_platform=platform],
>> -   [select helper platform to be used, default linux-generic])],
>> -[],
>> -[with_helper_platform=${with_platform}
>> -])
>> -
>> -AC_SUBST([with_helper_platform])
>> -
>> -##
>>  # Run platform specific checks and settings
>>  ##
>>  IMPLEMENTATION_NAME=""
>> @@ -214,7 +202,7 @@ AM_CO

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Christophe Milard

On 3 February 2017 at 12:23, Petri Savolainen
 wrote:
> There's no platform specific helpers. Helpers may depend on
> Linux and make it easier to do common series of Linux system
> calls. These kind of helpers are grouped into helper/linux
> directory.

This is getting really confusing to me! Haven't we defined a
"platform" as being a couple {OS, HW}? That is any change in this
couple makes a new platform...
If we hold to this definition, then linux-helpers becomes platform helpers...
Now, my humble opinion is that no-one is using these linux-only
helpers and no one ever will unless to enforce their usage by example
that people could copy/paste: why would a programmer want to replace a
well known linux system call by an ODP helper call? to save a for
loop?.
We are hitting the same usual problem of lack of proper definition for
things, but in this special case, my proposal is called "deletion".
:-)

Christophe

>
> Use --enable-helper-linux configuration option to enable
> support for Linux helpers.
>
> Signed-off-by: Petri Savolainen 
> ---
>  configure.ac   |  17 +-
>  example/Makefile.inc   |   2 +-
>  helper/Makefile.am |  18 +-
>  helper/include/odp/helper/linux/process.h  |  84 ++
>  helper/include/odp/helper/linux/pthread.h  |  66 +
>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>  helper/linux/thread.c  | 239 
>  helper/m4/configure.m4 |   8 +-
>  helper/platform/linux-generic/thread.c | 313 
> -
>  helper/test/.gitignore |   1 +
>  helper/test/Makefile.am|   9 +-
>  helper/test/linux-generic/Makefile.am  |   5 -
>  helper/test/linux-generic/process.c|  92 --
>  helper/test/linux-generic/thread.c |  87 --
>  helper/test/linux/Makefile.am  |   5 +
>  helper/test/linux/process.c|  93 ++
>  helper/test/linux/pthread.c|  87 ++
>  test/Makefile.inc  |   2 +-
>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>  test/linux-generic/Makefile.inc|   2 +-
>  20 files changed, 599 insertions(+), 645 deletions(-)
>  create mode 100644 helper/include/odp/helper/linux/process.h
>  create mode 100644 helper/include/odp/helper/linux/pthread.h
>  delete mode 100644 
> helper/include/odp/helper/platform/linux-generic/threads_extn.h
>  create mode 100644 helper/linux/thread.c
>  delete mode 100644 helper/platform/linux-generic/thread.c
>  delete mode 100644 helper/test/linux-generic/Makefile.am
>  delete mode 100644 helper/test/linux-generic/process.c
>  delete mode 100644 helper/test/linux-generic/thread.c
>  create mode 100644 helper/test/linux/Makefile.am
>  create mode 100644 helper/test/linux/process.c
>  create mode 100644 helper/test/linux/pthread.c
>
> diff --git a/configure.ac b/configure.ac
> index daa9b31..b672a1a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -138,18 +138,6 @@ AC_SUBST([with_platform])
>  AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
>
>  ##
> -# Determine which helper platform to build for
> -##
> -AC_ARG_WITH([helper_platform],
> -[AS_HELP_STRING([--with-helper_platform=platform],
> -   [select helper platform to be used, default linux-generic])],
> -[],
> -[with_helper_platform=${with_platform}
> -])
> -
> -AC_SUBST([with_helper_platform])
> -
> -##
>  # Run platform specific checks and settings
>  ##
>  IMPLEMENTATION_NAME=""
> @@ -214,7 +202,7 @@ AM_CONDITIONAL([test_example], [test x$test_example = 
> xyes ])
>  AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"])
>  AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
>  AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"])
> -AM_CONDITIONAL([helper_extn], [test x$helper_extn = xyes ])
> +AM_CONDITIONAL([helper_linux], [test x$helper_linux = xyes ])
>
>  ##
>  # Setup doxygen documentation
> @@ -345,8 +333,7 @@ AC_MSG_RESULT([
> implementation_name:${IMPLEMENTATION_NAME}
> ARCH_DIR${ARCH_DIR}
> with_platform:  ${with_platform}
> -   with_helper_platform:   ${with_helper_platform}
> -   helper_extn:${helper_extn}
> +   helper_linux:   ${helper_linux}
> prefix: ${prefix}
> sysconfdir: ${sysco

Re: [lng-odp] [PATCH 2/2] helper: add stubs for missing documentation

2017-02-03 Thread Mike Holmes

Is this a duplicate of http://patches.opendataplane.org/patch/8030/

On 3 February 2017 at 06:24, Petri Savolainen
 wrote:
> This suppress excessive amount of doxygen warnings caused by
> missing helper documentation. Other more improtant warnings
> may go unnoticed if these warning fill the screen.
>
> Signed-off-by: Petri Savolainen 
> ---
>  helper/include/odp/helper/odph_cuckootable.h   | 52 +++
>  helper/include/odp/helper/odph_hashtable.h | 57 
> ++
>  helper/include/odp/helper/odph_iplookuptable.h | 57 
> +-
>  helper/include/odp/helper/odph_lineartable.h   | 48 ++
>  4 files changed, 212 insertions(+), 2 deletions(-)
>
> diff --git a/helper/include/odp/helper/odph_cuckootable.h 
> b/helper/include/odp/helper/odph_cuckootable.h
> index d569980..65cd555 100644
> --- a/helper/include/odp/helper/odph_cuckootable.h
> +++ b/helper/include/odp/helper/odph_cuckootable.h
> @@ -52,27 +52,79 @@
>  extern "C" {
>  #endif
>
> +/**
> + * documentation missing
> + *
> + * @param name
> + * @param capacity
> + * @param key_size
> + * @param value_size
> + *
> + * @return
> + */
>  odph_table_t odph_cuckoo_table_create(
> const char *name,
> uint32_t capacity,
> uint32_t key_size,
> uint32_t value_size);
>
> +/**
> + * documentation missing
> + *
> + * @param name
> + *
> + * @return
> + */
>  odph_table_t odph_cuckoo_table_lookup(const char *name);
>
> +/**
> + * documentation missing
> + *
> + * @param table
> + *
> + * @return
> + */
>  int odph_cuckoo_table_destroy(odph_table_t table);
>
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + * @param value
> + *
> + * @return
> + */
>  int odph_cuckoo_table_put_value(
> odph_table_t table,
> void *key, void *value);
>
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + * @param buffer
> + * @param buffer_size
> + *
> + * @return
> + */
>  int odph_cuckoo_table_get_value(
> odph_table_t table,
> void *key, void *buffer,
> uint32_t buffer_size);
>
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + *
> + * @return
> + */
>  int odph_cuckoo_table_remove_value(odph_table_t table, void *key);
>
> +/** documentation missing */
>  extern odph_table_ops_t odph_cuckoo_table_ops;
>
>  #ifdef __cplusplus
> diff --git a/helper/include/odp/helper/odph_hashtable.h 
> b/helper/include/odp/helper/odph_hashtable.h
> index bb75cb9..d3dce99 100644
> --- a/helper/include/odp/helper/odph_hashtable.h
> +++ b/helper/include/odp/helper/odph_hashtable.h
> @@ -19,17 +19,74 @@
>  extern "C" {
>  #endif
>
> +/**
> + * documentation missing
> + *
> + * @param name
> + * @param capacity
> + * @param key_size
> + * @param value_size
> + *
> + * @return
> + */
>  odph_table_t odph_hash_table_create(const char *name,
> uint32_t capacity,
> uint32_t key_size,
> uint32_t value_size);
> +
> +/**
> + * documentation missing
> + *
> + * @param name
> + *
> + * @return
> + */
>  odph_table_t odph_hash_table_lookup(const char *name);
> +
> +/**
> + * documentation missing
> + *
> + * @param table
> + *
> + * @return
> + */
>  int odph_hash_table_destroy(odph_table_t table);
> +
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + * @param value
> + *
> + * @return
> + */
>  int odph_hash_put_value(odph_table_t table, void *key, void *value);
> +
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + * @param buffer
> + * @param buffer_size
> + *
> + * @return
> + */
>  int odph_hash_get_value(odph_table_t table, void *key, void *buffer,
> uint32_t buffer_size);
> +
> +/**
> + * documentation missing
> + *
> + * @param table
> + * @param key
> + *
> + * @return
> + */
>  int odph_hash_remove_value(odph_table_t table, void *key);
>
> +/** documentation missing */
>  extern odph_table_ops_t odph_hash_table_ops;
>
>  #ifdef __cplusplus
> diff --git a/helper/include/odp/helper/odph_iplookuptable.h 
> b/helper/include/odp/helper/odph_iplookuptable.h
> index 0ae6b37..f5da493 100644
> --- a/helper/include/odp/helper/odph_iplookuptable.h
> +++ b/helper/include/odp/helper/odph_iplookuptable.h
> @@ -24,31 +24,84 @@
>  extern "C" {
>  #endif
>
> +/** documentation missing */
>  typedef struct {
> -   uint32_t ip;
> -   uint8_t cidr;
> +   uint32_t ip;  /**< IP */
> +   uint8_t cidr; /**< CIDR */
>  } odph_iplookup_prefix_t;
>
> +/**
> + * documentation missing
> + *
> + * @param name
> + * @param ODP_IGNORED_1
> + * @param ODP_IGNORED_2
> + * @param value_size
> + *
> + * @return
> + */
>  odph_table_t odph_iplookup_table_create(
> const char *name,
> uint32_t ODP_IGNO

[lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

2017-02-03 Thread Petri Savolainen

There's no platform specific helpers. Helpers may depend on
Linux and make it easier to do common series of Linux system
calls. These kind of helpers are grouped into helper/linux
directory.

Use --enable-helper-linux configuration option to enable
support for Linux helpers.

Signed-off-by: Petri Savolainen 
---
 configure.ac   |  17 +-
 example/Makefile.inc   |   2 +-
 helper/Makefile.am |  18 +-
 helper/include/odp/helper/linux/process.h  |  84 ++
 helper/include/odp/helper/linux/pthread.h  |  66 +
 .../helper/platform/linux-generic/threads_extn.h   | 112 
 helper/linux/thread.c  | 239 
 helper/m4/configure.m4 |   8 +-
 helper/platform/linux-generic/thread.c | 313 -
 helper/test/.gitignore |   1 +
 helper/test/Makefile.am|   9 +-
 helper/test/linux-generic/Makefile.am  |   5 -
 helper/test/linux-generic/process.c|  92 --
 helper/test/linux-generic/thread.c |  87 --
 helper/test/linux/Makefile.am  |   5 +
 helper/test/linux/process.c|  93 ++
 helper/test/linux/pthread.c|  87 ++
 test/Makefile.inc  |   2 +-
 test/common_plat/validation/api/Makefile.inc   |   2 +-
 test/linux-generic/Makefile.inc|   2 +-
 20 files changed, 599 insertions(+), 645 deletions(-)
 create mode 100644 helper/include/odp/helper/linux/process.h
 create mode 100644 helper/include/odp/helper/linux/pthread.h
 delete mode 100644 
helper/include/odp/helper/platform/linux-generic/threads_extn.h
 create mode 100644 helper/linux/thread.c
 delete mode 100644 helper/platform/linux-generic/thread.c
 delete mode 100644 helper/test/linux-generic/Makefile.am
 delete mode 100644 helper/test/linux-generic/process.c
 delete mode 100644 helper/test/linux-generic/thread.c
 create mode 100644 helper/test/linux/Makefile.am
 create mode 100644 helper/test/linux/process.c
 create mode 100644 helper/test/linux/pthread.c

diff --git a/configure.ac b/configure.ac
index daa9b31..b672a1a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -138,18 +138,6 @@ AC_SUBST([with_platform])
 AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
 
 ##
-# Determine which helper platform to build for
-##
-AC_ARG_WITH([helper_platform],
-[AS_HELP_STRING([--with-helper_platform=platform],
-   [select helper platform to be used, default linux-generic])],
-[],
-[with_helper_platform=${with_platform}
-])
-
-AC_SUBST([with_helper_platform])
-
-##
 # Run platform specific checks and settings
 ##
 IMPLEMENTATION_NAME=""
@@ -214,7 +202,7 @@ AM_CONDITIONAL([test_example], [test x$test_example = xyes 
])
 AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"])
 AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
 AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"])
-AM_CONDITIONAL([helper_extn], [test x$helper_extn = xyes ])
+AM_CONDITIONAL([helper_linux], [test x$helper_linux = xyes ])
 
 ##
 # Setup doxygen documentation
@@ -345,8 +333,7 @@ AC_MSG_RESULT([
implementation_name:${IMPLEMENTATION_NAME}
ARCH_DIR${ARCH_DIR}
with_platform:  ${with_platform}
-   with_helper_platform:   ${with_helper_platform}
-   helper_extn:${helper_extn}
+   helper_linux:   ${helper_linux}
prefix: ${prefix}
sysconfdir: ${sysconfdir}
libdir: ${libdir}
diff --git a/example/Makefile.inc b/example/Makefile.inc
index ea596d5..70e3758 100644
--- a/example/Makefile.inc
+++ b/example/Makefile.inc
@@ -1,6 +1,6 @@
 include $(top_srcdir)/platform/@with_platform@/Makefile.inc
 LIB   = $(top_builddir)/lib
-LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper-@with_helper_platform@.la
+LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper.la
 AM_CFLAGS += \
-I$(srcdir) \
-I$(top_srcdir)/example \
diff --git a/helper/Makefile.am b/helper/Makefile.am
index d484679..9b6e3ce 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -30,16 +30,18 @@ helperinclude_HEADERS = \
  $(srcdir)/include/odp/helper/threads.h \
  $(srcdir)/include/odp/helper/udp.h
 
-if helper_extn
-helperinclude_HEADERS += \
-   
$(srcdir)/include/odp/helper/platform/@with_he

[lng-odp] [PATCH 2/2] helper: add stubs for missing documentation

2017-02-03 Thread Petri Savolainen

This suppress excessive amount of doxygen warnings caused by
missing helper documentation. Other more improtant warnings
may go unnoticed if these warning fill the screen.

Signed-off-by: Petri Savolainen 
---
 helper/include/odp/helper/odph_cuckootable.h   | 52 +++
 helper/include/odp/helper/odph_hashtable.h | 57 ++
 helper/include/odp/helper/odph_iplookuptable.h | 57 +-
 helper/include/odp/helper/odph_lineartable.h   | 48 ++
 4 files changed, 212 insertions(+), 2 deletions(-)

diff --git a/helper/include/odp/helper/odph_cuckootable.h 
b/helper/include/odp/helper/odph_cuckootable.h
index d569980..65cd555 100644
--- a/helper/include/odp/helper/odph_cuckootable.h
+++ b/helper/include/odp/helper/odph_cuckootable.h
@@ -52,27 +52,79 @@
 extern "C" {
 #endif
 
+/**
+ * documentation missing
+ *
+ * @param name
+ * @param capacity
+ * @param key_size
+ * @param value_size
+ *
+ * @return
+ */
 odph_table_t odph_cuckoo_table_create(
const char *name,
uint32_t capacity,
uint32_t key_size,
uint32_t value_size);
 
+/**
+ * documentation missing
+ *
+ * @param name
+ *
+ * @return
+ */
 odph_table_t odph_cuckoo_table_lookup(const char *name);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ *
+ * @return
+ */
 int odph_cuckoo_table_destroy(odph_table_t table);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ * @param value
+ *
+ * @return
+ */
 int odph_cuckoo_table_put_value(
odph_table_t table,
void *key, void *value);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ * @param buffer
+ * @param buffer_size
+ *
+ * @return
+ */
 int odph_cuckoo_table_get_value(
odph_table_t table,
void *key, void *buffer,
uint32_t buffer_size);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ *
+ * @return
+ */
 int odph_cuckoo_table_remove_value(odph_table_t table, void *key);
 
+/** documentation missing */
 extern odph_table_ops_t odph_cuckoo_table_ops;
 
 #ifdef __cplusplus
diff --git a/helper/include/odp/helper/odph_hashtable.h 
b/helper/include/odp/helper/odph_hashtable.h
index bb75cb9..d3dce99 100644
--- a/helper/include/odp/helper/odph_hashtable.h
+++ b/helper/include/odp/helper/odph_hashtable.h
@@ -19,17 +19,74 @@
 extern "C" {
 #endif
 
+/**
+ * documentation missing
+ *
+ * @param name
+ * @param capacity
+ * @param key_size
+ * @param value_size
+ *
+ * @return
+ */
 odph_table_t odph_hash_table_create(const char *name,
uint32_t capacity,
uint32_t key_size,
uint32_t value_size);
+
+/**
+ * documentation missing
+ *
+ * @param name
+ *
+ * @return
+ */
 odph_table_t odph_hash_table_lookup(const char *name);
+
+/**
+ * documentation missing
+ *
+ * @param table
+ *
+ * @return
+ */
 int odph_hash_table_destroy(odph_table_t table);
+
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ * @param value
+ *
+ * @return
+ */
 int odph_hash_put_value(odph_table_t table, void *key, void *value);
+
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ * @param buffer
+ * @param buffer_size
+ *
+ * @return
+ */
 int odph_hash_get_value(odph_table_t table, void *key, void *buffer,
uint32_t buffer_size);
+
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ *
+ * @return
+ */
 int odph_hash_remove_value(odph_table_t table, void *key);
 
+/** documentation missing */
 extern odph_table_ops_t odph_hash_table_ops;
 
 #ifdef __cplusplus
diff --git a/helper/include/odp/helper/odph_iplookuptable.h 
b/helper/include/odp/helper/odph_iplookuptable.h
index 0ae6b37..f5da493 100644
--- a/helper/include/odp/helper/odph_iplookuptable.h
+++ b/helper/include/odp/helper/odph_iplookuptable.h
@@ -24,31 +24,84 @@
 extern "C" {
 #endif
 
+/** documentation missing */
 typedef struct {
-   uint32_t ip;
-   uint8_t cidr;
+   uint32_t ip;  /**< IP */
+   uint8_t cidr; /**< CIDR */
 } odph_iplookup_prefix_t;
 
+/**
+ * documentation missing
+ *
+ * @param name
+ * @param ODP_IGNORED_1
+ * @param ODP_IGNORED_2
+ * @param value_size
+ *
+ * @return
+ */
 odph_table_t odph_iplookup_table_create(
const char *name,
uint32_t ODP_IGNORED_1,
uint32_t ODP_IGNORED_2,
uint32_t value_size);
 
+/**
+ * documentation missing
+ *
+ * @param name
+ *
+ * @return
+ */
 odph_table_t odph_iplookup_table_lookup(const char *name);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ *
+ * @return
+ */
 int odph_iplookup_table_destroy(odph_table_t table);
 
+/**
+ * documentation missing
+ *
+ * @param table
+ * @param key
+ * @param value
+ *
+ * @return
+ */
 int odph_iplookup_table_put_value(
odph_tab

[lng-odp] [Bug 2873] New: code coverage odp_timer_wheel.c

Re: [lng-odp] [API-NEXT PATCH] doc: userguide: add section on application portability

Re: [lng-odp] Fwd: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file

[lng-odp] Fwd: [Linaro/odp] 25ed19: abi: event: added the first ABI spec file

[lng-odp] [Bug 2872] New: odp_pktio_ordered_run.sh: line 34: [: : integer expression expected

Re: [lng-odp] [PATCH v4 0/8] First ABI files

Re: [lng-odp] rstp support on odp

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH] [RFC] API:update odp_schedle_multi to return events from multiple queues.

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[lng-odp] [PATCHv3 2/2] validation: classification: add test case for ipv6 src and dst addr

[lng-odp] [PATCHv3 1/2] linux-generic: classification: implement ipv6 packet matching rule

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

Re: [lng-odp] [PATCH 2/2] helper: add stubs for missing documentation

[lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to linux helpers

[lng-odp] [PATCH 2/2] helper: add stubs for missing documentation

20 matches

Site Navigation

Mail list logo

Footer information