[lng-odp] [API-NEXT PATCH v2 1/2] doc: images: add traffic manager svg

[Mike Holmes]

Signed-off-by: Mike Holmes 
---
v2:
   Updated digram for the node to match text

 doc/images/tm_hierarchy.svg | 2418 +++
 doc/images/tm_node.svg  | 1178 +
 2 files changed, 3596 insertions(+)
 create mode 100644 doc/images/tm_hierarchy.svg
 create mode 100644 doc/images/tm_node.svg

diff --git a/doc/images/tm_hierarchy.svg b/doc/images/tm_hierarchy.svg
new file mode 100644
index 000..740d43b
--- /dev/null
+++ b/doc/images/tm_hierarchy.svg
@@ -0,0 +1,2418 @@
+
+
+
+
+
+http://purl.org/dc/elements/1.1/;
+   xmlns:cc="http://creativecommons.org/ns#;
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+   xmlns:svg="http://www.w3.org/2000/svg;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:xlink="http://www.w3.org/1999/xlink;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
+   width="1362px"
+   height="600px"
+   viewBox="0 0 1362 600"
+   id="svg4136"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="tm_hierarchy.svg">
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage; />
+
+  
+
+  
+  
+  
+
+  
+
+
+
+
+
+
+
+
+
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+  
+  
+  
+q28
+
+q28
+  
+  
+a1
+
+User-18
+  
+  
+q28-a1
+
+
+  
+  
+q29
+
+q29
+  
+  
+q29-a1
+
+
+  
+  
+q30
+
+q30
+  
+  
+q30-a1
+
+
+  
+  
+q31
+
+q31
+  
+  
+q31-a1
+
+
+  
+  
+q25
+
+q25
+  
+  
+a2
+
+User-16
+  
+  
+q25-a2
+
+
+  
+  
+q26
+
+q26
+  
+  
+q26-a2
+
+
+  
+  
+q27
+
+q27
+  
+  
+a3
+
+User-17
+  
+  
+q27-a3
+
+
+  
+  
+q32
+
+q32
+  
+  
+a4
+
+User-19
+  
+  
+q32-a4
+
+
+  
+  
+q16
+
+q16
+  
+  
+a5
+
+User-11
+  
+  
+q16-a5
+
+
+  
+  
+q17
+
+q17
+  
+  
+q17-a5
+
+
+  
+  
+q18
+
+q18
+  
+  
+a6
+
+User-12
+  
+  
+q18-a6
+
+
+  
+  
+q19
+
+q19
+  
+  
+q19-a6
+
+
+  
+  
+q20
+
+q20
+  
+  
+a7
+
+User-13
+  
+  
+q20-a7
+
+
+  
+  
+q21
+
+q21
+  
+  
+a8
+
+User-14
+  
+  
+q21-a8
+
+
+  
+  
+q22
+
+q22
+  
+  
+q22-a8
+
+
+  
+  
+q23
+
+q23
+  
+  
+a9
+
+User-15
+  
+  
+q23-a9
+
+
+  
+  
+q24
+
+q24
+  
+  
+q24-a9
+
+
+  
+  
+q1
+
+q1
+  
+  
+a10
+
+User-1
+  
+  
+q1-a10
+
+
+  
+  
+q2
+
+q2
+  
+  
+a11
+
+User-2
+  
+  
+q2-a11
+
+
+  
+  
+q3
+
+q3
+  
+  
+a12
+
+User-3
+  
+  
+q3-a12
+
+
+  
+  
+q4
+
+q4
+  
+  
+q4-a12
+
+
+  
+  
+q5
+
+q5
+  
+  
+a13
+
+User-4
+  
+  
+q5-a13
+
+
+  
+  
+q6
+
+q6
+  
+  
+q6-a13
+
+
+  
+  
+q7
+
+q7
+  
+  
+a14
+
+User-5
+  
+  
+q7-a14
+
+
+  
+  
+q8
+
+q8
+  
+  
+q8-a14
+
+
+  
+  
+q9
+
+q9
+  
+  
+a15
+
+User-6
+  
+  
+q9-a15
+
+
+  
+  
+q10
+
+q10
+  
+  
+a16
+
+User-7
+  
+  
+q10-a16
+
+
+  
+  
+q11
+
+q11
+  
+  
+a17
+
+User-8
+  
+  
+q11-a17
+
+
+  
+  
+q12
+
+q12
+  
+  
+q12-a17
+
+
+  
+  
+q13
+
+q13
+  
+  
+a18
+
+User-9
+  
+  
+q13-a18
+
+
+  
+  
+q14
+
+q14
+  
+  
+a19
+
+User-10
+  
+  
+q14-a19
+
+
+  
+  
+q15
+
+q15
+  
+  
+q15-a19
+
+
+  
+  
+b1
+
+Gold-C3
+  
+  
+a1-b1
+
+
+  
+  
+a2-b1
+
+
+  
+  
+a3-b1
+
+
+  
+  
+a4-b1
+
+
+  
+  
+b2
+
+Bronze-C3
+  
+  
+a5-b2
+
+
+  
+  
+a6-b2
+
+
+  
+  
+a7-b2
+
+
+  
+  
+b3
+
+Silver-C3
+  
+  
+a8-b3
+
+
+  
+  
+a9-b3
+
+
+  
+  
+b4
+
+Regular-C1
+  
+  
+a10-b4
+
+
+  
+  
+a11-b4
+
+
+  
+  
+a12-b4
+
+
+  
+  
+b5
+
+Premium-C1
+  
+  
+a13-b5
+
+
+  
+  
+a14-b5
+
+
+  
+  
+a15-b5
+
+
+  
+  
+b6
+
+Normal-C2
+  
+  
+a16-b6
+
+
+  
+  
+a17-b6
+
+

Re: [lng-odp] Driver interface definition...

[Bill Fischofer]

In thinking about how ODP drivers relate to the rest of ODP it is useful to
consider this from a client/server perspective.  For ODP applications, the
ODP API defines an interface that allows client applications to request
services from an ODP implementation without either the application or ODP
implementation being tied to each other.  That is, the API defines a
portability boundary as well as a service boundary.

For ODP drivers, it's useful to consider the ODP Driver API as defining a
similar portability and service boundary layer, this time with the ODP
implementation as the client and the ODP driver providing services to it,
thus allowing ODP implementations have I/O portability across different
NICs.  However the ODP implementation also provides services to the driver
to enable it to be portable across ODP implementations.

We therefore have two related but logically distinct driver-level APIs.  A
"northbound" driver boundary that defines the services that each ODP
implementation must provide to drivers to enable them to be portable across
different implementations and a "southbound" driver boundary that defines
the services that each ODP driver must provide to implementations to enable
them to provide ODP's pktio services to applications in a
device-independent manner.

The boundaries might thus be viewed as follows:

 +-+
 | ODP Application |
 +-+

   ODP API  <-- Defined in include/odp.h

   ++
   | ODP Implementation |
   ++
|  A
V  |
=ODP Driver I/O API=  =ODP Driver Service API=
|  A
V  |
++   ++
| ODP Driver | . . . | ODP Driver |
++   ++

These two API boundaries would have their own header files. A question is,
should the ODP Driver Service API simply be the existing odp.h file?
Perhaps not, because the types of services needed by a driver may require
special privileges that are not desirable for ODP applications or may be
less portable than is desired for ODP Applications. But something to
explore further.


On Mon, Jan 11, 2016 at 3:48 PM, Mike Holmes  wrote:

> Anders, Christophe and I had a discussion and here are some very rough
> notes on what I think settled out of it.
>
> Requirements:
> We wanted something that scales if more interfaces to ODP are defined and
> openStack was suggested as the sort of east/west that may occur
> We want the actual driver implementations to be externally developed and
> use the odp_driver interface, but not be part of the odp reference repo,
> they will be in their own repo and are a lot like regular applications in
> how they relate to the api.
> Applications use drivers and odp platforms as needed, thus at a top level
> in the diagram there are three entities, with the application attaching the
> drivers it wants.
> The tree should make sense in its ordering of includes,  with a higher
> level including from below generally and not bouncing up and down with ../
>  etc
> We would like different entry points to help debugging, for example in a
> log to be able to distinguish a driver dma operation from an application
> dma operation even though the implementation will be identical on that
> platform.
> We would like to be able to alter the interfaces independently for the
> same basic concept - maybe dma in once case needs different semantics to
> the other, who knows what we may find.
>
> .
> ├── odp_drivers
> │   ├── my_nic1
> │   │   └── my_code.c
> │   └── my_nic2
> │   └── my_code.c
> ├── my_application
> │   └── my_code.c
> └── odp
> ├── include
> │   ├── odp
> │   │   ├── api
> │   │   └── driver
> │   ├── odp_driver.h
> │   └── odp.h
> └── platform
> └── linux-generic
> └── include
> ├── api
> │   ├── plat
> │   └── shared_memory.h
> └── driver
> └── shared_memory.h
>
> The discussion ended up suggest changing to creating facades, one for each
> of the different interfaces to a ODP Platform.
> So in  odp_driver.h and in odp.h  you may have two facades for the same
> common code in the platform for say dma access. These two facades can have
> a different prefix to the same code :-  odp_dma for applications (north
> bound) and odpd_dma for drivers (south bound) and they end up reusing the
> same .c file and function implementation.
>
> We had open questions:
> 1. Do we need the odp_driver to have something down under platform to make
> this work ?
> 2. How do we solve the includes - note that in the diagram under
> linux-generic/include we renamed odp to api for symmetry in discussion,
> that is not how it is currently.
>
>
>
>
>
> On 11 January 2016 at 12:30, Christophe Milard <
> christophe.mil...@linaro.org> wrote:

[lng-odp] [API-NEXT PATCH v2 2/2] doc: users: migrate TM from API to users doc

[Mike Holmes]

Signed-off-by: Mike Holmes 
---
v2:
   Directly use svg in the documentation and dont generate a png since modern 
browsers can work with .svg files 
 doc/users-guide/Makefile.am |   2 +-
 doc/users-guide/users-guide-tm.adoc | 264 
 doc/users-guide/users-guide.adoc|   2 +
 include/odp/api/traffic_mngr.h  | 237 
 4 files changed, 267 insertions(+), 238 deletions(-)
 create mode 100644 doc/users-guide/users-guide-tm.adoc

diff --git a/doc/users-guide/Makefile.am b/doc/users-guide/Makefile.am
index 383894a..d3a84c6 100644
--- a/doc/users-guide/Makefile.am
+++ b/doc/users-guide/Makefile.am
@@ -4,7 +4,7 @@ EXTRA_DIST = users-guide.adoc
 
 all-local: $(TARGET)
 
-$(TARGET): users-guide.adoc
+$(TARGET): users-guide.adoc users-guide-tm.adoc
@mkdir -p $(top_srcdir)/doc/output
asciidoc -a data-uri -b html5  -a icons -a toc2  -a max-width=55em 
--out-file=$@ $<
 
diff --git a/doc/users-guide/users-guide-tm.adoc 
b/doc/users-guide/users-guide-tm.adoc
new file mode 100644
index 000..dc0d003
--- /dev/null
+++ b/doc/users-guide/users-guide-tm.adoc
@@ -0,0 +1,264 @@
+== Traffic Manager \(TM)
+
+The TM subsystem is a general packet scheduling system that accepts
+packets from input queues and applies strict priority scheduling, weighted fair
+queueing scheduling and/or bandwidth controls to decide which input packet
+should be chosen as the next output packet and when this output packet can be
+sent onwards.
+
+A given platform supporting this TM API could support one or more pure hardware
+based packet scheduling systems, one or more pure software based systems or one
+or more hybrid systems - where because of hardware constraints some of the
+packet scheduling is done in hardware and some is done in software.  In
+addition, there may also be additional API's beyond those described here for:
+
+- controlling advanced capabilities supported by specific hardware, software
+or hybrid subsystems
+- dealing with constraints and limitations of
+specific implementations.
+
+The intention here is to be the simplest API that covers the vast majority of
+packet scheduling requirements.
+
+Often a TM subsystem's output(s) will be directly connected to a device's
+physical (or virtual) output interfaces/links, in which case sometimes such a
+system will be called an Egress Packet Scheduler or an Output Link Shaper,
+etc..  While the TM subsystems configured by this API can be used in such a
+way, this API equally well supports the ability to have the TM subsystem's
+outputs connect to other TM subsystem input queues or general software queues
+or even some combination of these three cases.
+
+=== TM Algorithms
+
+The packet scheduling/dropping techniques that can be applied to input
+traffic include any mixture of the following:
+
+- Strict Priority scheduling.
+- Weighted Fair Queueing scheduling (WFQ).
+- Bandwidth Shaping.
+- Weighted Random Early Discard (WRED).
+
+Note that Bandwidth Shaping is the only feature that can cause packets to be
+"delayed", and Weighted Random Early Discard is the only feature (other than
+input queues becoming full) that can cause packets to be dropped.
+
+ Strict Priority Scheduling
+
+Strict Priority Scheduling (or just priority for short), is a technique where 
input
+queues and the packets from them, are assigned a priority value in the range 0
+.. ODP_TM_MAX_PRIORITIES - 1.  At all times packets the the smallest priority
+value will be chosen ahead of packets with a numerically larger priority value.
+This is called strict priority scheduling because the algorithm strictly
+enforces the scheduling of higher priority packets over lower priority
+packets.
+
+ Bandwidth Shaping
+
+Bandwidth Shaping (or often just Shaping) is the term used here for the idea of
+controlling packet rates using single rate and/or dual rate token bucket
+algorithms.  For single rate shaping a rate (the commit rate) and a "burst
+size" (the maximum commit count) are configured.  Then an internal signed
+integer counter called the _commitCnt_ is maintained such that if the 
_commitCnt_
+is positive then packets are eligible to be sent. When such a packet is
+actually sent then its _commitCnt_ is decremented (usually by its length, but 
one
+could decrement by 1 for each packet instead).  The _commitCnt_ is then
+incremented periodically based upon the configured rate, so that this technique
+causes the traffic to be limited to the commit rate over the long term, while
+allowing some ability to exceed this rate for a very short time (based on the
+burst size) in order to catch up if the traffic input temporarily drops below
+the commit rate.
+
+Dual Rate Shaping is designed to allow  certain traffic flows to fairly send
+more than their assigned commit rate when the  scheduler has excess capacity.
+The idea being that it may be better to allow some types of traffic to send
+more than 

Re: [lng-odp] Driver interface definition...

[Mike Holmes]

Anders, Christophe and I had a discussion and here are some very rough
notes on what I think settled out of it.

Requirements:
We wanted something that scales if more interfaces to ODP are defined and
openStack was suggested as the sort of east/west that may occur
We want the actual driver implementations to be externally developed and
use the odp_driver interface, but not be part of the odp reference repo,
they will be in their own repo and are a lot like regular applications in
how they relate to the api.
Applications use drivers and odp platforms as needed, thus at a top level
in the diagram there are three entities, with the application attaching the
drivers it wants.
The tree should make sense in its ordering of includes,  with a higher
level including from below generally and not bouncing up and down with ../
 etc
We would like different entry points to help debugging, for example in a
log to be able to distinguish a driver dma operation from an application
dma operation even though the implementation will be identical on that
platform.
We would like to be able to alter the interfaces independently for the same
basic concept - maybe dma in once case needs different semantics to the
other, who knows what we may find.

.
├── odp_drivers
│   ├── my_nic1
│   │   └── my_code.c
│   └── my_nic2
│   └── my_code.c
├── my_application
│   └── my_code.c
└── odp
├── include
│   ├── odp
│   │   ├── api
│   │   └── driver
│   ├── odp_driver.h
│   └── odp.h
└── platform
└── linux-generic
└── include
├── api
│   ├── plat
│   └── shared_memory.h
└── driver
└── shared_memory.h

The discussion ended up suggest changing to creating facades, one for each
of the different interfaces to a ODP Platform.
So in  odp_driver.h and in odp.h  you may have two facades for the same
common code in the platform for say dma access. These two facades can have
a different prefix to the same code :-  odp_dma for applications (north
bound) and odpd_dma for drivers (south bound) and they end up reusing the
same .c file and function implementation.

We had open questions:
1. Do we need the odp_driver to have something down under platform to make
this work ?
2. How do we solve the includes - note that in the diagram under
linux-generic/include we renamed odp to api for symmetry in discussion,
that is not how it is currently.





On 11 January 2016 at 12:30, Christophe Milard  wrote:

> Hi,
>
>
>
> Today the situation as I see it, is as follows:
>
> We have a single interface to ODP, the application interface, A.
>
> This interface is defined by a file which any application includes:
> include/odp.h
>
>
>  includes in turn a set of
> platform//include/odp/.
> These files are given a chance to define platform specific types by
>
> including platform//include/odp/plat/.h, do their
>
> own definitions (such as inlines functions) and finishes by including
>
> /odp/include/odp/api/, which will mainly have for effect to
> check
> that the platform definitions do match the generic api definition.
>
>
>
> With the driver interface being defined, we are about to add another
> interface
> D (D as driver).
>
> It seems that some of you would like to have a /odp/include/odp/D
> directory
> which would contains driver specific , e.g. dma.h.
>
> While I understand the wish to keep interface separated, I am not conviced
>
> that this really fits the job...:
>
> How does this new directory work?.
>
> an include file, called D.h (at the same level as odp.h, it seems we could
>
>  agree here) would include what from the platform?
>
> platform//include/D/? which in turn would include:
>
> platform//include/D/plat/.h and finally
> /odp/include/odp/api_D/?
> OK. that works. maybe complicated but does work. But more to the point:
> what
> is the criteria for the modules to be in the A (normal appli api) or D
> directory?
> D directories would contain any module just included by the D interface
>
> whereas A directories woud contain modules either part of A and D or A
> only?
> This overlap is where I see the main issue: What if an X interface has to
> be
> created in the future (Petri named open stack as an exemple), and Y and Z?
>
> All partly overlapping... What will be the criteria to place the different
>
> modules (m.h) in the A, D,X, Y or Z directories? I cannot see that growing
> well...
> Also the function prefix would get messy: should a function used in the A
> and D
>  and Y interface be called A_f(), D_f(), Y_f() or ADY_f()? and change name
> when Z comes?
>
>
> The other approach (chosen by the patch serie, but actually not fully
>
> implemented there) is different:
>
> platform//include/odp/*
>
> platform//include/odp/plat/.h
>
> and /odp/include/odp/api/ (which we should rename EPI (instead
> of API)
> maybe, for External Programing Interface) would define all functions
> exported
> 

Re: [lng-odp] [PATCHv8] helper : Fix UDP checksum computation

[Ilya Maximets]

On 04.01.2016 15:48, ion.grig...@freescale.com wrote:
> From: Grigore Ion 
> 
> This patch fixes the following problems:
> - checksum computation for LE platforms
> - checksum computation for packets having the UDP length not a
> multiple of 2
> - checksum computation in the test and the example applications
> 
> Signed-off-by: Grigore Ion 
> ---
> v8:
> - Checksum in BE endianness (Ilya Maximets)
> v7:
> - Make code simpler and more understandable as it was
> sugessted by Ilya Maximets
> v6:
> - Make code more understandable. Not done as it was
> sugessted by Ilya Maximets.
> v5:
> - Checksum in CPU endianness fix added (Ilya Maximets)
> v4:
> - Verify checksum in CPU endianness in the associated test
> (Ilya Maximets)
> v3:
> - fix the UDP checksum computation in the associated test
> (Maxim Uvarov)
> v2:
> - patch updated to the last master (Maxim Uvarov)
> v1:
> - Move variables declaration on top of block. (Maxim Uvarov)
> - Check patch with checkpatch script.  (Maxim Uvarov)
> - L3 header presence is tested twice. (Alexandru Badicioiu)
> - Remove unnecessary check for L3 header presence. (Bill Fischofer)
> 
>  example/generator/odp_generator.c |  2 +-
>  helper/include/odp/helper/udp.h   | 65 
> ---
>  helper/test/odp_chksum.c  |  4 +--
>  test/validation/pktio/pktio.c |  2 +-
>  4 files changed, 37 insertions(+), 36 deletions(-)
> 
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index cdbc761..757dc54 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -242,7 +242,7 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
>   udp->dst_port = 0;
>   udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
>   udp->chksum = 0;
> - udp->chksum = odp_cpu_to_be_16(odph_ipv4_udp_chksum(pkt));
> + udp->chksum = odph_ipv4_udp_chksum(pkt);
>  
>   return pkt;
>  }
> diff --git a/helper/include/odp/helper/udp.h b/helper/include/odp/helper/udp.h
> index 06c439b..afdb4fc 100644
> --- a/helper/include/odp/helper/udp.h
> +++ b/helper/include/odp/helper/udp.h
> @@ -4,7 +4,6 @@
>   * SPDX-License-Identifier: BSD-3-Clause
>   */
>  
> -
>  /**
>   * @file
>   *
> @@ -22,7 +21,6 @@ extern "C" {
>  #include 
>  #include 
>  
> -
>  /** @addtogroup odph_header ODPH HEADER
>   *  @{
>   */
> @@ -44,46 +42,49 @@ typedef struct ODP_PACKED {
>   * This function uses odp packet to calc checksum
>   *
>   * @param pkt  calculate chksum for pkt
> - * @return  checksum value
> + * @return  checksum value in BE endianness
>   */
>  static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
>  {
> - uint32_t sum = 0;
> - odph_udphdr_t *udph;
> - odph_ipv4hdr_t *iph;
> - uint16_t udplen;
> - uint8_t *buf;
> -
> - if (!odp_packet_l3_offset(pkt))
> + odph_ipv4hdr_t  *iph;
> + odph_udphdr_t   *udph;
> + uint32_tsum;
> + uint16_tudplen, *buf;
> + union {
> + uint8_t v8[2];
> + uint16_t v16;
> + } val;
> +
> + if (odp_packet_l4_offset(pkt) == ODP_PACKET_OFFSET_INVALID)
>   return 0;
> -
> - if (!odp_packet_l4_offset(pkt))
> - return 0;
> -
>   iph = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
>   udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
> - udplen = odp_be_to_cpu_16(udph->length);
> -
> - /* 32-bit sum of all 16-bit words covered by UDP chksum */
> + /* 32-bit sum of UDP pseudo-header */

I think, it should be specified, that it's a sum of 16-bit words.

>   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
> -   (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> -   (uint16_t)iph->proto + udplen;
> - for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
> - sum += ((*buf << 8) + *(buf + 1));
> - buf += 2;
> + (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> + udph->length;
> + val.v8[0] = 0;
> + val.v8[1] = iph->proto;
> + sum += val.v16;
> + /* 32-bit sum of UDP header (checksum field cleared) and UDP data */

Same here.

> + udplen = odp_be_to_cpu_16(udph->length);
> + buf = (uint16_t *)((void *)udph);
> + for ( ; udplen > 1; udplen -= 2)
> + sum += *buf++;
> + /* Length is not a multiple of 2 bytes */
> + if (udplen) {
> + val.v8[0] = *buf;
> + val.v8[1] = 0;
> + sum += val.v16;
>   }
> -
> - /* Fold sum to 16 bits: add carrier to result */
> - while (sum >> 16)
> - sum = (sum & 0x) + (sum >> 16);
> -
> + /* Fold sum to 16 bits */
> + sum = (sum & 0x) + (sum >> 16);
> + /* Add carrier (0/1) to result */
> + sum += (sum >> 16);
>   /* 1's complement */
>   sum = ~sum;
> -
> - /* set computation result */
> - 

Re: [lng-odp] [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor

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

Since it's a driver interface file, it should be placed into new folder:

odp/include/odp/driver/dma.h

Under "driver" (or similar) and next to odp/include/odp/api (not under api).


-Petri




> -Original Message-
> From: EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Friday, January 08, 2016 10:30 PM
> To: anders.rox...@linaro.org; mike.hol...@linaro.org;
> stuart.has...@linaro.org; maxim.uva...@linaro.org;
> bill.fischo...@linaro.org; petri.savolai...@linaro.org;
> eda...@broadcom.com
> Cc: lng-odp@lists.linaro.org; Christophe Milard
> Subject: [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor
> 
> A DMA region descriptor is an object defining a contiguous DMA region.
> DMA descriptors can be chained to describe scattered regions.
> (The DMA mapping function itself will be defined as a PCI function,
> as the DMA is a PCI device)
> Note that this file is not included in include/odp.h as it does not belong
> to the ODP-application interface.
> 
> Signed-off-by: Christophe Milard 
> ---
>  include/odp/api/dma.h | 102
> ++
>  1 file changed, 102 insertions(+)
>  create mode 100644 include/odp/api/dma.h
> 
> diff --git a/include/odp/api/dma.h b/include/odp/api/dma.h
> new file mode 100644
> index 000..2cabcec
> --- /dev/null
> +++ b/include/odp/api/dma.h
> @@ -0,0 +1,102 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * DMA descriptor and related operations.
> + */
> +
> +#ifndef ODP_API_DMA_H_
> +#define ODP_API_DMA_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** @defgroup odp_dma DMA
> + *  @{
> + */
> +
> +/**
> + * @typedef odp_dma_addr_t
> + * DMA address (iether physical or iova)
> + */
> +
> +/**
> + * @typedef odp_dma_map_t
> + * DMA map region descriptor
> + * DMA map region descriptors are returned by ODP (on request) and
> describe
> + * how a DMA mapping should be done to access a given resource
> + * (sucha as a packet pool or a memory area).
> + * If needed (i.e. if the DMA region is scattered), the returned region
> can
> + * link to others (odp_dma_map_get_next() then returns valid region(s)),
> hence
> + * allowing a scattered region to be described.
> + * Regions descriptor are used to request DMA mapping for NIC devices.
> + * Region descriptors must be released using odp_dma_map_free().
> + */
> +
> +/**
> + * @def ODP_DMA_REG_INVALID
> + * Invalid DMA region
> + */
> +
> +/* operations on DMA maps: */
> +
> +/**
> + * Get the DMA region user address.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval the virtual userland address for the region
> + */
> +void *odp_dma_map_get_addr(odp_dma_map_t map);
> +
> +/**
> + * Get the DMA region DMA address.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval the DMA address (i.e. physical or iova) for the region
> + */
> +odp_dma_addr_t odp_dma_map_get_dma_addr(odp_dma_map_t map);
> +
> +/**
> + * Get the DMA region size.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval size (in bytes) for the region
> + */
> +int odp_dma_map_get_size(odp_dma_map_t map);
> +
> +/**
> + * Get the following region (if any).
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval a DMA region descriptor describing the next fragment
> + * (if any) of a scattered region. Returns ODP_DMA_REG_INVALID if none.
> + */
> +odp_dma_map_t odp_dma_map_get_next(odp_dma_map_t map);
> +
> +/**
> + * Free a region descriptor. The region must be unmapped first.
> + *
> + * @param an unmapped ODP DMA region descriptor
> + *
> + */
> +void odp_dma_map_free(odp_dma_map_t map);
> +
> +/**
> + * @}
> + */
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* ODP_API_DMA_H_ */
> --
> 2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv9] helper : Fix UDP checksum computation

[ion.grigore]

From: Grigore Ion 

This patch fixes the following problems:
- checksum computation for LE platforms
- checksum computation for packets having the UDP length not a
multiple of 2
- checksum computation in the test and the example applications

Signed-off-by: Grigore Ion 
---
v9:
- Fix comments (Ilya Maximets)
v8:
- Checksum in BE endianness (Ilya Maximets)
v7:
- Make code simpler and more understandable as it was
sugessted by Ilya Maximets
v6:
- Make code more understandable. Not done as it was
sugessted by Ilya Maximets.
v5:
- Checksum in CPU endianness fix added (Ilya Maximets)
v4:
- Verify checksum in CPU endianness in the associated test
(Ilya Maximets)
v3:
- fix the UDP checksum computation in the associated test
(Maxim Uvarov)
v2:
- patch updated to the last master (Maxim Uvarov)
v1:
- Move variables declaration on top of block. (Maxim Uvarov)
- Check patch with checkpatch script.  (Maxim Uvarov)
- L3 header presence is tested twice. (Alexandru Badicioiu)
- Remove unnecessary check for L3 header presence. (Bill Fischofer)

 example/generator/odp_generator.c |  2 +-
 helper/include/odp/helper/udp.h   | 66 ---
 helper/test/odp_chksum.c  |  4 +--
 test/validation/pktio/pktio.c |  2 +-
 4 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index cdbc761..757dc54 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -242,7 +242,7 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
udp->dst_port = 0;
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odp_cpu_to_be_16(odph_ipv4_udp_chksum(pkt));
+   udp->chksum = odph_ipv4_udp_chksum(pkt);
 
return pkt;
 }
diff --git a/helper/include/odp/helper/udp.h b/helper/include/odp/helper/udp.h
index 06c439b..93b342d 100644
--- a/helper/include/odp/helper/udp.h
+++ b/helper/include/odp/helper/udp.h
@@ -4,7 +4,6 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-
 /**
  * @file
  *
@@ -22,7 +21,6 @@ extern "C" {
 #include 
 #include 
 
-
 /** @addtogroup odph_header ODPH HEADER
  *  @{
  */
@@ -44,46 +42,50 @@ typedef struct ODP_PACKED {
  * This function uses odp packet to calc checksum
  *
  * @param pkt  calculate chksum for pkt
- * @return  checksum value
+ * @return  checksum value in BE endianness
  */
 static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
 {
-   uint32_t sum = 0;
-   odph_udphdr_t *udph;
-   odph_ipv4hdr_t *iph;
-   uint16_t udplen;
-   uint8_t *buf;
-
-   if (!odp_packet_l3_offset(pkt))
+   odph_ipv4hdr_t  *iph;
+   odph_udphdr_t   *udph;
+   uint32_tsum;
+   uint16_tudplen, *buf;
+   union {
+   uint8_t v8[2];
+   uint16_t v16;
+   } val;
+
+   if (odp_packet_l4_offset(pkt) == ODP_PACKET_OFFSET_INVALID)
return 0;
-
-   if (!odp_packet_l4_offset(pkt))
-   return 0;
-
iph = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
-   udplen = odp_be_to_cpu_16(udph->length);
-
-   /* 32-bit sum of all 16-bit words covered by UDP chksum */
+   /* 32-bit sum of UDP pseudo-header, seen as a series of 16-bit words */
sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
- (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
- (uint16_t)iph->proto + udplen;
-   for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
-   sum += ((*buf << 8) + *(buf + 1));
-   buf += 2;
+   (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
+   udph->length;
+   val.v8[0] = 0;
+   val.v8[1] = iph->proto;
+   sum += val.v16;
+   /* 32-bit sum of UDP header (checksum field cleared) and UDP data, seen
+* as a series of 16-bit words */
+   udplen = odp_be_to_cpu_16(udph->length);
+   buf = (uint16_t *)((void *)udph);
+   for ( ; udplen > 1; udplen -= 2)
+   sum += *buf++;
+   /* Length is not a multiple of 2 bytes */
+   if (udplen) {
+   val.v8[0] = *buf;
+   val.v8[1] = 0;
+   sum += val.v16;
}
-
-   /* Fold sum to 16 bits: add carrier to result */
-   while (sum >> 16)
-   sum = (sum & 0x) + (sum >> 16);
-
+   /* Fold sum to 16 bits */
+   sum = (sum & 0x) + (sum >> 16);
+   /* Add carrier (0/1) to result */
+   sum += (sum >> 16);
/* 1's complement */
sum = ~sum;
-
-   /* set computation result */
-   sum = (sum == 0x0) ? 0x : sum;
-
-   return sum;
+   /* Return checksum in BE endianness */
+   return (sum == 0x0) ? 0x : sum;
 }
 
 /** @internal Compile time assert */

Re: [lng-odp] [PATCHv8] helper : Fix UDP checksum computation

[Ion Grigore]

Done

-Original Message-
From: Ilya Maximets [mailto:i.maxim...@samsung.com] 
Sent: Monday, January 11, 2016 10:14 AM
To: ion.grig...@freescale.com; lng-odp@lists.linaro.org
Cc: Maxim Uvarov 
Subject: Re: [PATCHv8] helper : Fix UDP checksum computation

On 04.01.2016 15:48, ion.grig...@freescale.com wrote:
> From: Grigore Ion 
> 
> This patch fixes the following problems:
> - checksum computation for LE platforms
> - checksum computation for packets having the UDP length not a 
> multiple of 2
> - checksum computation in the test and the example applications
> 
> Signed-off-by: Grigore Ion 
> ---
> v8:
> - Checksum in BE endianness (Ilya Maximets)
> v7:
> - Make code simpler and more understandable as it was sugessted by 
> Ilya Maximets
> v6:
> - Make code more understandable. Not done as it was sugessted by Ilya 
> Maximets.
> v5:
> - Checksum in CPU endianness fix added (Ilya Maximets)
> v4:
> - Verify checksum in CPU endianness in the associated test (Ilya 
> Maximets)
> v3:
> - fix the UDP checksum computation in the associated test (Maxim 
> Uvarov)
> v2:
> - patch updated to the last master (Maxim Uvarov)
> v1:
> - Move variables declaration on top of block. (Maxim Uvarov)
> - Check patch with checkpatch script.  (Maxim Uvarov)
> - L3 header presence is tested twice. (Alexandru Badicioiu)
> - Remove unnecessary check for L3 header presence. (Bill Fischofer)
> 
>  example/generator/odp_generator.c |  2 +-
>  helper/include/odp/helper/udp.h   | 65 
> ---
>  helper/test/odp_chksum.c  |  4 +--
>  test/validation/pktio/pktio.c |  2 +-
>  4 files changed, 37 insertions(+), 36 deletions(-)
> 
> diff --git a/example/generator/odp_generator.c 
> b/example/generator/odp_generator.c
> index cdbc761..757dc54 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -242,7 +242,7 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
>   udp->dst_port = 0;
>   udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
>   udp->chksum = 0;
> - udp->chksum = odp_cpu_to_be_16(odph_ipv4_udp_chksum(pkt));
> + udp->chksum = odph_ipv4_udp_chksum(pkt);
>  
>   return pkt;
>  }
> diff --git a/helper/include/odp/helper/udp.h 
> b/helper/include/odp/helper/udp.h index 06c439b..afdb4fc 100644
> --- a/helper/include/odp/helper/udp.h
> +++ b/helper/include/odp/helper/udp.h
> @@ -4,7 +4,6 @@
>   * SPDX-License-Identifier: BSD-3-Clause
>   */
>  
> -
>  /**
>   * @file
>   *
> @@ -22,7 +21,6 @@ extern "C" {
>  #include 
>  #include 
>  
> -
>  /** @addtogroup odph_header ODPH HEADER
>   *  @{
>   */
> @@ -44,46 +42,49 @@ typedef struct ODP_PACKED {
>   * This function uses odp packet to calc checksum
>   *
>   * @param pkt  calculate chksum for pkt
> - * @return  checksum value
> + * @return  checksum value in BE endianness
>   */
>  static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)  {
> - uint32_t sum = 0;
> - odph_udphdr_t *udph;
> - odph_ipv4hdr_t *iph;
> - uint16_t udplen;
> - uint8_t *buf;
> -
> - if (!odp_packet_l3_offset(pkt))
> + odph_ipv4hdr_t  *iph;
> + odph_udphdr_t   *udph;
> + uint32_tsum;
> + uint16_tudplen, *buf;
> + union {
> + uint8_t v8[2];
> + uint16_t v16;
> + } val;
> +
> + if (odp_packet_l4_offset(pkt) == ODP_PACKET_OFFSET_INVALID)
>   return 0;
> -
> - if (!odp_packet_l4_offset(pkt))
> - return 0;
> -
>   iph = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
>   udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
> - udplen = odp_be_to_cpu_16(udph->length);
> -
> - /* 32-bit sum of all 16-bit words covered by UDP chksum */
> + /* 32-bit sum of UDP pseudo-header */

I think, it should be specified, that it's a sum of 16-bit words.

>   sum = (iph->src_addr & 0x) + (iph->src_addr >> 16) +
> -   (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> -   (uint16_t)iph->proto + udplen;
> - for (buf = (uint8_t *)udph; udplen > 1; udplen -= 2) {
> - sum += ((*buf << 8) + *(buf + 1));
> - buf += 2;
> + (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> + udph->length;
> + val.v8[0] = 0;
> + val.v8[1] = iph->proto;
> + sum += val.v16;
> + /* 32-bit sum of UDP header (checksum field cleared) and UDP data */

Same here.

> + udplen = odp_be_to_cpu_16(udph->length);
> + buf = (uint16_t *)((void *)udph);
> + for ( ; udplen > 1; udplen -= 2)
> + sum += *buf++;
> + /* Length is not a multiple of 2 bytes */
> + if (udplen) {
> + val.v8[0] = *buf;
> + val.v8[1] = 0;
> + sum += val.v16;
>   }
> -
> - /* Fold sum to 16 bits: add carrier to result */
> - while (sum >> 16)
> -   

Re: [lng-odp] [API-NEXT RFC 02/31] api: introducing the driver api definition file

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

CC’d the list again.


From: EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
Sent: Monday, January 11, 2016 10:29 AM
To: Savolainen, Petri (Nokia - FI/Espoo)
Subject: Re: [API-NEXT RFC 02/31] api: introducing the driver api definition 
file


On 11 January 2016 at 09:12, Savolainen, Petri (Nokia - FI/Espoo) 
> wrote:


> -Original Message-
> From: EXT Christophe Milard 
> [mailto:christophe.mil...@linaro.org]
> Sent: Friday, January 08, 2016 10:30 PM
> To: anders.rox...@linaro.org; 
> mike.hol...@linaro.org;
> stuart.has...@linaro.org; 
> maxim.uva...@linaro.org;
> bill.fischo...@linaro.org; 
> petri.savolai...@linaro.org;
> eda...@broadcom.com
> Cc: lng-odp@lists.linaro.org; Christophe 
> Milard
> Subject: [API-NEXT RFC 02/31] api: introducing the driver api definition
> file
>
> include/odp.h defines the ODP-application API (as before).
> include/odp_driver.h defines the new driver API.
> Note that the two APIs (application API and driver API) are partly
> overlapping: Some files such as byteorder.h, sync.h, hints.h... needs
> obviously to be part of both APIs.
>
> Signed-off-by: Christophe Milard 
> >
> ---
>  include/odp.h|  2 +-
>  include/odp_driver.h | 34 ++
>  2 files changed, 35 insertions(+), 1 deletion(-)
>  create mode 100644 include/odp_driver.h
>
> diff --git a/include/odp.h b/include/odp.h
> index 4a93c23..1c880df 100644
> --- a/include/odp.h
> +++ b/include/odp.h
> @@ -7,7 +7,7 @@
>  /**
>   * @file
>   *
> - * The OpenDataPlane API
> + * The OpenDataPlane API to applications

This addition is not needed, since API ("Application Programming Interface") 
should be always defined for applications.

OK




>   *
>   */
>
> diff --git a/include/odp_driver.h b/include/odp_driver.h
> new file mode 100644
> index 000..b59f7df
> --- /dev/null
> +++ b/include/odp_driver.h
> @@ -0,0 +1,34 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * The OpenDataPlane API to NIC drivers


To keep it simple, ODP API should always point towards applications. This can 
be named e.g. "ODP Driver Interface" (ODP-DI ?). It's an interface to connect 
drivers to ODP implementations, not an interface to develop applications (that 
are NIC drivers, etc).

All driver interface data types and calls should be also prefixed with odpdrv_, 
odpd_, odpdi_ or something similar (other than odp_), so that it's clear which 
definitions belong to the API and which to the driver interface.

That was my original intemtion, but how would you then handle the overlaping 
situation of these programming interfaces? shmem, byte order, barriers, locks, 
hints ... Many API things (according to your terminology) would also be part of 
the DI...  Would you then alias all these functions...?


If driver interface needs some definitions from API side, then we include those 
from the API (and maintain those in sync with API) . New / additional 
definitions are prefixed with e.g. odpdi_. Driver API can consist of a bunch of 
odp_ defientions (re-used from API side) and odpdi_ definitions (only for 
drivers). Driver interface may have its own version numbering. An API change in 
those reused calls/definitions would also bump the driver interface version. We 
should select carefully which definitions and calls are really needed (or are 
useful) on driver side and include only those, which means that some of the 
headers (mentioned under) may need to be split into  API only vs. API + DI 
parts.


Pseudo code for odp/include/odp/driver/odp_driver.h

#include 
#include 
#include < api/byteorder.h>
#include 
#include 
#include 
#include 

#include 
#include 
#include 
…


-Petri




-Petri


> + *
> + */
> +
> +#ifndef ODP_DRIVER_H_
> +#define ODP_DRIVER_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /*ODP_DRIVER_H_*/
> --
> 2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor

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

Addition of driver interface should have minimal impact into API (it’s just 
another way to connect pktio into HW). E.g. application should not configure 
DMA directly, but maybe provide additional information through pktio or pool 
parameters (which can be useful to integrated pktio devices in SoCs also).

-Petri


From: EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
Sent: Monday, January 11, 2016 10:51 AM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: anders.rox...@linaro.org; mike.hol...@linaro.org; stuart.has...@linaro.org; 
maxim.uva...@linaro.org; bill.fischo...@linaro.org; eda...@broadcom.com; 
lng-odp@lists.linaro.org
Subject: Re: [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor

Then I have a issue about the overlapping part of the API / DPI...  Shall we 
have two names for each of these symbols?  The approach taken here avoided 
that, at least.
Mike has added an item to the ARCH call this afternoon... We can take that there
Thx,

Christophe.

On 11 January 2016 at 09:22, Savolainen, Petri (Nokia - FI/Espoo) 
> wrote:
Since it's a driver interface file, it should be placed into new folder:

odp/include/odp/driver/dma.h

Under "driver" (or similar) and next to odp/include/odp/api (not under api).


-Petri




> -Original Message-
> From: EXT Christophe Milard 
> [mailto:christophe.mil...@linaro.org]
> Sent: Friday, January 08, 2016 10:30 PM
> To: anders.rox...@linaro.org; 
> mike.hol...@linaro.org;
> stuart.has...@linaro.org; 
> maxim.uva...@linaro.org;
> bill.fischo...@linaro.org; 
> petri.savolai...@linaro.org;
> eda...@broadcom.com
> Cc: lng-odp@lists.linaro.org; Christophe 
> Milard
> Subject: [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor
>
> A DMA region descriptor is an object defining a contiguous DMA region.
> DMA descriptors can be chained to describe scattered regions.
> (The DMA mapping function itself will be defined as a PCI function,
> as the DMA is a PCI device)
> Note that this file is not included in include/odp.h as it does not belong
> to the ODP-application interface.
>
> Signed-off-by: Christophe Milard 
> >
> ---
>  include/odp/api/dma.h | 102
> ++
>  1 file changed, 102 insertions(+)
>  create mode 100644 include/odp/api/dma.h
>
> diff --git a/include/odp/api/dma.h b/include/odp/api/dma.h
> new file mode 100644
> index 000..2cabcec
> --- /dev/null
> +++ b/include/odp/api/dma.h
> @@ -0,0 +1,102 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * DMA descriptor and related operations.
> + */
> +
> +#ifndef ODP_API_DMA_H_
> +#define ODP_API_DMA_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** @defgroup odp_dma DMA
> + *  @{
> + */
> +
> +/**
> + * @typedef odp_dma_addr_t
> + * DMA address (iether physical or iova)
> + */
> +
> +/**
> + * @typedef odp_dma_map_t
> + * DMA map region descriptor
> + * DMA map region descriptors are returned by ODP (on request) and
> describe
> + * how a DMA mapping should be done to access a given resource
> + * (sucha as a packet pool or a memory area).
> + * If needed (i.e. if the DMA region is scattered), the returned region
> can
> + * link to others (odp_dma_map_get_next() then returns valid region(s)),
> hence
> + * allowing a scattered region to be described.
> + * Regions descriptor are used to request DMA mapping for NIC devices.
> + * Region descriptors must be released using odp_dma_map_free().
> + */
> +
> +/**
> + * @def ODP_DMA_REG_INVALID
> + * Invalid DMA region
> + */
> +
> +/* operations on DMA maps: */
> +
> +/**
> + * Get the DMA region user address.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval the virtual userland address for the region
> + */
> +void *odp_dma_map_get_addr(odp_dma_map_t map);
> +
> +/**
> + * Get the DMA region DMA address.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval the DMA address (i.e. physical or iova) for the region
> + */
> +odp_dma_addr_t odp_dma_map_get_dma_addr(odp_dma_map_t map);
> +
> +/**
> + * Get the DMA region size.
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval size (in bytes) for the region
> + */
> +int odp_dma_map_get_size(odp_dma_map_t map);
> +
> +/**
> + * Get the following region (if any).
> + *
> + * @param an ODP DMA region descriptor
> + *
> + * @retval a DMA region descriptor describing the next fragment
> + * (if any) of a scattered region. Returns 

[lng-odp] [PATCH v3 0/3] correct limits validation

[Ivan Khoronzhuk]

This series corrects limits based on resolution.

Since v2:
- remove return

Since v1:
- no functional changes
- replaceed "[lng-odp] [PATCH 1/3] validation: time: initialize resolution vars"
  on "validation: time: store local and global resolution" from Nicolas

Ivan Khoronzhuk (2):
  validation: time: round up resolution
  validation: time: increase limit to check to 2 res

Nicolas Morey-Chaisemartin (1):
  validation: time: store local and global resolution

 test/validation/time/time.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH v3 1/3] validation: time: store local and global resolution

[Ivan Khoronzhuk]

From: Nicolas Morey-Chaisemartin 

Computation were done on a local variable and never stored back
to the global value so both local_res and global_res were always 0.

Reviewed-by: Ivan Khoronzhuk 
Signed-off-by: Ivan Khoronzhuk 
Signed-off-by: Nicolas Morey-Chaisemartin 
---
 test/validation/time/time.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/validation/time/time.c b/test/validation/time/time.c
index 8b469b0..b4e53ec 100644
--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -31,7 +31,7 @@ void time_test_constants(void)
CU_ASSERT(ns == ODP_TIME_USEC_IN_NS);
 }
 
-static void time_test_res(time_res_cb time_res, uint64_t res)
+static void time_test_res(time_res_cb time_res, uint64_t *res)
 {
uint64_t rate;
 
@@ -39,18 +39,18 @@ static void time_test_res(time_res_cb time_res, uint64_t 
res)
CU_ASSERT(rate > MIN_TIME_RATE);
CU_ASSERT(rate < MAX_TIME_RATE);
 
-   res = ODP_TIME_SEC_IN_NS / rate;
-   res = res ? res : 1;
+   *res = ODP_TIME_SEC_IN_NS / rate;
+   *res = *res ? *res : 1;
 }
 
 void time_test_local_res(void)
 {
-   time_test_res(odp_time_local_res, local_res);
+   time_test_res(odp_time_local_res, _res);
 }
 
 void time_test_global_res(void)
 {
-   time_test_res(odp_time_global_res, global_res);
+   time_test_res(odp_time_global_res, _res);
 }
 
 /* check that related conversions come back to the same value */
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH v3 2/3] validation: time: round up resolution

[Ivan Khoronzhuk]

While division the resolution can have fractional part, so better to
round it up, when it's needed.

Reviewed-by: Bill Fischofer 
Signed-off-by: Ivan Khoronzhuk 
---
 test/validation/time/time.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/test/validation/time/time.c b/test/validation/time/time.c
index b4e53ec..d0d198a 100644
--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -40,7 +40,8 @@ static void time_test_res(time_res_cb time_res, uint64_t *res)
CU_ASSERT(rate < MAX_TIME_RATE);
 
*res = ODP_TIME_SEC_IN_NS / rate;
-   *res = *res ? *res : 1;
+   if (ODP_TIME_SEC_IN_NS % rate)
+   (*res)++;
 }
 
 void time_test_local_res(void)
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT RFC 01/31] api: dma: defining the dma region descriptor

[Christophe Milard]

Then I have a issue about the overlapping part of the API / DPI...  Shall
we have two names for each of these symbols?  The approach taken here
avoided that, at least.
Mike has added an item to the ARCH call this afternoon... We can take that
there
Thx,

Christophe.

On 11 January 2016 at 09:22, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Since it's a driver interface file, it should be placed into new folder:
>
> odp/include/odp/driver/dma.h
>
> Under "driver" (or similar) and next to odp/include/odp/api (not under
> api).
>
>
> -Petri
>
>
>
>
> > -Original Message-
> > From: EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
> > Sent: Friday, January 08, 2016 10:30 PM
> > To: anders.rox...@linaro.org; mike.hol...@linaro.org;
> > stuart.has...@linaro.org; maxim.uva...@linaro.org;
> > bill.fischo...@linaro.org; petri.savolai...@linaro.org;
> > eda...@broadcom.com
> > Cc: lng-odp@lists.linaro.org; Christophe Milard
> > Subject: [API-NEXT RFC 01/31] api: dma: defining the dma region
> descriptor
> >
> > A DMA region descriptor is an object defining a contiguous DMA region.
> > DMA descriptors can be chained to describe scattered regions.
> > (The DMA mapping function itself will be defined as a PCI function,
> > as the DMA is a PCI device)
> > Note that this file is not included in include/odp.h as it does not
> belong
> > to the ODP-application interface.
> >
> > Signed-off-by: Christophe Milard 
> > ---
> >  include/odp/api/dma.h | 102
> > ++
> >  1 file changed, 102 insertions(+)
> >  create mode 100644 include/odp/api/dma.h
> >
> > diff --git a/include/odp/api/dma.h b/include/odp/api/dma.h
> > new file mode 100644
> > index 000..2cabcec
> > --- /dev/null
> > +++ b/include/odp/api/dma.h
> > @@ -0,0 +1,102 @@
> > +/* Copyright (c) 2015, Linaro Limited
> > + * All rights reserved.
> > + *
> > + * SPDX-License-Identifier: BSD-3-Clause
> > + */
> > +
> > +/**
> > + * @file
> > + *
> > + * DMA descriptor and related operations.
> > + */
> > +
> > +#ifndef ODP_API_DMA_H_
> > +#define ODP_API_DMA_H_
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/** @defgroup odp_dma DMA
> > + *  @{
> > + */
> > +
> > +/**
> > + * @typedef odp_dma_addr_t
> > + * DMA address (iether physical or iova)
> > + */
> > +
> > +/**
> > + * @typedef odp_dma_map_t
> > + * DMA map region descriptor
> > + * DMA map region descriptors are returned by ODP (on request) and
> > describe
> > + * how a DMA mapping should be done to access a given resource
> > + * (sucha as a packet pool or a memory area).
> > + * If needed (i.e. if the DMA region is scattered), the returned region
> > can
> > + * link to others (odp_dma_map_get_next() then returns valid region(s)),
> > hence
> > + * allowing a scattered region to be described.
> > + * Regions descriptor are used to request DMA mapping for NIC devices.
> > + * Region descriptors must be released using odp_dma_map_free().
> > + */
> > +
> > +/**
> > + * @def ODP_DMA_REG_INVALID
> > + * Invalid DMA region
> > + */
> > +
> > +/* operations on DMA maps: */
> > +
> > +/**
> > + * Get the DMA region user address.
> > + *
> > + * @param an ODP DMA region descriptor
> > + *
> > + * @retval the virtual userland address for the region
> > + */
> > +void *odp_dma_map_get_addr(odp_dma_map_t map);
> > +
> > +/**
> > + * Get the DMA region DMA address.
> > + *
> > + * @param an ODP DMA region descriptor
> > + *
> > + * @retval the DMA address (i.e. physical or iova) for the region
> > + */
> > +odp_dma_addr_t odp_dma_map_get_dma_addr(odp_dma_map_t map);
> > +
> > +/**
> > + * Get the DMA region size.
> > + *
> > + * @param an ODP DMA region descriptor
> > + *
> > + * @retval size (in bytes) for the region
> > + */
> > +int odp_dma_map_get_size(odp_dma_map_t map);
> > +
> > +/**
> > + * Get the following region (if any).
> > + *
> > + * @param an ODP DMA region descriptor
> > + *
> > + * @retval a DMA region descriptor describing the next fragment
> > + * (if any) of a scattered region. Returns ODP_DMA_REG_INVALID if none.
> > + */
> > +odp_dma_map_t odp_dma_map_get_next(odp_dma_map_t map);
> > +
> > +/**
> > + * Free a region descriptor. The region must be unmapped first.
> > + *
> > + * @param an unmapped ODP DMA region descriptor
> > + *
> > + */
> > +void odp_dma_map_free(odp_dma_map_t map);
> > +
> > +/**
> > + * @}
> > + */
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* ODP_API_DMA_H_ */
> > --
> > 2.1.4
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] doc: implementers-guide: libC version

[Christophe Milard]

Limiting the usage of the C library to the functions defined in its
C99 version.

Signed-off-by: Christophe Milard 
---
 doc/implementers-guide/implementers-guide.adoc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/implementers-guide/implementers-guide.adoc 
b/doc/implementers-guide/implementers-guide.adoc
index de0b9b1..eb076cf 100644
--- a/doc/implementers-guide/implementers-guide.adoc
+++ b/doc/implementers-guide/implementers-guide.adoc
@@ -90,7 +90,9 @@ This grouping defines tests that are expected to be 
executable and succeed on
 any platform, though possibly with very different performances, depending on 
the
 underlying platform.
 They are written in plain C code, and may only use functions defined in the
-standard libC library (besides the ODP functions being tested, of course).
+standard libC (C99) library (besides the ODP functions being tested, of 
course).
+A free C99 specification can be found at
+http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf.
 No other languages (like scripting) are allowed as their usage would make
 assumptions on the platform capability.
 
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH v3 3/3] validation: time: increase limit to check to 2 res

[Ivan Khoronzhuk]

In places of two conversions the error can be up to
2 resolutions, so increase validation range to 2 res.

Reviewed-by: Bill Fischofer 
Signed-off-by: Ivan Khoronzhuk 
---
 test/validation/time/time.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/test/validation/time/time.c b/test/validation/time/time.c
index d0d198a..a64bff6 100644
--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -215,8 +215,8 @@ static void time_test_diff(time_cb time,
ns = ns2 - ns1;
nsdiff = odp_time_to_ns(diff);
 
-   upper_limit = ns + res;
-   lower_limit = ns - res;
+   upper_limit = ns + 2 * res;
+   lower_limit = ns - 2 * res;
CU_ASSERT((nsdiff <= upper_limit) && (nsdiff >= lower_limit));
 
/* test timestamp and interval diff */
@@ -228,8 +228,8 @@ static void time_test_diff(time_cb time,
CU_ASSERT(odp_time_cmp(diff, ODP_TIME_NULL) > 0);
nsdiff = odp_time_to_ns(diff);
 
-   upper_limit = ns + res;
-   lower_limit = ns - res;
+   upper_limit = ns + 2 * res;
+   lower_limit = ns - 2 * res;
CU_ASSERT((nsdiff <= upper_limit) && (nsdiff >= lower_limit));
 
/* test interval diff */
@@ -241,8 +241,8 @@ static void time_test_diff(time_cb time,
CU_ASSERT(odp_time_cmp(diff, ODP_TIME_NULL) > 0);
nsdiff = odp_time_to_ns(diff);
 
-   upper_limit = ns + res;
-   lower_limit = ns - res;
+   upper_limit = ns + 2 * res;
+   lower_limit = ns - 2 * res;
CU_ASSERT((nsdiff <= upper_limit) && (nsdiff >= lower_limit));
 
/* same time has to diff to 0 */
@@ -283,8 +283,8 @@ static void time_test_sum(time_cb time,
CU_ASSERT(odp_time_cmp(sum, ODP_TIME_NULL) > 0);
nssum = odp_time_to_ns(sum);
 
-   upper_limit = ns + res;
-   lower_limit = ns - res;
+   upper_limit = ns + 2 * res;
+   lower_limit = ns - 2 * res;
CU_ASSERT((nssum <= upper_limit) && (nssum >= lower_limit));
 
/* sum intervals */
@@ -296,8 +296,8 @@ static void time_test_sum(time_cb time,
CU_ASSERT(odp_time_cmp(sum, ODP_TIME_NULL) > 0);
nssum = odp_time_to_ns(sum);
 
-   upper_limit = ns + res;
-   lower_limit = ns - res;
+   upper_limit = ns + 2 * res;
+   lower_limit = ns - 2 * res;
CU_ASSERT((nssum <= upper_limit) && (nssum >= lower_limit));
 
/* test on 0 */
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] pool:support to create pool on user's own memory

[Zaibo Xu]

As user initiates pool params with its own memory reserving and un-reserving 
functions,
pool will be created on its own memory, or on odp share memory as before.

Signed-off-by: Zaibo Xu 
---
 include/odp/api/pool.h| 12 
 platform/linux-generic/odp_pool.c | 34 +-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
index 2e79a55..fce0592 100644
--- a/include/odp/api/pool.h
+++ b/include/odp/api/pool.h
@@ -40,6 +40,12 @@ extern "C" {
 /** Maximum queue name length in chars */
 #define ODP_POOL_NAME_LEN  32
 
+/** For user's memory reserve function */
+typedef void* (*odp_usr_resv_mem_t)(uint32_t len);
+
+/** For user's memory un-reserve function */
+typedef int (*odp_usr_unresv_mem_t)(void *addr);
+
 /**
  * Pool parameters
  * Used to communicate pool creation options.
@@ -48,6 +54,12 @@ typedef struct odp_pool_param_t {
/** Pool type */
int type;
 
+   /** Odp pool can be created on user's own memory.
+   there are memory reserve and un-reserve
+   functions of user. */
+   odp_usr_resv_mem_t resv_mem_fn;
+   odp_usr_unresv_mem_t unresv_mem_fn;
+
union {
struct {
/** Number of buffers in the pool */
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index 84d35bf..eb8b153 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -295,15 +295,27 @@ odp_pool_t odp_pool_create(const char *name, 
odp_pool_param_t *params)
  mdata_size +
  udata_size);
 
-   shm = odp_shm_reserve(pool->s.name,
- pool->s.pool_size,
- ODP_PAGE_SIZE, 0);
-   if (shm == ODP_SHM_INVALID) {
-   POOL_UNLOCK(>s.lock);
-   return ODP_POOL_INVALID;
+   if (pool->s.params.resv_mem_fn != NULL) {
+   void *addr = pool->s.params.resv_mem_fn(
+   (uint32_t)pool->s.pool_size);
+
+   if (addr == NULL) {
+   POOL_UNLOCK(>s.lock);
+   return ODP_POOL_INVALID;
+   }
+   pool->s.pool_base_addr = (uint8_t *)addr;
+   pool->s.pool_shm = (odp_shm_t)!ODP_SHM_INVALID;
+   } else {
+   shm = odp_shm_reserve(pool->s.name,
+ pool->s.pool_size,
+ ODP_PAGE_SIZE, 0);
+   if (shm == ODP_SHM_INVALID) {
+   POOL_UNLOCK(>s.lock);
+   return ODP_POOL_INVALID;
+   }
+   pool->s.pool_base_addr = odp_shm_addr(shm);
+   pool->s.pool_shm = shm;
}
-   pool->s.pool_base_addr = odp_shm_addr(shm);
-   pool->s.pool_shm = shm;
 
/* Now safe to unlock since pool entry has been allocated */
POOL_UNLOCK(>s.lock);
@@ -473,7 +485,11 @@ int odp_pool_destroy(odp_pool_t pool_hdl)
return -1;
}
 
-   odp_shm_free(pool->s.pool_shm);
+   if (pool->s.params.unresv_mem_fn != NULL)
+   pool->s.params.unresv_mem_fn((void *)pool->s.pool_base_addr);
+   else
+   odp_shm_free(pool->s.pool_shm);
+
pool->s.pool_shm = ODP_SHM_INVALID;
POOL_UNLOCK(>s.lock);
 
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC API-NEXT PATCH] api: packet: add packet segment manipulation

[Bill Fischofer]

On Mon, Jan 11, 2016 at 7:47 AM, Petri Savolainen <
petri.savolai...@nokia.com> wrote:

> Packet segments can be allocated/freed/multi-referenced.
> Segments data pointer and length can be modified (push/pull).
> Segments can be linked to packets when needed (can exist also
> when not connected to packets).
>
> TODO: Packet pool params need tuning for segment length
> configuration.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/packet.h | 82
> +++-
>  1 file changed, 74 insertions(+), 8 deletions(-)
>
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 8651a47..7d315ba 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -118,6 +118,15 @@ int odp_packet_alloc_multi(odp_pool_t pool, uint32_t
> len,
>odp_packet_t pkt[], int num);
>
>  /**
> + * Create a new reference to the packet
> + *
> + * @param pkt   Packet handle
> + *
> + * @return New handle which refers to the input packet
> + */
> +odp_packet_t odp_packet_ref(odp_packet_t pkt);
>

Do we need to distinguish between non-shared vs. shared references?  That
was something we discussed earlier, which is why I had a 2nd parameter in
my proposed version of this API.  Under this form this implies that all
references are shared, meaning that a change to the underlying packet via
any handle is visible to all other references to that packet.  OK if that's
what we want, but we need to note this behavior.


> +
> +/**
>   * Free packet
>   *
>   * Frees the packet into the buffer pool it was allocated from.
> @@ -810,11 +819,44 @@ void odp_packet_shaper_len_adjust_set(odp_packet_t
> pkt, int8_t adj);
>   */
>
>  /**
> + * Allocate a new segment
> + *
> + * Allocates a new segment from the specified packet pool. The segment
> + * is initialized with data pointers and lengths set according to the
> + * specified len. All other segment metadata are set to their default
> values.
> + *
> + * @param pool  Pool handle
> + * @param len   Segment data length
> + *
> + * @return Handle of allocated packet
> + * @retval ODP_PACKET_SEG_INVALID  Segment could not be allocated
> + */
> +odp_packet_seg_t odp_packet_seg_alloc(odp_pool_t pool, uint32_t len);
>

The problem I have with this proposed API is that segments are used to
represent the physical organization of packets at a platform level, which
controls contiguous addressability.  This is why the various packet APIs
that return addresses also return a seg_len output parameter which tells
the caller how many bytes are contiguously addressable from the returned
address. Since segment lengths are inherently platform-specific, what
happens if the caller requests a len that's larger than one of these
platform-defined segment lengths?  That would seem to get awkward as alloc
calls would either fail unpredictably from platform to platform or else the
implementation would have to allocate multiple physical segments and chain
them together into a "logical segment" that would share the same ODP data
type as a physical segment (odp_packet_seg_t), which would also be
confusing and ambiguous.

But a logical segment, as envisioned here is effectively what a packet is,
which is why I've proposed that composites be packet-based rather than
segment based.  The difference is the amount of metadata that's carried.  A
simple solution would be to provide a hint to the implementation that full
metadata is not required for one of these packets that are intended to be
used as composite packet components.  I'd rather tackle the metadata
management issue separately rather than conflate physical and logical
segments as that would seem to be more portable and more easily
implementable across a range of HW-based or assisted implementations.

Possible solutions to this would be either an additional parameter (e.g.,
odp_packet_alloc(pool, len, options);) or a separate API that also returns
an odp_packet_t (e.g., odp_packet_alloc_subpacket(pool, len);).  This would
also have the advantage that per-subpacket metadata can be added back as
needed to allow for more sophisticated structures over time.

The other issue is that this API is that it introduces the notion of
odp_packet_seg_t objects that are not associated with any packet since
until they are attached to a packet they are "floating", which is something
new.  Currently an odp_packet_seg_t is always a part of a packet and simply
represents how a platform physically organizes an odp_packet_t into memory.
It's not clear how easy this change would be for many implementations.


> +
> +/**
> + * Free segment
> + *
> + * Frees the segment into the pool it was allocated from. Segment must
> not be
> + * linked into any packet.
> + *
> + * @param seg   Segment handle
> + */
> +void odp_packet_seg_free(odp_packet_seg_t seg);
>

If we use packets for composite parts, then this would just be
odp_packet_free() 

Re: [lng-odp] [PATCH] doc: images: refactor makefile

[Maxim Uvarov]

Merged,
Maxim.

On 01/07/2016 22:47, Bill Fischofer wrote:



On Thu, Jan 7, 2016 at 1:44 PM, Mike Holmes > wrote:


Drop per target rules for generic make

Suggested-by: Anders Roxell 
Signed-off-by: Mike Holmes >


Reviewed-by: Bill Fischofer >


---
 doc/images/Makefile.am | 67
++
 1 file changed, 13 insertions(+), 54 deletions(-)

diff --git a/doc/images/Makefile.am b/doc/images/Makefile.am
index 5495b69..8ab03b4 100644
--- a/doc/images/Makefile.am
+++ b/doc/images/Makefile.am
@@ -1,4 +1,14 @@
-SVG_SRCS =  atomic_queue.svg \
+.svg.png:
+   convert $^ $@
+
+.svg.eps:
+   convert $^ $@
+
+.msc.png:
+   mscgen -T png -i $^ -o $@
+
+SVG_SRCS = \
+   atomic_queue.svg \
ordered_queue.svg \
parallel_queue.svg \
odp_components.svg \
@@ -11,12 +21,13 @@ SVG_SRCS =  atomic_queue.svg \

 SVG_TARGETS = $(SVG_SRCS:svg=png)
 SVG_TARGETS += $(SVG_SRCS:svg=eps)
+
 MSG_SRCS = resource_management.msc
 MSG_TARGETS = $(MSG_SRCS:msc=png)

 EXTRA_DIST = $(SVG_SRCS) $(MSG_SRCS)

-TARGETS=
+TARGETS=$(SVG_TARGETS) $(MSG_TARGETS)

 if HAVE_IMAGEMAGIC
 TARGETS += $(SVG_TARGETS)
@@ -30,55 +41,3 @@ all-local: $(TARGETS)

 clean-local:
rm -f $(SVG_TARGETS) $(MSG_TARGETS)
-
-atomic_queue.png: atomic_queue.svg
-   convert $< $@
-atomic_queue.eps: atomic_queue.svg
-   convert $< $@
-
-ordered_queue.png: ordered_queue.svg
-   convert $< $@
-parallel_queue.eps: parallel_queue.svg
-   convert $< $@
-
-parallel_queue.png: parallel_queue.svg
-   convert $< $@
-ordered_queue.eps: ordered_queue.svg
-   convert $< $@
-
-odp_components.png: odp_components.svg
-   convert $< $@
-odp_components.eps: odp_components.svg
-   convert $< $@
-
-odp_rx_processing.png: odp_rx_processing.svg
-   convert $< $@
-odp_rx_processing.eps: odp_rx_processing.svg
-   convert $< $@
-
-odp_scheduling.png: odp_scheduling.svg
-   convert $< $@
-odp_scheduling.eps: odp_scheduling.svg
-   convert $< $@
-
-odp_traffic_manager.png: odp_traffic_manager.svg
-   convert $< $@
-odp_traffic_manager.eps: odp_traffic_manager.svg
-   convert $< $@
-
-overview.png: overview.svg
-   convert $< $@
-overview.eps: overview.svg
-
-release_git.png: release_git.svg
-   convert $< $@
-release_git.eps: release_git.svg
-   convert $< $@
-
-simple_release_git.png: simple_release_git.svg
-   convert $< $@
-simple_release_git.eps: simple_release_git.svg
-   convert $< $@
-
-resource_management.png: resource_management.msc
-   mscgen -T png -i $< -o $@
--
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org 
https://lists.linaro.org/mailman/listinfo/lng-odp




___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] validation: possibility to inactive preconded test

[Mike Holmes]

Looks good, but maybe the implementers guide needs an update.
The example is now out of date, we can have the guide automatically use the
code frm in test as part of the doc if you think that helps keep it in sync

On 11 January 2016 at 07:18, Christophe Milard  wrote:

> When marking a test which has a precondition as temporarly inactive,
> it feels better to be able to keep the precondition function:
> ODP_TEST_INFO_CONDITIONAL(send_failure, check_send_failure)
> will be marked as inactive by:
> ODP_TEST_INFO_INACTIVE(send_failure, check_send_failure)
> rather than:
> ODP_TEST_INFO_INACTIVE(send_failure)
> Remarking the test as active later on is then only a matter of changing
> back the macro name.
>
> Signed-off-by: Christophe Milard 
> ---
>  test/validation/common/odp_cunit_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/validation/common/odp_cunit_common.h
> b/test/validation/common/odp_cunit_common.h
> index 8dbbb9f..37e8e8c 100644
> --- a/test/validation/common/odp_cunit_common.h
> +++ b/test/validation/common/odp_cunit_common.h
> @@ -44,7 +44,7 @@ static inline void odp_cunit_test_missing(void) { }
>  /* A test case that is unconditionally inactive. Its name will be
> registered
>   * with CUnit but it won't be executed and will be reported as inactive in
>   * the result summary. */
> -#define ODP_TEST_INFO_INACTIVE(test_func) \
> +#define ODP_TEST_INFO_INACTIVE(test_func, args...) \
> {#test_func, odp_cunit_test_missing, odp_cunit_test_inactive}
>
>  /* A test case that may be marked as inactive at runtime based on the
> --
> 2.1.4
>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] ODP 1.5 - Crash while cleanup ODP/ODP timer pool

[Bogdan Pricope]

Hi,

I am using ODP-LNG 1.5 and I am getting this crash while trying to cleanup ODP 
timer pool + other resources.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe700 (LWP 27019)]
timer_notify (sigval=sigval@entry=...) at odp_timer.c:638
638 overrun = timer_getoverrun(tp->timerid);
(gdb) bt
#0  timer_notify (sigval=sigval@entry=...) at odp_timer.c:638
#1  0x76fb80ff in timer_sigev_thread (arg=0x78c0) at 
../nptl/sysdeps/unix/sysv/linux/timer_routines.c:63
#2  0x77589182 in start_thread (arg=0x7fffe700) at 
pthread_create.c:312
#3  0x772b5efd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) print tp
$1 = (odp_timer_pool *) 0x77dfd000
(gdb) print *tp
Cannot access memory at address 0x77dfd000
(gdb) print sigval
$2 = {sival_int = -136327168, sival_ptr = 0x77dfd000}


This 'timer_notify()' is the callback for timer associated with an ODP timer 
pool.

See this:
http://man7.org/linux/man-pages/man2/timer_delete.2.html

This crash may be related to:

"The treatment of any pending signal generated by the
   deleted timer is unspecified.
"

Any thoughts?


Best regards,
Bogdan
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH v3 0/3] correct limits validation

[Maxim Uvarov]

Merged,
Maxim.

On 01/11/2016 12:58, Ivan Khoronzhuk wrote:

This series corrects limits based on resolution.

Since v2:
- remove return

Since v1:
- no functional changes
- replaceed "[lng-odp] [PATCH 1/3] validation: time: initialize resolution vars"
   on "validation: time: store local and global resolution" from Nicolas

Ivan Khoronzhuk (2):
   validation: time: round up resolution
   validation: time: increase limit to check to 2 res

Nicolas Morey-Chaisemartin (1):
   validation: time: store local and global resolution

  test/validation/time/time.c | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)



___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv9] helper : Fix UDP checksum computation

[Maxim Uvarov]

Merged,
Thanks,
Maxim.

On 01/11/2016 12:48, Ilya Maximets wrote:

On 11.01.2016 12:13, ion.grig...@freescale.com wrote:

From: Grigore Ion 

This patch fixes the following problems:
- checksum computation for LE platforms
- checksum computation for packets having the UDP length not a
multiple of 2
- checksum computation in the test and the example applications

Signed-off-by: Grigore Ion 
---
v9:
- Fix comments (Ilya Maximets)
v8:
- Checksum in BE endianness (Ilya Maximets)
v7:
- Make code simpler and more understandable as it was
sugessted by Ilya Maximets
v6:
- Make code more understandable. Not done as it was
sugessted by Ilya Maximets.
v5:
- Checksum in CPU endianness fix added (Ilya Maximets)
v4:
- Verify checksum in CPU endianness in the associated test
(Ilya Maximets)
v3:
- fix the UDP checksum computation in the associated test
(Maxim Uvarov)
v2:
- patch updated to the last master (Maxim Uvarov)
v1:
- Move variables declaration on top of block. (Maxim Uvarov)
- Check patch with checkpatch script.  (Maxim Uvarov)
- L3 header presence is tested twice. (Alexandru Badicioiu)
- Remove unnecessary check for L3 header presence. (Bill Fischofer)

  example/generator/odp_generator.c |  2 +-
  helper/include/odp/helper/udp.h   | 66 ---
  helper/test/odp_chksum.c  |  4 +--
  test/validation/pktio/pktio.c |  2 +-
  4 files changed, 38 insertions(+), 36 deletions(-)

Reviewed-by: Ilya Maximets 


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCH v3 2/6] linux-generic: pktio: re-organize queue config code

[Petri Savolainen]

Push generic parts of input/output queue config code to
upper level (into odp_packet_io.c).

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/include/odp_packet_netmap.h |   7 +-
 platform/linux-generic/odp_packet_io.c | 186 ++---
 platform/linux-generic/pktio/netmap.c  | 108 ++--
 3 files changed, 139 insertions(+), 162 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index dae770d..26a8da1 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -48,13 +48,10 @@ typedef struct {
unsigned cur_rx_queue;  /**< current pktin queue */
uint32_t num_rx_rings;  /**< number of nm rx rings */
uint32_t num_tx_rings;  /**< number of nm tx rings */
+   unsigned num_rx_desc_rings; /**< number of rx descriptor rings */
+   unsigned num_tx_desc_rings; /**< number of tx descriptor rings */
odp_bool_t lockless_rx; /**< no locking for rx */
odp_bool_t lockless_tx; /**< no locking for tx */
-   /** State of netmap descriptors */
-   enum {
-   NM_DESC_INVALID = 0,
-   NM_DESC_VALID
-   } desc_state;
/** mapping of pktin queues to netmap rx descriptors */
netmap_ring_t rx_desc_ring[PKTIO_MAX_QUEUES];
/** mapping of pktout queues to netmap tx descriptors */
diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index 95b8904..1b1f811 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -279,6 +279,18 @@ static int _pktio_close(pktio_entry_t *entry)
return 0;
 }
 
+static void destroy_in_queues(pktio_entry_t *entry, int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++) {
+   if (entry->s.in_queue[i].queue != ODP_QUEUE_INVALID) {
+   odp_queue_destroy(entry->s.in_queue[i].queue);
+   entry->s.in_queue[i].queue = ODP_QUEUE_INVALID;
+   }
+   }
+}
+
 int odp_pktio_close(odp_pktio_t id)
 {
pktio_entry_t *entry;
@@ -289,6 +301,9 @@ int odp_pktio_close(odp_pktio_t id)
return -1;
 
lock_entry(entry);
+
+   destroy_in_queues(entry, entry->s.num_in_queue);
+
if (!is_free(entry)) {
res = _pktio_close(entry);
if (res)
@@ -971,9 +986,16 @@ int odp_pktio_input_queues_config(odp_pktio_t pktio,
  const odp_pktio_input_queue_param_t *param)
 {
pktio_entry_t *entry;
+   odp_pktio_input_mode_t mode;
+   odp_pktio_capability_t capa;
+   unsigned num_queues;
+   unsigned i;
+   odp_queue_t queue;
 
-   if (param == NULL)
+   if (param == NULL) {
+   ODP_DBG("no parameters\n");
return -1;
+   }
 
entry = get_pktio_entry(pktio);
if (entry == NULL) {
@@ -981,10 +1003,69 @@ int odp_pktio_input_queues_config(odp_pktio_t pktio,
return -1;
}
 
+   if (entry->s.state != STATE_STOP) {
+   ODP_DBG("pktio %s: not stopped\n", entry->s.name);
+   return -1;
+   }
+
+   mode = entry->s.param.in_mode;
+
+   if (mode == ODP_PKTIN_MODE_DISABLED) {
+   ODP_DBG("pktio %s: packet input is disabled\n", entry->s.name);
+   return -1;
+   }
+
+   num_queues = param->num_queues;
+
+   if (num_queues == 0) {
+   ODP_DBG("pktio %s: zero input queues\n", entry->s.name);
+   return -1;
+   }
+
+   odp_pktio_capability(pktio, );
+
+   if (num_queues > capa.max_input_queues) {
+   ODP_DBG("pktio %s: too many input queues\n", entry->s.name);
+   return -1;
+   }
+
+   /* If re-configuring, destroy old queues */
+   if (entry->s.num_in_queue)
+   destroy_in_queues(entry, entry->s.num_in_queue);
+
+   for (i = 0; i < num_queues; i++) {
+   if (mode == ODP_PKTIN_MODE_POLL ||
+   mode == ODP_PKTIN_MODE_SCHED) {
+   odp_queue_type_t type = ODP_QUEUE_TYPE_POLL;
+
+   if (mode == ODP_PKTIN_MODE_SCHED)
+   type = ODP_QUEUE_TYPE_SCHED;
+
+   /* Ugly cast to uintptr_t is needed since queue_param
+* is not defined as const in odp_queue_create() */
+   queue = odp_queue_create("pktio_in", type,
+(odp_queue_param_t *)
+(uintptr_t)
+>queue_param);
+   if (queue == ODP_QUEUE_INVALID) {
+   destroy_in_queues(entry, i + 

[lng-odp] [API-NEXT PATCH v3 1/6] linux-generic: netmap: map rings in netmap_start

[Petri Savolainen]

From: Matias Elo 

This is a bug fix for old API. Map pktin/pktout queues to
netmap rings in netmap_start() instead of
netmap_*put_queues_config() for backward compatibility with
inq_setdef API.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/netmap.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index ed5159b..a347d29 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -207,9 +207,6 @@ static int netmap_input_queues_config(pktio_entry_t 
*pktio_entry,
pktio->in_queue[i].pktin.index = i;
pktio->in_queue[i].pktin.pktio = pktio_entry->s.handle;
}
-   /* Map pktin queues to netmap rings */
-   map_netmap_rings(pkt_nm->rx_desc_ring, num_queues,
-pkt_nm->num_rx_rings);
 
pkt_nm->lockless_rx = single_user;
 
@@ -241,15 +238,13 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
if (num_queues == pktio_entry->s.num_out_queue) /* Already configured */
return 0;
 
-   /* Enough to map only one netmap tx ring per pktout queue */
-   map_netmap_rings(pkt_nm->tx_desc_ring, num_queues, num_queues);
-
for (i = 0; i < num_queues; i++) {
pktio->out_queue[i].pktout.index = i;
pktio->out_queue[i].pktout.pktio = pktio_entry->s.handle;
}
pkt_nm->desc_state = NM_DESC_INVALID;
pktio_entry->s.num_out_queue = num_queues;
+
return 0;
 }
 
@@ -481,6 +476,17 @@ static int netmap_start(pktio_entry_t *pktio_entry)
 
netmap_close_descriptors(pktio_entry);
 
+   /* Map pktin/pktout queues to netmap rings */
+   if (pktio_entry->s.num_in_queue)
+   map_netmap_rings(pkt_nm->rx_desc_ring,
+pktio_entry->s.num_in_queue,
+pkt_nm->num_rx_rings);
+   if (pktio_entry->s.num_out_queue)
+   /* Enough to map only one netmap tx ring per pktout queue */
+   map_netmap_rings(pkt_nm->tx_desc_ring,
+pktio_entry->s.num_out_queue,
+pktio_entry->s.num_out_queue);
+
base_desc.self = _desc;
base_desc.mem = NULL;
memcpy(base_desc.req.nr_name, pktio_entry->s.name,
-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCH v3 0/6] Multi-queue pktio for poll mode

[Petri Savolainen]

This patch set adds support for multi-queue pktio for poll mode queues.

v3:
  * Rebased

v2:
  * Bug correction in patch 2/6: bad netmap initialization when using 
the old API.

Matias Elo (1):
  linux-generic: netmap: map rings in netmap_start

Petri Savolainen (5):
  linux-generic: pktio: re-organize queue config code
  linux-generic: pktio: added poll type input queue
  linux-generic: pktio: use multiqueue recv internally
  test: l2fwd: re-organize functions
  test: l2fwd: added poll queue mode

 platform/linux-generic/include/odp_packet_netmap.h |   7 +-
 .../linux-generic/include/odp_queue_internal.h |   2 +-
 platform/linux-generic/odp_packet_io.c | 216 --
 platform/linux-generic/odp_queue.c |   2 +
 platform/linux-generic/pktio/netmap.c  | 124 +---
 test/performance/odp_l2fwd.c   | 797 -
 6 files changed, 632 insertions(+), 516 deletions(-)

-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] validation: possibility to inactive preconded test

[Christophe Milard]

When marking a test which has a precondition as temporarly inactive,
it feels better to be able to keep the precondition function:
ODP_TEST_INFO_CONDITIONAL(send_failure, check_send_failure)
will be marked as inactive by:
ODP_TEST_INFO_INACTIVE(send_failure, check_send_failure)
rather than:
ODP_TEST_INFO_INACTIVE(send_failure)
Remarking the test as active later on is then only a matter of changing
back the macro name.

Signed-off-by: Christophe Milard 
---
 test/validation/common/odp_cunit_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/validation/common/odp_cunit_common.h 
b/test/validation/common/odp_cunit_common.h
index 8dbbb9f..37e8e8c 100644
--- a/test/validation/common/odp_cunit_common.h
+++ b/test/validation/common/odp_cunit_common.h
@@ -44,7 +44,7 @@ static inline void odp_cunit_test_missing(void) { }
 /* A test case that is unconditionally inactive. Its name will be registered
  * with CUnit but it won't be executed and will be reported as inactive in
  * the result summary. */
-#define ODP_TEST_INFO_INACTIVE(test_func) \
+#define ODP_TEST_INFO_INACTIVE(test_func, args...) \
{#test_func, odp_cunit_test_missing, odp_cunit_test_inactive}
 
 /* A test case that may be marked as inactive at runtime based on the
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCH v3 3/6] linux-generic: pktio: added poll type input queue

[Petri Savolainen]

Added support for poll type input queues.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_queue_internal.h |  2 +-
 platform/linux-generic/odp_packet_io.c | 23 ++
 platform/linux-generic/odp_queue.c |  2 ++
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_queue_internal.h 
b/platform/linux-generic/include/odp_queue_internal.h
index b4c1909..de612eb 100644
--- a/platform/linux-generic/include/odp_queue_internal.h
+++ b/platform/linux-generic/include/odp_queue_internal.h
@@ -76,7 +76,7 @@ struct queue_entry_s {
odp_event_t   cmd_ev;
odp_queue_type_t  type;
odp_queue_param_t param;
-   odp_pktio_t   pktin;
+   odp_pktin_queue_t pktin;
odp_pktio_t   pktout;
char  name[ODP_QUEUE_NAME_LEN];
uint64_t  order_in;
diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index 1b1f811..713c597 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -496,7 +496,8 @@ int odp_pktio_inq_setdef(odp_pktio_t id, odp_queue_t queue)
 
/* User polls the input queue */
queue_lock(qentry);
-   qentry->s.pktin = id;
+   qentry->s.pktin.pktio = id;
+   qentry->s.pktin.index = 0;
queue_unlock(qentry);
 
return 0;
@@ -522,7 +523,7 @@ int odp_pktio_inq_remdef(odp_pktio_t id)
qentry = queue_to_qentry(queue);
 
queue_lock(qentry);
-   qentry->s.pktin = ODP_PKTIO_INVALID;
+   qentry->s.pktin = PKTIN_INVALID;
queue_unlock(qentry);
 
pktio_entry->s.in_queue[0].queue = ODP_QUEUE_INVALID;
@@ -613,7 +614,7 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *qentry)
if (buf_hdr != NULL)
return buf_hdr;
 
-   pktio = qentry->s.pktin;
+   pktio = qentry->s.pktin.pktio;
 
pkts = odp_pktio_recv(pktio, pkt_tbl, QUEUE_MULTI_MAX);
if (pkts <= 0)
@@ -658,7 +659,7 @@ int pktin_deq_multi(queue_entry_t *qentry, odp_buffer_hdr_t 
*buf_hdr[], int num)
if (nbr == num)
return nbr;
 
-   pktio = qentry->s.pktin;
+   pktio = qentry->s.pktin.pktio;
 
pkts = odp_pktio_recv(pktio, pkt_tbl, QUEUE_MULTI_MAX);
if (pkts <= 0)
@@ -1051,6 +1052,20 @@ int odp_pktio_input_queues_config(odp_pktio_t pktio,
destroy_in_queues(entry, i + 1);
return -1;
}
+
+   if (mode == ODP_PKTIN_MODE_POLL) {
+   queue_entry_t *qentry;
+
+   qentry = queue_to_qentry(queue);
+   qentry->s.pktin.index  = i;
+   qentry->s.pktin.pktio  = pktio;
+
+   qentry->s.enqueue = pktin_enqueue;
+   qentry->s.dequeue = pktin_dequeue;
+   qentry->s.enqueue_multi = pktin_enq_multi;
+   qentry->s.dequeue_multi = pktin_deq_multi;
+   }
+
entry->s.in_queue[i].queue = queue;
} else {
entry->s.in_queue[i].queue = ODP_QUEUE_INVALID;
diff --git a/platform/linux-generic/odp_queue.c 
b/platform/linux-generic/odp_queue.c
index a2fd4ec..17a26e8 100644
--- a/platform/linux-generic/odp_queue.c
+++ b/platform/linux-generic/odp_queue.c
@@ -128,6 +128,8 @@ static int queue_init(queue_entry_t *queue, const char 
*name,
break;
}
 
+   queue->s.pktin = PKTIN_INVALID;
+
queue->s.head = NULL;
queue->s.tail = NULL;
 
-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC API-NEXT PATCH] Packet References and Composites

[Bill Fischofer]

Thanks. I'll do that in the next iteration.  I just wanted to get the
discussion going on these topics, and in particular to get feedback from
the SoC vendors as to what sort of aggregation mechanism fits most
naturally with their architecture and HW capabilities.  Note that this is
just an initial cut and I'd expect it to expand considerably before it
becomes a real patch.

The idea behind composites is to provide more sophisticated packet
manipulation capabilities without resulting in something that is either
overly SW-centric or tied to specific implementation assumptions.  The
odp_packet_t is a good baseline abstraction but it currently does not allow
for multiple packets to consist of shared and non-shared parts.  That's the
basic idea behind a composite.

A composite is a higher-level packet abstraction that is designed to do two
things:

1. Maintain all of the ODP APIs associated with packets--we don't need a
parallel set of APIs that do the same thing, only with composites instead
of packets.

2. Permit the individual sections of a composite (I don't want to use the
term segments here, since that's confusing since we already use that term
to reflect the underlying implementation's physical organization of
packets) to continue to be manipulable individually as packets in their own
right for maximum flexibility.

As for use case, here's a simple one: a composite that consists of two
parts: a payload and a header:

odp_packet_t payload = odp_packet_alloc(pool, payload_len);
odp_packet_t header1 = odp_packet_alloc(pool, header_len1);
odp_packe_t header2 =  odp_packet_alloc(pool, header_len2);

odp_packet_t composite1 = odp_packet_push_prefix(payload, header1);
odp_packet_t composite2 = odp_packet_push_prefix(payload, header2);

In this case composite1 and composite2 share payload as a common section
while having individual headers that can be
manipulated independently.

Now let's suppose composite1 is to be transmitted through a tunnel:

odp_packet_t tunnel_header1 = odp_packet_alloc(pool. tunnel_hdr_len1);

odp_packet_t tunnel_composite1 = odp_packet_push_prefix(composite1,
tunnel_header1);

etc.

Writing it out like this I can see already the syntax could use improvement
and we probably want to add explicit split/join APIs to help with this, but
hopefully this clarifies some of the intent.

Bill


On Mon, Jan 11, 2016 at 6:11 AM, Bala Manoharan 
wrote:

> This patch series could be split into two different parts as Reference
> and Composite since IMO the Referencing part is straight forward and
> might not need much discussion and could be be accepted sooner.
>
> Regarding the concept of composite packets it would be appreciable to
> provide some use-cases for this API.
> The individual pieces of the composite could be referenced using a
> different handle than the odp_packet_t in the same way we do for
> segments. Since the idea is to utilize unique and shared sections
> these sections could be referred using odp_buffer_t rather than
> odp_packet_t.
>
> Regards,
> Bala
> Regards,
> Bala
>
>
> On 7 January 2016 at 20:20, Bill Fischofer 
> wrote:
> > Add two new concepts to ODP Packets: References and Composites
> >
> > This RFC proposes the addition of two new concepts to the ODP API:
> References
> > and Composites. A reference is an alias to packet. References are either
> > shared or nonshared. Changes to a shared reference are visible to all
> other
> > shared reference to the same packet while changes to nonshared
> references are
> > unique to that reference. References provide an efficient means of
> supporting
> > things like multicast without the explicit use of reference counts, as
> > underlying packet storage is only freed when the last reference to it is
> > freed.
> >
> > References are intended to be used in conjunction with another new
> concept:
> > Composites. A composite is a logical join between two packets that can
> then
> > be manipulated as if they are a single packet. The intent of composites
> is to
> > provide an efficient and implementation-independent means of creating and
> > manipulating packets that consist of a combination of unique and shared
> > sections. Typical use would be to have one or more unique headers
> prefixed to
> > a common payload.
> >
> > Composites are created by pushing/pulling prefixes and suffixes. These
> > routines create a new composite packet which has its own handle. Each of
> the
> > component parts of composites are themelves ODP packets and continue to
> be
> > manipulable via ODP APIs even while they are part of a composite.
> References
> > to each part of a composite via its own handle affect that part of the
> > composite only but are visible when referencing the composite via its
> handle.
> > Note that a composite handle is an implied reference to each of its
> component
> > parts, so freeing a packet after it has been composited does not release
> the
> > underlying storage 

[lng-odp] [API-NEXT PATCH v3 4/6] linux-generic: pktio: use multiqueue recv internally

[Petri Savolainen]

Use multiqueue recv for poll type input queues.

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/odp_packet_io.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index 713c597..e8b5350 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -417,8 +417,6 @@ odp_pktio_t odp_pktio_lookup(const char *dev)
return id;
 }
 
-
-
 int odp_pktio_recv(odp_pktio_t id, odp_packet_t pkt_table[], int len)
 {
pktio_entry_t *pktio_entry = get_pktio_entry(id);
@@ -608,15 +606,13 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *qentry)
odp_packet_t pkt_tbl[QUEUE_MULTI_MAX];
odp_buffer_hdr_t *hdr_tbl[QUEUE_MULTI_MAX];
int pkts, i;
-   odp_pktio_t pktio;
 
buf_hdr = queue_deq(qentry);
if (buf_hdr != NULL)
return buf_hdr;
 
-   pktio = qentry->s.pktin.pktio;
+   pkts = odp_pktio_recv_queue(qentry->s.pktin, pkt_tbl, QUEUE_MULTI_MAX);
 
-   pkts = odp_pktio_recv(pktio, pkt_tbl, QUEUE_MULTI_MAX);
if (pkts <= 0)
return NULL;
 
@@ -646,7 +642,6 @@ int pktin_deq_multi(queue_entry_t *qentry, odp_buffer_hdr_t 
*buf_hdr[], int num)
odp_buffer_hdr_t *hdr_tbl[QUEUE_MULTI_MAX];
odp_buffer_t buf;
int pkts, i, j;
-   odp_pktio_t pktio;
 
nbr = queue_deq_multi(qentry, buf_hdr, num);
if (odp_unlikely(nbr > num))
@@ -659,9 +654,7 @@ int pktin_deq_multi(queue_entry_t *qentry, odp_buffer_hdr_t 
*buf_hdr[], int num)
if (nbr == num)
return nbr;
 
-   pktio = qentry->s.pktin.pktio;
-
-   pkts = odp_pktio_recv(pktio, pkt_tbl, QUEUE_MULTI_MAX);
+   pkts = odp_pktio_recv_queue(qentry->s.pktin, pkt_tbl, QUEUE_MULTI_MAX);
if (pkts <= 0)
return nbr;
 
-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [RFC API-NEXT PATCH] Packet References and Composites

[Bala Manoharan]

This patch series could be split into two different parts as Reference
and Composite since IMO the Referencing part is straight forward and
might not need much discussion and could be be accepted sooner.

Regarding the concept of composite packets it would be appreciable to
provide some use-cases for this API.
The individual pieces of the composite could be referenced using a
different handle than the odp_packet_t in the same way we do for
segments. Since the idea is to utilize unique and shared sections
these sections could be referred using odp_buffer_t rather than
odp_packet_t.

Regards,
Bala
Regards,
Bala


On 7 January 2016 at 20:20, Bill Fischofer  wrote:
> Add two new concepts to ODP Packets: References and Composites
>
> This RFC proposes the addition of two new concepts to the ODP API: References
> and Composites. A reference is an alias to packet. References are either
> shared or nonshared. Changes to a shared reference are visible to all other
> shared reference to the same packet while changes to nonshared references are
> unique to that reference. References provide an efficient means of supporting
> things like multicast without the explicit use of reference counts, as
> underlying packet storage is only freed when the last reference to it is
> freed.
>
> References are intended to be used in conjunction with another new concept:
> Composites. A composite is a logical join between two packets that can then
> be manipulated as if they are a single packet. The intent of composites is to
> provide an efficient and implementation-independent means of creating and
> manipulating packets that consist of a combination of unique and shared
> sections. Typical use would be to have one or more unique headers prefixed to
> a common payload.
>
> Composites are created by pushing/pulling prefixes and suffixes. These
> routines create a new composite packet which has its own handle. Each of the
> component parts of composites are themelves ODP packets and continue to be
> manipulable via ODP APIs even while they are part of a composite.  References
> to each part of a composite via its own handle affect that part of the
> composite only but are visible when referencing the composite via its handle.
> Note that a composite handle is an implied reference to each of its component
> parts, so freeing a packet after it has been composited does not release the
> underlying storage associated with that part until the composite itself is
> freed or the freed part is removed from the composite.
>
> Bill Fischofer (1):
>   api: packet: add packet references and composites
>
>  include/odp/api/packet.h | 98 
> 
>  1 file changed, 98 insertions(+)
>
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCH v3 6/6] test: l2fwd: added poll queue mode

[Petri Savolainen]

Added poll queue mode (mode == 4), which uses poll type queues
for packet input. Configuration and functionality is very similar
to direct recv mode.

Signed-off-by: Petri Savolainen 
---
 test/performance/odp_l2fwd.c | 188 ---
 1 file changed, 160 insertions(+), 28 deletions(-)

diff --git a/test/performance/odp_l2fwd.c b/test/performance/odp_l2fwd.c
index cfd0f07..dae9bbd 100644
--- a/test/performance/odp_l2fwd.c
+++ b/test/performance/odp_l2fwd.c
@@ -56,6 +56,7 @@
  */
 typedef enum pkt_in_mode_t {
DIRECT_RECV,
+   POLL_QUEUE,
SCHED_NONE,
SCHED_ATOMIC,
SCHED_ORDERED,
@@ -111,6 +112,7 @@ typedef struct thread_args_t {
odp_pktio_t tx_pktio;
odp_pktin_queue_t pktin;
odp_pktout_queue_t pktout;
+   odp_queue_t rx_queue;
int rx_idx;
int tx_idx;
int rx_queue_idx;
@@ -141,6 +143,7 @@ typedef struct {
odp_pktio_t pktio;
odp_pktin_queue_t pktin[MAX_QUEUES];
odp_pktout_queue_t pktout[MAX_QUEUES];
+   odp_queue_t rx_queue[MAX_QUEUES];
int num_rx_thr;
int num_tx_thr;
int num_rx_queue;
@@ -273,7 +276,7 @@ static void *run_worker_sched_mode(void *arg)
LOG_ABORT("Bad number of output queues %i\n", i);
}
 
-   printf("[%02i] QUEUE mode\n", thr);
+   printf("[%02i] SCHEDULED QUEUE mode\n", thr);
odp_barrier_wait();
 
wait = odp_schedule_wait_time(ODP_TIME_MSEC_IN_NS * 100);
@@ -332,6 +335,97 @@ static void *run_worker_sched_mode(void *arg)
 }
 
 /**
+ * Packet IO worker thread using poll queues
+ *
+ * @param arg  thread arguments of type 'thread_args_t *'
+ */
+static void *run_worker_poll_mode(void *arg)
+{
+   int thr;
+   int pkts;
+   odp_packet_t pkt_tbl[MAX_PKT_BURST];
+   int dst_idx, num_pktio;
+   odp_queue_t queue;
+   odp_pktout_queue_t pktout;
+   int pktio = 0;
+   thread_args_t *thr_args = arg;
+   stats_t *stats = thr_args->stats;
+
+   thr = odp_thread_id();
+
+   num_pktio = thr_args->num_pktio;
+   dst_idx   = thr_args->pktio[pktio].tx_idx;
+   queue = thr_args->pktio[pktio].rx_queue;
+   pktout= thr_args->pktio[pktio].pktout;
+
+   printf("[%02i] num pktios %i, POLL QUEUE mode\n", thr, num_pktio);
+   odp_barrier_wait();
+
+   /* Loop packets */
+   while (!exit_threads) {
+   int sent;
+   unsigned tx_drops;
+   odp_event_t event[MAX_PKT_BURST];
+   int i;
+
+   pkts = odp_queue_deq_multi(queue, event, MAX_PKT_BURST);
+   if (odp_unlikely(pkts <= 0))
+   continue;
+
+   for (i = 0; i < pkts; i++)
+   pkt_tbl[i] = odp_packet_from_event(event[i]);
+
+   if (gbl_args->appl.error_check) {
+   int rx_drops;
+
+   /* Drop packets with errors */
+   rx_drops = drop_err_pkts(pkt_tbl, pkts);
+
+   if (odp_unlikely(rx_drops)) {
+   stats->s.rx_drops += rx_drops;
+   if (pkts == rx_drops)
+   continue;
+
+   pkts -= rx_drops;
+   }
+   }
+
+   fill_eth_addrs(pkt_tbl, pkts, dst_idx);
+
+   sent = odp_pktio_send_queue(pktout, pkt_tbl, pkts);
+
+   sent = odp_unlikely(sent < 0) ? 0 : sent;
+   tx_drops = pkts - sent;
+
+   if (odp_unlikely(tx_drops)) {
+   int i;
+
+   stats->s.tx_drops += tx_drops;
+
+   /* Drop rejected packets */
+   for (i = sent; i < pkts; i++)
+   odp_packet_free(pkt_tbl[i]);
+   }
+
+   stats->s.packets += pkts;
+
+   if (num_pktio > 1) {
+   dst_idx   = thr_args->pktio[pktio].tx_idx;
+   queue = thr_args->pktio[pktio].rx_queue;
+   pktout= thr_args->pktio[pktio].pktout;
+   pktio++;
+   if (pktio == num_pktio)
+   pktio = 0;
+   }
+   }
+
+   /* Make sure that latest stat writes are visible to other threads */
+   odp_mb_full();
+
+   return NULL;
+}
+
+/**
  * Packet IO worker thread accessing IO resources directly
  *
  * @param arg  thread arguments of type 'thread_args_t *'
@@ -428,7 +522,7 @@ static void *run_worker_direct_mode(void *arg)
  * @retval 0 on success
  * @retval -1 on failure
  */
-static int create_pktio(const char *dev, int index, int num_rx, int num_tx,
+static int create_pktio(const char *dev, 

[lng-odp] [API-NEXT PATCH v3 5/6] test: l2fwd: re-organize functions

[Petri Savolainen]

Re-order functions to get rid off (static) function prototypes
and improve code readability.

Signed-off-by: Petri Savolainen 
---
 test/performance/odp_l2fwd.c | 645 +--
 1 file changed, 318 insertions(+), 327 deletions(-)

diff --git a/test/performance/odp_l2fwd.c b/test/performance/odp_l2fwd.c
index c3eedce..cfd0f07 100644
--- a/test/performance/odp_l2fwd.c
+++ b/test/performance/odp_l2fwd.c
@@ -155,22 +155,97 @@ static args_t *gbl_args;
 /** Global barrier to synchronize main and workers */
 static odp_barrier_t barrier;
 
-/* helper funcs */
-static inline int lookup_dest_port(odp_packet_t pkt);
-static inline int find_dest_port(int port);
-static inline int drop_err_pkts(odp_packet_t pkt_tbl[], unsigned num);
-static void fill_eth_addrs(odp_packet_t pkt_tbl[], unsigned num,
-  int dst_port);
-static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
-static void print_info(char *progname, appl_args_t *appl_args);
-static void usage(char *progname);
-
-/**
- * Packet IO worker thread using ODP queues
+/**
+ * Lookup the destination port for a given packet
+ *
+ * @param pkt  ODP packet handle
+ */
+static inline int lookup_dest_port(odp_packet_t pkt)
+{
+   int i, src_idx;
+   odp_pktio_t pktio_src;
+
+   pktio_src = odp_packet_input(pkt);
+
+   for (src_idx = -1, i = 0; gbl_args->pktios[i].pktio
+ != ODP_PKTIO_INVALID; ++i)
+   if (gbl_args->pktios[i].pktio == pktio_src)
+   src_idx = i;
+
+   if (src_idx == -1)
+   LOG_ABORT("Failed to determine pktio input\n");
+
+   return gbl_args->dst_port[src_idx];
+}
+
+/**
+ * Drop packets which input parsing marked as containing errors.
+ *
+ * Frees packets with error and modifies pkt_tbl[] to only contain packets with
+ * no detected errors.
+ *
+ * @param pkt_tbl  Array of packets
+ * @param num  Number of packets in pkt_tbl[]
+ *
+ * @return Number of packets dropped
+ */
+static inline int drop_err_pkts(odp_packet_t pkt_tbl[], unsigned num)
+{
+   odp_packet_t pkt;
+   unsigned dropped = 0;
+   unsigned i, j;
+
+   for (i = 0, j = 0; i < num; ++i) {
+   pkt = pkt_tbl[i];
+
+   if (odp_unlikely(odp_packet_has_error(pkt))) {
+   odp_packet_free(pkt); /* Drop */
+   dropped++;
+   } else if (odp_unlikely(i != j++)) {
+   pkt_tbl[j - 1] = pkt;
+   }
+   }
+
+   return dropped;
+}
+
+/**
+ * Fill packets' eth addresses according to the destination port
+ *
+ * @param pkt_tbl  Array of packets
+ * @param num  Number of packets in the array
+ * @param dst_port Destination port
+ */
+static inline void fill_eth_addrs(odp_packet_t pkt_tbl[],
+ unsigned num, int dst_port)
+{
+   odp_packet_t pkt;
+   odph_ethhdr_t *eth;
+   unsigned i;
+
+   if (!gbl_args->appl.dst_change && !gbl_args->appl.src_change)
+   return;
+
+   for (i = 0; i < num; ++i) {
+   pkt = pkt_tbl[i];
+   if (odp_packet_has_eth(pkt)) {
+   eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
+
+   if (gbl_args->appl.src_change)
+   eth->src = gbl_args->port_eth_addr[dst_port];
+
+   if (gbl_args->appl.dst_change)
+   eth->dst = gbl_args->dst_eth_addr[dst_port];
+   }
+   }
+}
+
+/**
+ * Packet IO worker thread using scheduled queues
  *
  * @param arg  thread arguments of type 'thread_args_t *'
  */
-static void *pktio_queue_thread(void *arg)
+static void *run_worker_sched_mode(void *arg)
 {
odp_event_t  ev_tbl[MAX_PKT_BURST];
odp_packet_t pkt_tbl[MAX_PKT_BURST];
@@ -257,52 +332,11 @@ static void *pktio_queue_thread(void *arg)
 }
 
 /**
- * Lookup the destination port for a given packet
- *
- * @param pkt  ODP packet handle
- */
-static inline int lookup_dest_port(odp_packet_t pkt)
-{
-   int i, src_idx;
-   odp_pktio_t pktio_src;
-
-   pktio_src = odp_packet_input(pkt);
-
-   for (src_idx = -1, i = 0; gbl_args->pktios[i].pktio
- != ODP_PKTIO_INVALID; ++i)
-   if (gbl_args->pktios[i].pktio == pktio_src)
-   src_idx = i;
-
-   if (src_idx == -1)
-   LOG_ABORT("Failed to determine pktio input\n");
-
-   return gbl_args->dst_port[src_idx];
-}
-
-/**
- * Find the destination port for a given input port
- *
- * @param port  Input port index
- */
-static inline int find_dest_port(int port)
-{
-   /* Even number of ports */
-   if (gbl_args->appl.if_count % 2 == 0)
-   return (port % 2 == 0) ? port + 1 : port - 1;
-
-   /* Odd number of ports */
-   if (port == gbl_args->appl.if_count - 1)
-   

[lng-odp] [RFC API-NEXT PATCH] packet segmentation

[Petri Savolainen]

Pseudo code example of multi-casting a received packet
-


odp_packet_seg_t prepared_seg[NUM_MCAST];


void on_init(void)
{
int i;

/* prepare a segment per multi-cast header */
for (i = 0; i < NUM_MCAST; i++) {
void *ptr;

prepared_seg[i] = odp_packet_seg_alloc(PACKET_POOL, 
new_hdr_len);
ptr= odp_packet_seg_data(prepared_seg[i]);
fill_in_packet_headers(ptr, i); 
}
}

void on_receive(odp_packet_t pkt_in)
{
int i;
odp_packet_t pkt[NUM_MCAST];
odp_packet_seg_t seg;

/* drop old headers */
odp_packet_push_head(pkt_in, old_hdr_len);

for (i = 0; i < NUM_MCAST - 1; i++) {

/* new reference */
pkt[i] = odp_packet_ref(pkt_in);

/* we'll re-use prepared multi-cast headers */ 
seg = odp_packet_seg_ref(prepared_seg[i]);

/* link segment to the head of the packet */
odp_packet_add_seg(pkt[i], 0, seg);
}

/* use incoming packet as one of the references */
pkt[NUM_MCAST - 1] = pkt_in;
seg = odp_packet_seg_ref(prepared_seg[NUM_MCAST - 1]);
odp_packet_add_seg(pkt[NUM_MCAST - 1], 0, seg);

for (i = 0; i < NUM_MCAST; i++) {
/* set metadata before sending */
odp_packet_l2_offset_set(pkt[i], 0);
odp_packet_l3_offset_set(pkt[i], 14);
odp_packet_l4_offset_set(pkt[i], 34);
}

/* All packet handles and common segments (the payload) are free'd after
 * transmit. Multi-cast header segments can be re-used on next packet, 
 * as the header data is constant. */
odp_pktio_send_queue(pktout, pkt, NUM_MCAST);
}


Petri Savolainen (1):
  api: packet: add packet segment manipulation

 include/odp/api/packet.h | 82 +++-
 1 file changed, 74 insertions(+), 8 deletions(-)

-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [RFC API-NEXT PATCH] api: packet: add packet segment manipulation

[Petri Savolainen]

Packet segments can be allocated/freed/multi-referenced.
Segments data pointer and length can be modified (push/pull).
Segments can be linked to packets when needed (can exist also
when not connected to packets).

TODO: Packet pool params need tuning for segment length
configuration.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/packet.h | 82 +++-
 1 file changed, 74 insertions(+), 8 deletions(-)

diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
index 8651a47..7d315ba 100644
--- a/include/odp/api/packet.h
+++ b/include/odp/api/packet.h
@@ -118,6 +118,15 @@ int odp_packet_alloc_multi(odp_pool_t pool, uint32_t len,
   odp_packet_t pkt[], int num);
 
 /**
+ * Create a new reference to the packet
+ *
+ * @param pkt   Packet handle
+ *
+ * @return New handle which refers to the input packet
+ */
+odp_packet_t odp_packet_ref(odp_packet_t pkt);
+
+/**
  * Free packet
  *
  * Frees the packet into the buffer pool it was allocated from.
@@ -810,11 +819,44 @@ void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, 
int8_t adj);
  */
 
 /**
+ * Allocate a new segment
+ *
+ * Allocates a new segment from the specified packet pool. The segment
+ * is initialized with data pointers and lengths set according to the
+ * specified len. All other segment metadata are set to their default values.
+ *
+ * @param pool  Pool handle
+ * @param len   Segment data length
+ *
+ * @return Handle of allocated packet
+ * @retval ODP_PACKET_SEG_INVALID  Segment could not be allocated
+ */
+odp_packet_seg_t odp_packet_seg_alloc(odp_pool_t pool, uint32_t len);
+
+/**
+ * Free segment
+ *
+ * Frees the segment into the pool it was allocated from. Segment must not be
+ * linked into any packet.
+ *
+ * @param seg   Segment handle
+ */
+void odp_packet_seg_free(odp_packet_seg_t seg);
+
+/**
+ * Create a new reference to the segment
+ *
+ * @param seg   Segment handle
+ *
+ * @return New handle which refers to the input segment
+ */
+odp_packet_seg_t odp_packet_seg_ref(odp_packet_seg_t seg);
+
+/**
  * Segment buffer address
  *
  * Returns start address of the segment.
  *
- * @param pkt  Packet handle
  * @param seg  Segment handle
  *
  * @return  Start address of the segment
@@ -822,28 +864,26 @@ void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, 
int8_t adj);
  *
  * @see odp_packet_seg_buf_len()
  */
-void *odp_packet_seg_buf_addr(odp_packet_t pkt, odp_packet_seg_t seg);
+void *odp_packet_seg_buf_addr(odp_packet_seg_t seg);
 
 /**
  * Segment buffer length
  *
  * Returns segment buffer length in bytes.
  *
- * @param pkt  Packet handle
  * @param seg  Segment handle
  *
  * @return  Segment buffer length in bytes
  *
  * @see odp_packet_seg_buf_addr()
  */
-uint32_t odp_packet_seg_buf_len(odp_packet_t pkt, odp_packet_seg_t seg);
+uint32_t odp_packet_seg_buf_len(odp_packet_seg_t seg);
 
 /**
  * Segment data pointer
  *
  * Returns pointer to the first byte of data in the segment.
  *
- * @param pkt  Packet handle
  * @param seg  Segment handle
  *
  * @return  Pointer to the segment data
@@ -851,21 +891,29 @@ uint32_t odp_packet_seg_buf_len(odp_packet_t pkt, 
odp_packet_seg_t seg);
  *
  * @see odp_packet_seg_data_len()
  */
-void *odp_packet_seg_data(odp_packet_t pkt, odp_packet_seg_t seg);
+void *odp_packet_seg_data(odp_packet_seg_t seg);
 
 /**
  * Segment data length
  *
  * Returns segment data length in bytes.
  *
- * @param pkt  Packet handle
  * @param seg  Segment handle
  *
  * @return  Segment data length in bytes
  *
  * @see odp_packet_seg_data()
  */
-uint32_t odp_packet_seg_data_len(odp_packet_t pkt, odp_packet_seg_t seg);
+uint32_t odp_packet_seg_data_len(odp_packet_seg_t seg);
+
+
+void *odp_packet_seg_push_head(odp_packet_seg_t seg, uint32_t len);
+
+void *odp_packet_seg_pull_head(odp_packet_seg_t seg, uint32_t len);
+
+void *odp_packet_seg_push_tail(odp_packet_seg_t seg, uint32_t len);
+
+void *odp_packet_seg_pull_tail(odp_packet_seg_t seg, uint32_t len);
 
 
 /*
@@ -875,6 +923,24 @@ uint32_t odp_packet_seg_data_len(odp_packet_t pkt, 
odp_packet_seg_t seg);
  *
  */
 
+/**
+ * Insert segment into packet at an offset
+ *
+ * Links a segment into packet. Operation updates data pointers, offsets and
+ * lengths, but not other packet metadata (e.g. L2/L3/L4 offsets and pointers).
+ * The packet is not modified on an error.
+ *
+ * Segment must have been allocated from the same pool as the packet.
+ *
+ * @param pkt Packet handle
+ * @param offset  Byte offset into the packet
+ * @param seg Segment to be added into the offset
+ *
+ * @retval 0 on success
+ * @retval !0 on failure
+ */
+int odp_packet_add_seg(odp_packet_t pkt, uint32_t offset,
+  odp_packet_seg_t seg);
 
 /**
  * Add data into an offset
-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org

[lng-odp] Driver interface definition...

[Christophe Milard]

Hi,



Today the situation as I see it, is as follows:

We have a single interface to ODP, the application interface, A.

This interface is defined by a file which any application includes:
include/odp.h


 includes in turn a set of
platform//include/odp/.
These files are given a chance to define platform specific types by

including platform//include/odp/plat/.h, do their

own definitions (such as inlines functions) and finishes by including

/odp/include/odp/api/, which will mainly have for effect to check

that the platform definitions do match the generic api definition.



With the driver interface being defined, we are about to add another
interface
D (D as driver).

It seems that some of you would like to have a /odp/include/odp/D directory

which would contains driver specific , e.g. dma.h.

While I understand the wish to keep interface separated, I am not conviced

that this really fits the job...:

How does this new directory work?.

an include file, called D.h (at the same level as odp.h, it seems we could

 agree here) would include what from the platform?

platform//include/D/? which in turn would include:

platform//include/D/plat/.h and finally
/odp/include/odp/api_D/?
OK. that works. maybe complicated but does work. But more to the point:
what
is the criteria for the modules to be in the A (normal appli api) or D
directory?
D directories would contain any module just included by the D interface

whereas A directories woud contain modules either part of A and D or A
only?
This overlap is where I see the main issue: What if an X interface has to
be
created in the future (Petri named open stack as an exemple), and Y and Z?

All partly overlapping... What will be the criteria to place the different

modules (m.h) in the A, D,X, Y or Z directories? I cannot see that growing
well...
Also the function prefix would get messy: should a function used in the A
and D
 and Y interface be called A_f(), D_f(), Y_f() or ADY_f()? and change name
when Z comes?


The other approach (chosen by the patch serie, but actually not fully

implemented there) is different:

platform//include/odp/*

platform//include/odp/plat/.h

and /odp/include/odp/api/ (which we should rename EPI (instead of
API)
maybe, for External Programing Interface) would define all functions
exported
by ODP. On ANY interface.

All these functions are prefixed by odp_*. as today. Saddly, one cannot
tell by
the name of function only which interface it belongs to.

That actually makes sense as we accept functions to be part of many
interfaces
at the same time.



The file include/odp/.h (e.g. Api.h, driver.h X.h,Y.h or
Z.h)
just lists the functions (module .h files, that may have to be splitted if

modules define function for different interfaces) belonging to that
interface.


Overlap is no longer a problem and directory contents becomes clear and

well defined.



The definition on each interface is done by the interface ".h" file.

not a directory.

Does it matter?

Overlap is clean: the corresponding module symply being listed many times
in the
different interface definition files they belong to.

Less directories, and no question on where a module belonging to interface

A,D Z,Y or Z should end-up.

Specific directories and function prefix make only sense to me when the

interfaces do not overlap, or overlapping functions get aliases

(A_f() and D_f() being the same).

Thanks for reading. Hope we'll find the optimal solution together.



/Christophe.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] Regarding running the new traffic_mngr tests.

[Alexandru Badicioiu]

Hi Barry,
thanks for all these details and explanations.
Regarding enhanced API for finding HW configurations those are meant to
help in creating portable HW-accelerated applications. The changes may be
modest but the goal is not, I think.
A high level description of these changes :
- set egress of a TM system independently of creation
- get capabilities of a given level in a HW TM system, motivated by the
fact that different levels may have different features
- introduce a maximum and minimum level of levels for a TM systems
- not an API change per-se, but I think it's necessary to clearly document
that the TM tree creation may not be possible in any order , so that a
level N node  should be completely configured before it's N+1 level
children are created
- changing TM queue parameters after configuration may not be always
possible
- updating a shared profile may not always update all objects (TM nodes)
which use that profile
- allow local priorities, configurable or not by the user
- clarify use of sched params for case when odp_tm_queue_sched_config is
used - in this case the only first weight in the sched_weight array should
be considered by the implementation (cannot have multiple weights on a
single TM queue). However, another question is what is the best way to
configure different weights on different queues (with the same prio) - use
a new profile, use odp_tm_sched_params_update ?

Thanks,
Alex




On 9 January 2016 at 17:46, Barry Spinney  wrote:

>
> I just realized that I neglected to add a README to the
>
> new "test/validation/traffic_mngr" directory explaining how
>
> to run these tests.  Basically the simple answer is "the same
>
> as the pktio tests", since much of the initial pktio setup code
>
> came from the pktio tests.  But of course since the code for
>
> these tests can diverge, the traffic_mngr tests need their
>
> README.  There are 3 different ways to configure the pktio
>
> and traffic_mngr tests, but I cam only going to discuss one
>
> of them - namely the one I have done the most testing
>
> with and so I have the most confidence in.
>
>
> Basically need a box with a pair of 1 Gbps or 10 Gbps links.
>
> Connect these two interfaces with a cable, so that everything
>
> sent by one interface will be received by the other.  Then
>
> set the two environment variables - ODP_PKTIO_IF0 and
>
> ODP_PKTIO_IF1 - to contain the names of the two interfaces.
>
> Then run the pktio tests to prove that these are set correctly,
>
> and that the odp pktio systems is happy with the interface
>
> names and has access (often means test needs to be run as
>
> root).  If you can't get the pktio tests to open these links
>
> and send and receive traffic, there is probably no point to
>
> trying the traffic_mngr tests.
>
>
> Also regarding the enhancement of the traffic_mngr tests
>
> to support an improved API for finding HW configurations,
>
> that should be considered a separate follow on piece of
>
> work involving modest changes both to the API header files,
>
> the implementation, the example and the test.  But first we
>
> collectively need to agree on EXACTLY what should change
>
> in the API ala your feedback.  I was planning on sending
>
> a request for comment email prior to Tuesday mornings
>
> call with a proposed change (or maybe even a couple of
>
> proposals).  But I don't think this should hold up the
>
> acceptance of the existing patch set into the git repo.
>
> A lot easier to patch something that has been added to
>
> the git repo that patching a set of ongoing patches.
>
>
> Regarding the testing of hierarchical WRED - I deferred this since
>
> I had the impression that many vendors didn't support this
>
> and so its importance was a bit little.  Of course there is
>
> a fairly substantial set of tests of normal (tm_queue based)
>
> WRED.  This is particularly tricky given the fact the WRED is
>
> inherently random and so the test has to deal with the fact
>
> that which pkts get dropped (and even the number of pkts
>
> dropped) is not predictable!
>
>
> Thanx Barry.
>
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] doc: implementers-guide: libC version

[Mike Holmes]

On 11 January 2016 at 04:47, Christophe Milard  wrote:

> Limiting the usage of the C library to the functions defined in its
> C99 version.
>
> Signed-off-by: Christophe Milard 
>

Reviewed-by: Mike Holmes 


> ---
>  doc/implementers-guide/implementers-guide.adoc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/implementers-guide/implementers-guide.adoc
> b/doc/implementers-guide/implementers-guide.adoc
> index de0b9b1..eb076cf 100644
> --- a/doc/implementers-guide/implementers-guide.adoc
> +++ b/doc/implementers-guide/implementers-guide.adoc
> @@ -90,7 +90,9 @@ This grouping defines tests that are expected to be
> executable and succeed on
>  any platform, though possibly with very different performances, depending
> on the
>  underlying platform.
>  They are written in plain C code, and may only use functions defined in
> the
> -standard libC library (besides the ODP functions being tested, of course).
> +standard libC (C99) library (besides the ODP functions being tested, of
> course).
> +A free C99 specification can be found at
> +http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf.
>  No other languages (like scripting) are allowed as their usage would make
>  assumptions on the platform capability.
>
> --
> 2.1.4
>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] doc: process: add byelaws

[Maxim Uvarov]

bellow are small notes but it's better to clean up it now.

Maxim.

On 01/07/2016 22:17, Mike Holmes wrote:

The bylaws were only recorded as part of the website, move them to git
where they can be tracked.

Signed-off-by: Mike Holmes 
---
  doc/process-guide/Makefile.am   |  10 ++--
  doc/process-guide/bylaws-guide.adoc | 104 
  2 files changed, 110 insertions(+), 4 deletions(-)
  create mode 100644 doc/process-guide/bylaws-guide.adoc

diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am
index 54e2c1d..1ac32da 100644
--- a/doc/process-guide/Makefile.am
+++ b/doc/process-guide/Makefile.am
@@ -1,11 +1,13 @@
-TARGET = $(top_srcdir)/doc/output/release-guide.html
+TARGET = $(top_srcdir)/doc/output/release-guide.html 
$(top_srcdir)/doc/output/bylaws-guide.html

please do it in 2 lines (better to see later diffs), and alphabetical order.
  
-EXTRA_DIST = release-guide.adoc

+EXTRA_DIST = release-guide.adoc bylaws-guide.adoc

please do it in 2 lines (better to see later diffs), and alphabetical order.

  
  all-local: $(TARGET)
  
-$(TARGET): release-guide.adoc

-   @mkdir -p $(top_srcdir)/doc/output
+$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc
+   asciidoc -b html5  -a icons -a toc2  -a max-width=55em --out-file=$@ $<
+
+$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc
asciidoc -b html5  -a icons -a toc2  -a max-width=55em --out-file=$@ $<
  
  clean-local:

diff --git a/doc/process-guide/bylaws-guide.adoc 
b/doc/process-guide/bylaws-guide.adoc
new file mode 100644
index 000..91411da
--- /dev/null
+++ b/doc/process-guide/bylaws-guide.adoc
@@ -0,0 +1,104 @@
+OpenDataPlane (ODP) Bylaws-Guide
+
+:toc:
+
+:numbered!:
+[abstract]
+Abstract
+
+This document is intended to guide a new application developer in
+understanding the bylaws

dot is missing.

In some places you have "bylaws" but in other "by-laws".  Dictionary 
says that hyphen has to be used.

Please fix it everywhere in doc.



+
+The ODP project has established a set of by-laws defining the operational
+processes by which direction of ODP resources is determined and how the product
+is managed.
+
+The by-laws define roles, stewardship/management, patch approvals, voting
+procedures, and reporting (Roadmap) requirements.
+
+Further details about ODP may be found at the http://opendataplane.org[ODP]
+home page.
+
+:numbered:
+
+== Roles considered
+=== Users


How about name it: Users (ODP Applications developers).



+People that use the project and submit bugs and request new features to the
+project.
+
+=== Contributors
+All of the volunteers who are contributing time, code, documentation, or
+resources to the project. A contributor that makes sustained, welcome
+contributions to the project may be invited to become a maintainer, though the
+exact timing of such invitations depends on many factors.
+
+If a contributor wants to move the project in direction X or add feature Y, and
+that requires a lot of rewrite in the existing code-base then:
+
+* explain that in an email to the mailing list.
+* send out RFCs (early and often) with example code, so the community (and
+maintainers) can see what you want and say if it fits or not.
+
+The above helps find and solve common problems among contributors.
+
+=== Maintainer(s)
+* The maintainer for a project have push rights to the main repo. Only one
+maintainer. The most trustworthy sub-maintainer shall step in and take over the
+maintainer ship as required.
+* Sub-maintainer(s) one or many for the different modules in the project.
+* Sub-maintainers shall focus on ensuring that the current code base has good
+quality and review new patches to maintain that good quality.
+* When Maintainers accept code, they have to deal with it until they die or rip
+it out (so its important that they understand what the code does and why they
+need it). The contributor shall convince the maintainer to take their code (the
+maintainer should feel like he would be stupid to not accept the code…)
+
+=== Release Manager ===
+
+* The RM shall publish a Release Plan on the roadmap. One week before the
+release the candidate list will be reviewed.
+* The RM is responsible for building consensus around the content of the
+Release.
+
+== Roadmap
+The roadmap shall state projected future releases and the expected content.
+
+== Steering Committee (SC)
+* Maintaining the project’s shared resources, email lists and the homepage.
Maybe maintain is not right word here. Technically work operating of 
that services
maintained by Linaro IT team. SC probably defines requirements for 
project support services.



+* Speaking on behalf of the project.
+* Resolving license disputes regarding products of the project.
+* Nominating new PMC members and committers.
+* Maintaining these bylaws and other guidelines of the project.
+* Planning the roadmap (shall state 

Re: [lng-odp] [PATCH] doc: process: add byelaws

[Mike Holmes]

On 11 January 2016 at 14:31, Maxim Uvarov  wrote:

> bellow are small notes but it's better to clean up it now.
>
> Maxim.
>
> On 01/07/2016 22:17, Mike Holmes wrote:
>
>> The bylaws were only recorded as part of the website, move them to git
>> where they can be tracked.
>>
>> Signed-off-by: Mike Holmes 
>> ---
>>   doc/process-guide/Makefile.am   |  10 ++--
>>   doc/process-guide/bylaws-guide.adoc | 104
>> 
>>   2 files changed, 110 insertions(+), 4 deletions(-)
>>   create mode 100644 doc/process-guide/bylaws-guide.adoc
>>
>> diff --git a/doc/process-guide/Makefile.am b/doc/process-guide/Makefile.am
>> index 54e2c1d..1ac32da 100644
>> --- a/doc/process-guide/Makefile.am
>> +++ b/doc/process-guide/Makefile.am
>> @@ -1,11 +1,13 @@
>> -TARGET = $(top_srcdir)/doc/output/release-guide.html
>> +TARGET = $(top_srcdir)/doc/output/release-guide.html
>> $(top_srcdir)/doc/output/bylaws-guide.html
>>
> please do it in 2 lines (better to see later diffs), and alphabetical
> order.


Thanks


>
>   -EXTRA_DIST = release-guide.adoc
>> +EXTRA_DIST = release-guide.adoc bylaws-guide.adoc
>>
> please do it in 2 lines (better to see later diffs), and alphabetical
> order.



Thanks


>
>
> all-local: $(TARGET)
>>   -$(TARGET): release-guide.adoc
>> -   @mkdir -p $(top_srcdir)/doc/output
>> +$(top_srcdir)/doc/output/release-guide.html: release-guide.adoc
>> +   asciidoc -b html5  -a icons -a toc2  -a max-width=55em
>> --out-file=$@ $<
>> +
>> +$(top_srcdir)/doc/output/bylaws-guide.html: bylaws-guide.adoc
>> asciidoc -b html5  -a icons -a toc2  -a max-width=55em
>> --out-file=$@ $<
>> clean-local:
>> diff --git a/doc/process-guide/bylaws-guide.adoc
>> b/doc/process-guide/bylaws-guide.adoc
>> new file mode 100644
>> index 000..91411da
>> --- /dev/null
>> +++ b/doc/process-guide/bylaws-guide.adoc
>> @@ -0,0 +1,104 @@
>> +OpenDataPlane (ODP) Bylaws-Guide
>> +
>> +:toc:
>> +
>> +:numbered!:
>> +[abstract]
>> +Abstract
>> +
>> +This document is intended to guide a new application developer in
>> +understanding the bylaws
>>
> dot is missing.
>
>
Thanks


> In some places you have "bylaws" but in other "by-laws".  Dictionary says
> that hyphen has to be used.
> Please fix it everywhere in doc.


Thanks - will unify


>
>
>
> +
>> +The ODP project has established a set of by-laws defining the operational
>> +processes by which direction of ODP resources is determined and how the
>> product
>> +is managed.
>> +
>> +The by-laws define roles, stewardship/management, patch approvals, voting
>> +procedures, and reporting (Roadmap) requirements.
>> +
>> +Further details about ODP may be found at the http://opendataplane.org
>> [ODP]
>> +home page.
>> +
>> +:numbered:
>> +
>> +== Roles considered
>> +=== Users
>>
>
> How about name it: Users (ODP Applications developers).


Maybe, we will likely have driver developer's, implementation developers
and application developers, dont we need a term for all of them as users of
the API


>
>
>
> +People that use the project and submit bugs and request new features to
>> the
>> +project.
>> +
>> +=== Contributors
>> +All of the volunteers who are contributing time, code, documentation, or
>> +resources to the project. A contributor that makes sustained, welcome
>> +contributions to the project may be invited to become a maintainer,
>> though the
>> +exact timing of such invitations depends on many factors.
>> +
>> +If a contributor wants to move the project in direction X or add feature
>> Y, and
>> +that requires a lot of rewrite in the existing code-base then:
>> +
>> +* explain that in an email to the mailing list.
>> +* send out RFCs (early and often) with example code, so the community
>> (and
>> +maintainers) can see what you want and say if it fits or not.
>> +
>> +The above helps find and solve common problems among contributors.
>> +
>> +=== Maintainer(s)
>> +* The maintainer for a project have push rights to the main repo. Only
>> one
>> +maintainer. The most trustworthy sub-maintainer shall step in and take
>> over the
>> +maintainer ship as required.
>> +* Sub-maintainer(s) one or many for the different modules in the project.
>> +* Sub-maintainers shall focus on ensuring that the current code base has
>> good
>> +quality and review new patches to maintain that good quality.
>> +* When Maintainers accept code, they have to deal with it until they die
>> or rip
>> +it out (so its important that they understand what the code does and why
>> they
>> +need it). The contributor shall convince the maintainer to take their
>> code (the
>> +maintainer should feel like he would be stupid to not accept the code…)
>> +
>> +=== Release Manager ===
>> +
>> +* The RM shall publish a Release Plan on the roadmap. One week before the
>> +release the candidate list will be reviewed.
>> +* The RM is responsible for building consensus around the