Re: [lng-odp] DDF discussions taking time

[Honnappa Nagarahalli]

On 26 October 2017 at 16:34, Bill Fischofer  wrote:
> I agree with Maxim. Best to get one or two working drivers and see what else
> is needed. The intent here is not for ODP to become another OS, so I'm not
> sure why we need to concern ourselves with bus walking and similar arcana.
> Linux has already long solved this problem. We should leverage what's there,
> not try to reinvent it.
>
> ODP applications are told what I/O interfaces to use, either through an
> application configuration file, command line, or other means outside the
> scope of ODP itself. ODP's job is simply to connect applications to these
> configured I/O interfaces when they call odp_pktio_open(). The name used for
> interfaces is simply a string that we've defined to have the format:
>
> class: device: other-info-needed-by-driver
>
> We've defined a number of classes already:
>
> - loop
> - pcap
> - ipc
> - dpdk
> - socket
> - socket_mmap
> - tap
> etc.
>
> We simply need to define new classes (e.g., ddf, mdev) and the names they
> need to take to identify a specific device and the associated driver to use
> for operate that device. The driver is then loaded if necessary and its
> open() interface is called.
>

Coincidentally, internally we were discussing this exactly.

Why do we need to scan and understand the complete platform during
initialization? - I would think, mostly, ODP will run in a platform
(baremetal, VM, container) where all the devices are supposed to be
used by ODP (i.e. ODP will not run in a platform where it will share
the platform with other applications). So why not scan and identify
the devices/drivers and create the packet IO ops during
initialization. The packet I/O framework assumes that various methods
(open, close, send, recv etc) of the device driver are known when
odp_pktio_open API is called. None of that has to change.

Another solution I can think of is (tweak to reduce the time spent in
scanning etc), instead of scanning all the devices, DDF initialization
function can be provided with all the ports the user has requested.

If the scanning for the device and identifying the driver has to be
triggered through the odp_pktio_open API, the current packet IO
framework needs to change.

> On Thu, Oct 26, 2017 at 3:59 PM, Maxim Uvarov 
> wrote:
>>
>> Hello Honnappa,
>>
>> I think we also need to take a look from bottom. I.e. from exact drivers
>> to
>> implement. That it will be more clear which interface is needed to be
>> created.
>> Do you have some list of drivers which needed to be implemented? I.e. with
>> pci drivers I think we in a good way, but non pci drivers are under
>> question.
>> I think we should not over-complicate odp itself with huge discovery and
>> numeration of devices. Let's take a look what is the minimal interface to
>> support
>> devices.
>>
>> Best regards,
>> Maxim.
>>
>> On 26 October 2017 at 23:35, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> wrote:
>>
>> > Hi,
>> >Agree, we have taken 2 hours and the progress has been slow. But
>> > the discussions have been good and helpful to us at Arm. The goal is
>> > to identify the gaps and work items. I am not sure if it has been
>> > helpful to others, please let me know.
>> >
>> > To speed this up, I propose few options below, let me know your opinion:
>> >
>> > 1) Have 2 additional (along with regular ODP 2.0) calls next week - We
>> > can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
>> > time, GMT-6, one hour before the regular ODP-2.0)
>> >
>> > 2) Resolve the pending PRs on emails
>> >
>> > 3) Discuss the DDF slides on email - Not sure how effective it will be
>> >
>> > Any other solutions?
>> >
>> > Thank you,
>> > Honnappa
>> >
>
>

Re: [lng-odp] DDF discussions taking time

[Honnappa Nagarahalli]

Hi Bill/Maxim,
These are the exact decisions I wanted us to make coming out of
this discussion. I have taken some what of a longer route, i.e.
examine the DDF design and understand the idea/thinking on why
somethings were created.

We are almost there, we do not have many more slides to cover, another
1.5 slides to cover and the last slide is about few changes Jianbo has
identified.

I expect that, after this discussion, we will identify what are the
gaps, which parts can we let go.

Thank you,
Honnappa

On 26 October 2017 at 16:34, Bill Fischofer  wrote:
> I agree with Maxim. Best to get one or two working drivers and see what else
> is needed. The intent here is not for ODP to become another OS, so I'm not
> sure why we need to concern ourselves with bus walking and similar arcana.
> Linux has already long solved this problem. We should leverage what's there,
> not try to reinvent it.
>
> ODP applications are told what I/O interfaces to use, either through an
> application configuration file, command line, or other means outside the
> scope of ODP itself. ODP's job is simply to connect applications to these
> configured I/O interfaces when they call odp_pktio_open(). The name used for
> interfaces is simply a string that we've defined to have the format:
>
> class: device: other-info-needed-by-driver
>
> We've defined a number of classes already:
>
> - loop
> - pcap
> - ipc
> - dpdk
> - socket
> - socket_mmap
> - tap
> etc.
>
> We simply need to define new classes (e.g., ddf, mdev) and the names they
> need to take to identify a specific device and the associated driver to use
> for operate that device. The driver is then loaded if necessary and its
> open() interface is called.
>
> On Thu, Oct 26, 2017 at 3:59 PM, Maxim Uvarov 
> wrote:
>>
>> Hello Honnappa,
>>
>> I think we also need to take a look from bottom. I.e. from exact drivers
>> to
>> implement. That it will be more clear which interface is needed to be
>> created.
>> Do you have some list of drivers which needed to be implemented? I.e. with
>> pci drivers I think we in a good way, but non pci drivers are under
>> question.
>> I think we should not over-complicate odp itself with huge discovery and
>> numeration of devices. Let's take a look what is the minimal interface to
>> support
>> devices.
>>
>> Best regards,
>> Maxim.
>>
>> On 26 October 2017 at 23:35, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> wrote:
>>
>> > Hi,
>> >Agree, we have taken 2 hours and the progress has been slow. But
>> > the discussions have been good and helpful to us at Arm. The goal is
>> > to identify the gaps and work items. I am not sure if it has been
>> > helpful to others, please let me know.
>> >
>> > To speed this up, I propose few options below, let me know your opinion:
>> >
>> > 1) Have 2 additional (along with regular ODP 2.0) calls next week - We
>> > can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
>> > time, GMT-6, one hour before the regular ODP-2.0)
>> >
>> > 2) Resolve the pending PRs on emails
>> >
>> > 3) Discuss the DDF slides on email - Not sure how effective it will be
>> >
>> > Any other solutions?
>> >
>> > Thank you,
>> > Honnappa
>> >
>
>

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

Dmitry Eremin-Solenikov(lumag) replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
@muvarov they do not mention any compiler errors, so they are useless in trying 
to understand, which errors were there.

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> It's never wrong to use the PRIxxx macros so that's the safest and most 
> portable way to go. So I'm happy to see them used here and we should try to 
> use them in new development that calls for these sort of conversions.


>> muvarov wrote
>> @lumag  compilation errors. So we have comits:
>>  27a05a1d61f3b7e4d5
>> 
>> 42d0b99c453f269f
>> 
>> d25d276c649f57021f


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> @muvarov could you please be more specific? What kind of problems?


 muvarov wrote
 we had some problems with that prints in the past. Arm build or -m32 do 
 not remember exactly what it was.


> Dmitry Eremin-Solenikov(lumag) wrote:
> My understanding is that `PRIu32/PRIu16` are not required, you can always 
> use `%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact 
> `uint64_t` definition depends on platform ABI.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Is there any reason for printing into the string buffer, rather than 
>> calling `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147280744
updated_at 2017-10-26 22:08:11

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

[Bill Fischofer]

I think you've captured the distinction correctly. The larger question is
what does ODP itself need to do with this? When an interface name is
presented to odp_pktio_open() it is the application's responsibility to
provide a name string that can be mapped to the device that should be
opened. ODP uses that string to locate / load the driver that's needed to
operate that device. The driver is then responsible to make the actual
connection to the device.

When a driver gets a "device string" is needs to translate that into either
an appropriate Linux system call (for mdev) or to a set of PCI Bar or other
HW register addresses (for dedicated I/O). So if there is a case of a
southbound ODP API, it would be to assist with this latter translation.

On Thu, Oct 26, 2017 at 12:38 PM, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Hi,
>I created a document to convert our discussion into pictures. I
> will update this as we discuss other concepts like devio/driver etc.
>
> https://docs.google.com/a/linaro.org/document/d/1nzy-Qp6hYZU38DVi7_
> ZnPiaf3jRqdMN6IQHmfO80Al4/edit?usp=sharing
>
> Thanks,
> Honnappa
>

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
It's never wrong to use the PRIxxx macros so that's the safest and most 
portable way to go. So I'm happy to see them used here and we should try to use 
them in new development that calls for these sort of conversions.

> muvarov wrote
> @lumag  compilation errors. So we have comits:
>  27a05a1d61f3b7e4d5
> 
> 42d0b99c453f269f
> 
> d25d276c649f57021f


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> @muvarov could you please be more specific? What kind of problems?


>>> muvarov wrote
>>> we had some problems with that prints in the past. Arm build or -m32 do not 
>>> remember exactly what it was.


 Dmitry Eremin-Solenikov(lumag) wrote:
 My understanding is that `PRIu32/PRIu16` are not required, you can always 
 use `%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact 
 `uint64_t` definition depends on platform ABI.


> Dmitry Eremin-Solenikov(lumag) wrote:
> Is there any reason for printing into the string buffer, rather than 
> calling `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147278329
updated_at 2017-10-26 21:55:37

Re: [lng-odp] DDF discussions taking time

[Bill Fischofer]

I agree with Maxim. Best to get one or two working drivers and see what
else is needed. The intent here is not for ODP to become another OS, so I'm
not sure why we need to concern ourselves with bus walking and similar
arcana. Linux has already long solved this problem. We should leverage
what's there, not try to reinvent it.

ODP applications are told what I/O interfaces to use, either through an
application configuration file, command line, or other means outside the
scope of ODP itself. ODP's job is simply to connect applications to these
configured I/O interfaces when they call odp_pktio_open(). The name used
for interfaces is simply a string that we've defined to have the format:

class: device: other-info-needed-by-driver

We've defined a number of classes already:

- loop
- pcap
- ipc
- dpdk
- socket
- socket_mmap
- tap
etc.

We simply need to define new classes (e.g., ddf, mdev) and the names they
need to take to identify a specific device and the associated driver to use
for operate that device. The driver is then loaded if necessary and its
open() interface is called.

On Thu, Oct 26, 2017 at 3:59 PM, Maxim Uvarov 
wrote:

> Hello Honnappa,
>
> I think we also need to take a look from bottom. I.e. from exact drivers to
> implement. That it will be more clear which interface is needed to be
> created.
> Do you have some list of drivers which needed to be implemented? I.e. with
> pci drivers I think we in a good way, but non pci drivers are under
> question.
> I think we should not over-complicate odp itself with huge discovery and
> numeration of devices. Let's take a look what is the minimal interface to
> support
> devices.
>
> Best regards,
> Maxim.
>
> On 26 October 2017 at 23:35, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
> > Hi,
> >Agree, we have taken 2 hours and the progress has been slow. But
> > the discussions have been good and helpful to us at Arm. The goal is
> > to identify the gaps and work items. I am not sure if it has been
> > helpful to others, please let me know.
> >
> > To speed this up, I propose few options below, let me know your opinion:
> >
> > 1) Have 2 additional (along with regular ODP 2.0) calls next week - We
> > can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
> > time, GMT-6, one hour before the regular ODP-2.0)
> >
> > 2) Resolve the pending PRs on emails
> >
> > 3) Discuss the DDF slides on email - Not sure how effective it will be
> >
> > Any other solutions?
> >
> > Thank you,
> > Honnappa
> >
>

Re: [lng-odp] DDF discussions taking time

[Maxim Uvarov]

Hello Honnappa,

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

Best regards,
Maxim.

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

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

[lng-odp] DDF discussions taking time

[Honnappa Nagarahalli]

Hi,
   Agree, we have taken 2 hours and the progress has been slow. But
the discussions have been good and helpful to us at Arm. The goal is
to identify the gaps and work items. I am not sure if it has been
helpful to others, please let me know.

To speed this up, I propose few options below, let me know your opinion:

1) Have 2 additional (along with regular ODP 2.0) calls next week - We
can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
time, GMT-6, one hour before the regular ODP-2.0)

2) Resolve the pending PRs on emails

3) Discuss the DDF slides on email - Not sure how effective it will be

Any other solutions?

Thank you,
Honnappa

[lng-odp] Relation between Enumerator class and Enumerator

[Honnappa Nagarahalli]

Hi,
   I created a document to convert our discussion into pictures. I
will update this as we discuss other concepts like devio/driver etc.

https://docs.google.com/a/linaro.org/document/d/1nzy-Qp6hYZU38DVi7_ZnPiaf3jRqdMN6IQHmfO80Al4/edit?usp=sharing

Thanks,
Honnappa

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

muvarov replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
@lumag  compilation errors. So we have comits:
 27a05a1d61f3b7e4d5

42d0b99c453f269f

d25d276c649f57021f


> Dmitry Eremin-Solenikov(lumag) wrote:
> @muvarov could you please be more specific? What kind of problems?


>> muvarov wrote
>> we had some problems with that prints in the past. Arm build or -m32 do not 
>> remember exactly what it was.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> My understanding is that `PRIu32/PRIu16` are not required, you can always 
>>> use `%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact 
>>> `uint64_t` definition depends on platform ABI.


 Dmitry Eremin-Solenikov(lumag) wrote:
 Is there any reason for printing into the string buffer, rather than 
 calling `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147194103
updated_at 2017-10-26 16:18:08

[lng-odp] [PATCH API-NEXT v1 1/1] shippable: add libconfig and libnuma

[Github ODP bot]

From: Maxim Uvarov 

add libconfig and libnuma for docker image for api-next.

Signed-off-by: Maxim Uvarov 
---
/** Email created from pull request 262 (muvarov:api-next_shippable)
 ** https://github.com/Linaro/odp/pull/262
 ** Patch: https://github.com/Linaro/odp/pull/262.patch
 ** Base sha: d61d32590d1772b70b8dcd0d0ec44d29029d7443
 ** Merge commit sha: 994179feeb8121a96a433e6be9bb8f5acbf7f105
 **/
 scripts/Dockerfile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/Dockerfile b/scripts/Dockerfile
index 995330fa0..b15282aaf 100644
--- a/scripts/Dockerfile
+++ b/scripts/Dockerfile
@@ -12,12 +12,14 @@ RUN sudo apt-get update && sudo apt-get install -yy \
   gcc-4.8 \
   graphviz \
   kmod \
-  mscgen \
+  libconfig-dev \
   libcunit1-dev \
+  libnuma-dev \
   libpcap-dev \
   libssl-dev \
   libtool \
   linux-headers-`uname -r` \
+  mscgen \
   ruby-dev
 
 RUN sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10

[lng-odp] [PATCH API-NEXT v1 0/1] shippable: add libconfig and libnuma

[Github ODP bot]

add libconfig and libnuma for docker image for api-next.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org

github
/** Email created from pull request 262 (muvarov:api-next_shippable)
 ** https://github.com/Linaro/odp/pull/262
 ** Patch: https://github.com/Linaro/odp/pull/262.patch
 ** Base sha: d61d32590d1772b70b8dcd0d0ec44d29029d7443
 ** Merge commit sha: 994179feeb8121a96a433e6be9bb8f5acbf7f105
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 15 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [Linaro/odp] 3edee3: linux-gen: packet: add debugging asserts in packet...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 3edee38da55876e36f654a5d1a4b87c2ea5b8bfe
  
https://github.com/Linaro/odp/commit/3edee38da55876e36f654a5d1a4b87c2ea5b8bfe
  Author: Bill Fischofer 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

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

  Log Message:
  ---
  linux-gen: packet: add debugging asserts in packet code

Restore the ODP_ASSERTS() that assist application debugging that were
lost in the recent packet reference rework. When using --enable-debug
insert guards to detect duplicate packet frees as well as attempts to
modify known shared data sections of packet references.

Signed-off-by: Bill Fischofer 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 

[lng-odp] [Bug 3289] [PKTIO] 'num_queues' isn't ignored when ''classifier_enable' is enabled

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[lng-odp] [Bug 2254] check-odp: valgrind generates "No rule to make target"

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

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

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

muvarov replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
we had some problems with that prints in the past. Arm build or -m32 do not 
remember exactly what it was.

> Dmitry Eremin-Solenikov(lumag) wrote:
> My understanding is that `PRIu32/PRIu16` are not required, you can always use 
> `%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact `uint64_t` 
> definition depends on platform ABI.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Is there any reason for printing into the string buffer, rather than calling 
>> `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147152491
updated_at 2017-10-26 14:09:26

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

Dmitry Eremin-Solenikov(lumag) replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
@muvarov could you please be more specific? What kind of problems?

> muvarov wrote
> we had some problems with that prints in the past. Arm build or -m32 do not 
> remember exactly what it was.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> My understanding is that `PRIu32/PRIu16` are not required, you can always 
>> use `%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact 
>> `uint64_t` definition depends on platform ABI.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Is there any reason for printing into the string buffer, rather than 
>>> calling `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147154654
updated_at 2017-10-26 14:16:11

[lng-odp] [Bug 3242] setup_pktio_entry missing unlock

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[lng-odp] [Bug 3337] ./test/linux-generic/run-test is not used

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Maxim Uvarov  ---
Closed.

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

[lng-odp] [Bug 3343] aarch64 timer test fails

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Maxim Uvarov  ---
Issued resolved. Closed.

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

[lng-odp] [Linaro/odp] 8d22e0: doc: userguide: add section on api specification p...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 8d22e0e2013596403ae6a35457cdf30b0a0c559b
  
https://github.com/Linaro/odp/commit/8d22e0e2013596403ae6a35457cdf30b0a0c559b
  Author: Bill Fischofer 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M doc/users-guide/users-guide.adoc

  Log Message:
  ---
  doc: userguide: add section on api specification principles

Add section to the User Guide that highlights that unless otherwise
documented, API behavior is undefined if applications pass invalid
parameters to them.

Signed-off-by: Bill Fischofer 
Reviewed-by: Petri Savolainen 

[lng-odp] [Linaro/odp] 4fafec: linux-gen: netmap: use thread id to make vdev mac ...

[GitHub]

  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 4fafec8378b6e7d0b353d851e724ab27eb002b27
  
https://github.com/Linaro/odp/commit/4fafec8378b6e7d0b353d851e724ab27eb002b27
  Author: Matias Elo 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M platform/linux-generic/pktio/netmap.c

  Log Message:
  ---
  linux-gen: netmap: use thread id to make vdev mac addresses unique

Previously the mac addresses of virtual netmap devices would clash if
multiple odp processes were run on the same host.

Signed-off-by: Matias Elo 
Signed-off-by: Bill Fischofer 


  Commit: bd1b1adf37dd8d252f7daf761d4ae9a6d1ef156a
  
https://github.com/Linaro/odp/commit/bd1b1adf37dd8d252f7daf761d4ae9a6d1ef156a
  Author: Matias Elo 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M platform/linux-generic/pktio/netmap.c

  Log Message:
  ---
  linux-gen: netmap: remove minimum frame len check

Checking the minimum frame length is unnecessary as netmap drops truncated
frames internally.

Signed-off-by: Matias Elo 
Signed-off-by: Bill Fischofer 


  Commit: 66b363634fe1bba003cdb9e4e49a5980fc8c79f4
  
https://github.com/Linaro/odp/commit/66b363634fe1bba003cdb9e4e49a5980fc8c79f4
  Author: Sachin Saxena 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

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

  Log Message:
  ---
  api: pool: Return address range for pool objects

Pool info support has been extented to provide minimum and maximum
addresses of application accessible data for any pool object (event).

Signed-off-by: Sachin Saxena 
Reviewed-by: Petri Savolainen 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: d61d32590d1772b70b8dcd0d0ec44d29029d7443
  
https://github.com/Linaro/odp/commit/d61d32590d1772b70b8dcd0d0ec44d29029d7443
  Author: Maxim Uvarov 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M platform/linux-generic/pktio/netmap.c

  Log Message:
  ---
  Merge branch 'master' into api-next

Signed-off-by: Maxim Uvarov 


Compare: https://github.com/Linaro/odp/compare/63d92eb28926...d61d32590d17

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

Dmitry Eremin-Solenikov(lumag) replied on github web page:

platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");
+   len += snprintf(&str[len], n - len,
+   "  pool index%" PRIu32 "\n", pool->pool_idx);


Comment:
My understanding is that `PRIu32/PRIu16` are not required, you can always use 
`%u/%hu` instead. Only `PRIu64/PRIx64` are required, because exact `uint64_t` 
definition depends on platform ABI.

> Dmitry Eremin-Solenikov(lumag) wrote:
> Is there any reason for printing into the string buffer, rather than calling 
> `ODP_PRINT` directly?


https://github.com/Linaro/odp/pull/258#discussion_r147150364
updated_at 2017-10-26 14:02:24

Re: [lng-odp] [PATCH API-NEXT v1] api: packet: print data

[Github ODP bot]

Dmitry Eremin-Solenikov(lumag) replied on github web page:

platform/linux-generic/odp_packet.c
line 21
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
 
-   str[len] = '\0';
+   ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(odp_packet_t pkt, uint32_t offset,
+  uint32_t byte_len)
+{
+   odp_packet_hdr_t *hdr = packet_hdr(pkt);
+   uint32_t bytes_per_row = 16;
+   int num_rows = (byte_len + bytes_per_row - 1) / bytes_per_row;
+   int max_len = 256 + (3 * byte_len) + (3 * num_rows);
+   char str[max_len];
+   int len = 0;
+   int n = max_len - 1;
+   uint32_t data_len = odp_packet_len(pkt);
+   pool_t *pool = hdr->buf_hdr.pool_ptr;
+
+   len += snprintf(&str[len], n - len, "Packet\n--\n");


Comment:
Is there any reason for printing into the string buffer, rather than calling 
`ODP_PRINT` directly?

https://github.com/Linaro/odp/pull/258#discussion_r147150009
updated_at 2017-10-26 14:02:23

[lng-odp] [PATCH API-NEXT v7 1/1] api: pool: Return address range for pool objects

[Github ODP bot]

From: Sachin Saxena 

Pool info support has been extented to provide minimum and maximum
addresses of application accessible data for any pool object (event).

Signed-off-by: Sachin Saxena 
---
/** Email created from pull request 200 (sachin-saxena:api-next)
 ** https://github.com/Linaro/odp/pull/200
 ** Patch: https://github.com/Linaro/odp/pull/200.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: d02a9cbb3d1bf077dfb901c6ee8f96d1b9f39c2f
 **/
 include/odp/api/spec/pool.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
index 221798ee8..35f783775 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -294,6 +294,22 @@ odp_pool_t odp_pool_lookup(const char *name);
 typedef struct odp_pool_info_t {
const char *name;  /**< pool name */
odp_pool_param_t params;   /**< pool parameters */
+
+   /** Minimum data address.
+* This is the minimum address that application accessible
+* data of any object (event) allocated from the pool may
+* locate. When there's no application accessible data
+* (e.g. ODP_POOL_TIMEOUT pools), the value may be zero.
+*/
+   uintptr_t min_data_addr;
+
+   /** Maximum data address.
+* This is the maximum address that application accessible
+* data of any object (event) allocated from the pool may
+* locate. When there's no application accessible data
+* (e.g. ODP_POOL_TIMEOUT pools), the value may be zero.
+*/
+   uintptr_t max_data_addr;
 } odp_pool_info_t;
 
 /**

[lng-odp] [PATCH API-NEXT v7 0/1] API: Pool: Return address range for pool objects

[Github ODP bot]

Signed-off-by: Sachin Saxena sachin.sax...@linaro.org

github
/** Email created from pull request 200 (sachin-saxena:api-next)
 ** https://github.com/Linaro/odp/pull/200
 ** Patch: https://github.com/Linaro/odp/pull/200.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: d02a9cbb3d1bf077dfb901c6ee8f96d1b9f39c2f
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 22 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

Re: [lng-odp] Ingress Metering/Policing

[Liron Himi]

Hi,

Yes, our HW support TCM offload.

Liron

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim 
Uvarov
Sent: Thursday, October 26, 2017 16:00
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Ingress Metering/Policing

Hello Liron,

does you hardware support TCM offload?

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

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

Regards,
Maxim.

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

Re: [lng-odp] API-next branch

[Maxim Uvarov]

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

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

Maxim.


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

Re: [lng-odp] [PATCH API-NEXT v12] api: classification: add random early detection

[Github ODP bot]

muvarov replied on github web page:

include/odp/api/spec/classification.h
@@ -206,6 +213,43 @@ typedef struct odp_cls_cos_param {
 
/** Drop policy associated with CoS */
odp_cls_drop_t drop_policy;
+
+   /* Random Early Detection (RED)
+* Random Early Detection is enabled to initiate a drop probability


Comment:
@bala-manoharan there was error in check script, I fixed that.

> Petri Savolainen(psavol) wrote:
> "number of packets in pool" == number of free packets or allocated packets? 


>> Petri Savolainen(psavol) wrote:
>> Threshold value meaning and units need to be specified:  packets in queue, 
>> packets allocated from pool. What are the maximum and minimum values of 
>> these? And accuracy is implementation specific?
>> 
>> E.g. pool size 10 000 packet, usually values for min 8000 and max 9 500 
>> could be. Are min 1 and max 100 allowed?


>>> muvarov wrote
>>> +1 moving will also easy to support ABI compat mode.


 Dmitry Eremin-Solenikov(lumag) wrote:
 Commit subject is too long. Also it would be good to mention in commit 
 message that this is a dummy (null) implementation


> Dmitry Eremin-Solenikov(lumag) wrote:
> In my opinion, let's just push it into `odp/api/spec/std_types.h`.


>> Balasubramanian Manoharan(bala-manoharan) wrote:
>> Okay. 
>> @muvarov Travis does not check doxygen?


>>> Balasubramanian Manoharan(bala-manoharan) wrote:
>>> BP in HW is implemented as edge triggered and the interface is 
>>> configured to send Back pressure to the peer when the level increases 
>>> the threshold. Current our HW only supports only threshold value and is 
>>> not monitored as a range.
>>> If any HW later implements this as a range we can add in the future.


 Petri Savolainen(psavol) wrote:
 Although this is single param now, it's better to wrap it into a 
 struct, so that it's easy to add more params later (if needed). Also 
 the 100th percent units should be used.
 
 struct {
   uint16_t ena_threshold;
 } bp;
 
 Could there be other thresholds params later? ena_threshold would 
 leave room for other (high, low, ...etc) threshold params.


> Petri Savolainen(psavol) wrote:
> 
> 
> Missing /**
> 
> "Enable back pressure
> 
> When true, back pressure is enabled and configured with the 
> parameters below.
> Otherwise, back pressure parameters are ignored. When back pressure 
> is enabled 
> for a particular flow, the HW can send back pressure information to 
> the remote 
> peer indicating a network congestion."


>> Petri Savolainen(psavol) wrote:
>> Wrap these two into "struct red". Add missing doxygen tagging. We 
>> should use 100th parts of a percent. So, that API is not bottle neck 
>> if HW can offer higher resolution than 1 percent. TM API uses the 
>> same unit.
>> 
>> /** RED parameters
>> struct {
>>   Maximum threshold percentage for RED in one-hundredths of a 
>> percent. 
>>   Hence 100% is represented as the integer value 1.
>>   uint16_t max_threshold;
>> 
>>   uint16_t min_threshold;
>> } red;


>>> Petri Savolainen(psavol) wrote:
>>> Missing /**
>>> 
>>> "Enable RED
>>> 
>>> When true, RED is enabled and configured with the red parameters 
>>> below.
>>> Otherwise, RED parameters are ignored."


 Petri Savolainen(psavol) wrote:
 Missing Doxygen tag /**
 
 Run 'make doxygen-doc' locally before pushing and correct all 
 doxygen warnings.


> Petri Savolainen(psavol) wrote:
> For consistency, it's better to define probability as 100% here, 
> as we use percents below.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> As noted above, Detection.


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> The correct term is Random Early Detection, not Discard. See 
>>> [RFC 7567](https://tools.ietf.org/html/rfc7567).


https://github.com/Linaro/odp/pull/172#discussion_r147129262
updated_at 2017-10-26 12:43:39

Re: [lng-odp] [PATCH API-NEXT v12] api: classification: add random early detection

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/classification.h
line 64
@@ -206,6 +213,53 @@ typedef struct odp_cls_cos_param {
 
/** Drop policy associated with CoS */
odp_cls_drop_t drop_policy;
+
+   /** Random Early Detection (RED)
+* Random Early Detection is enabled to initiate a drop probability
+* for the incoming packet when the packets in the queue/pool reaches
+* a specified threshold.
+* When RED is enabled for a particular flow then further incoming
+* packets are assigned a drop probability based on the size of the
+* pool/queue and the drop probability becomes 100% when the queue/pool
+* is full.
+* RED is logically configured in the CoS and could be implemented
+* in either pool or queue linked to the CoS depending on
+* platform capabilities. Application should make sure not to link
+* multiple CoS with different RED or BP configuration to the same queue
+* or pool.
+* RED is enabled when the resource limit is equal to or greater than
+* the maximum threshold value and is disabled when resource limit
+* is less than or equal to minimum threshold value. */
+
+   /** A boolean to enable RED
+* When true, RED is enabled and configured with RED parameters.
+* Otherwise, RED parameters are ignored. */
+   odp_bool_t red_enable;
+
+   /** RED parameters */
+   struct {
+   /** Maximum threshold value for RED */
+   uint32_t max_threshold;
+
+   /** Minimum threshold value for RED */
+   uint32_t min_threshold;
+   } red;
+
+   /** A boolean to enable Back pressure
+* When true, back pressure is enabled and configured with the BP
+* parameters. Otherwise BP parameters are ignored. When back pressure
+* is enabled for a particular flow, the HW can send back pressure
+* information to the remote peer indicating a network congestion */
+   odp_bool_t bp_enable;
+
+   /** BP parameters */
+   struct {
+   /** Threshold value for back pressure.
+* BP is enabled when queue or pool size is equal to or greater
+* than the backpressure threshold. BP threshold is expressed
+* as number packets in either queue or pool. */
+   uint32_t bp_threshold;
+   } bp;


Comment:
"number of packets in pool" == number of free packets or allocated packets? 

> Petri Savolainen(psavol) wrote:
> Threshold value meaning and units need to be specified:  packets in queue, 
> packets allocated from pool. What are the maximum and minimum values of 
> these? And accuracy is implementation specific?
> 
> E.g. pool size 10 000 packet, usually values for min 8000 and max 9 500 could 
> be. Are min 1 and max 100 allowed?


>> muvarov wrote
>> +1 moving will also easy to support ABI compat mode.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Commit subject is too long. Also it would be good to mention in commit 
>>> message that this is a dummy (null) implementation


 Dmitry Eremin-Solenikov(lumag) wrote:
 In my opinion, let's just push it into `odp/api/spec/std_types.h`.


> Balasubramanian Manoharan(bala-manoharan) wrote:
> Okay. 
> @muvarov Travis does not check doxygen?


>> Balasubramanian Manoharan(bala-manoharan) wrote:
>> BP in HW is implemented as edge triggered and the interface is 
>> configured to send Back pressure to the peer when the level increases 
>> the threshold. Current our HW only supports only threshold value and is 
>> not monitored as a range.
>> If any HW later implements this as a range we can add in the future.


>>> Petri Savolainen(psavol) wrote:
>>> Although this is single param now, it's better to wrap it into a 
>>> struct, so that it's easy to add more params later (if needed). Also 
>>> the 100th percent units should be used.
>>> 
>>> struct {
>>>   uint16_t ena_threshold;
>>> } bp;
>>> 
>>> Could there be other thresholds params later? ena_threshold would leave 
>>> room for other (high, low, ...etc) threshold params.


 Petri Savolainen(psavol) wrote:
 
 
 Missing /**
 
 "Enable back pressure
 
 When true, back pressure is enabled and configured with the parameters 
 below.
 Otherwise, back pressure parameters are ignored. When back pressure is 
 enabled 
 for a particular flow, the HW can send back pressure information to 
 the remote 
 peer indicating a network congestion."


> Petri Savolainen(psavol) wrote:
> Wrap these two into "struct red". Add missing doxygen tagging. We 
> should use 100th parts of a percent. So, that API is not bottle neck 
> if HW can offer higher resolution than 1 percen

Re: [lng-odp] [PATCH API-NEXT v12] api: classification: add random early detection

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/classification.h
line 48
@@ -206,6 +213,53 @@ typedef struct odp_cls_cos_param {
 
/** Drop policy associated with CoS */
odp_cls_drop_t drop_policy;
+
+   /** Random Early Detection (RED)
+* Random Early Detection is enabled to initiate a drop probability
+* for the incoming packet when the packets in the queue/pool reaches
+* a specified threshold.
+* When RED is enabled for a particular flow then further incoming
+* packets are assigned a drop probability based on the size of the
+* pool/queue and the drop probability becomes 100% when the queue/pool
+* is full.
+* RED is logically configured in the CoS and could be implemented
+* in either pool or queue linked to the CoS depending on
+* platform capabilities. Application should make sure not to link
+* multiple CoS with different RED or BP configuration to the same queue
+* or pool.
+* RED is enabled when the resource limit is equal to or greater than
+* the maximum threshold value and is disabled when resource limit
+* is less than or equal to minimum threshold value. */
+
+   /** A boolean to enable RED
+* When true, RED is enabled and configured with RED parameters.
+* Otherwise, RED parameters are ignored. */
+   odp_bool_t red_enable;
+
+   /** RED parameters */
+   struct {
+   /** Maximum threshold value for RED */
+   uint32_t max_threshold;
+
+   /** Minimum threshold value for RED */
+   uint32_t min_threshold;
+   } red;


Comment:
Threshold value meaning and units need to be specified:  packets in queue, 
packets allocated from pool. What are the maximum and minimum values of these? 
And accuracy is implementation specific?

E.g. pool size 10 000 packet, usually values for min 8000 and max 9 500 could 
be. Are min 1 and max 100 allowed?


> muvarov wrote
> +1 moving will also easy to support ABI compat mode.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Commit subject is too long. Also it would be good to mention in commit 
>> message that this is a dummy (null) implementation


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> In my opinion, let's just push it into `odp/api/spec/std_types.h`.


 Balasubramanian Manoharan(bala-manoharan) wrote:
 Okay. 
 @muvarov Travis does not check doxygen?


> Balasubramanian Manoharan(bala-manoharan) wrote:
> BP in HW is implemented as edge triggered and the interface is configured 
> to send Back pressure to the peer when the level increases the threshold. 
> Current our HW only supports only threshold value and is not monitored as 
> a range.
> If any HW later implements this as a range we can add in the future.


>> Petri Savolainen(psavol) wrote:
>> Although this is single param now, it's better to wrap it into a struct, 
>> so that it's easy to add more params later (if needed). Also the 100th 
>> percent units should be used.
>> 
>> struct {
>>   uint16_t ena_threshold;
>> } bp;
>> 
>> Could there be other thresholds params later? ena_threshold would leave 
>> room for other (high, low, ...etc) threshold params.


>>> Petri Savolainen(psavol) wrote:
>>> 
>>> 
>>> Missing /**
>>> 
>>> "Enable back pressure
>>> 
>>> When true, back pressure is enabled and configured with the parameters 
>>> below.
>>> Otherwise, back pressure parameters are ignored. When back pressure is 
>>> enabled 
>>> for a particular flow, the HW can send back pressure information to the 
>>> remote 
>>> peer indicating a network congestion."


 Petri Savolainen(psavol) wrote:
 Wrap these two into "struct red". Add missing doxygen tagging. We 
 should use 100th parts of a percent. So, that API is not bottle neck 
 if HW can offer higher resolution than 1 percent. TM API uses the same 
 unit.
 
 /** RED parameters
 struct {
   Maximum threshold percentage for RED in one-hundredths of a percent. 
   Hence 100% is represented as the integer value 1.
   uint16_t max_threshold;
 
   uint16_t min_threshold;
 } red;


> Petri Savolainen(psavol) wrote:
> Missing /**
> 
> "Enable RED
> 
> When true, RED is enabled and configured with the red parameters 
> below.
> Otherwise, RED parameters are ignored."


>> Petri Savolainen(psavol) wrote:
>> Missing Doxygen tag /**
>> 
>> Run 'make doxygen-doc' locally before pushing and correct all 
>> doxygen warnings.


>>> Petri Savolainen(psavol) wrote:
>>> For consistency, it's better to define probability as 100% here, as 
>>> we use

Re: [lng-odp] Ingress Metering/Policing

[Maxim Uvarov]

Hello Liron,

does you hardware support TCM offload?

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

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

Regards,
Maxim.

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

Re: [lng-odp] [PATCH API-NEXT v4 1/3] api: ipsec: rework ODP_IPSEC_SA_DISABLE into packet error

[Dmitry Eremin-Solenikov]

On 26/10/17 14:55, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> 
> 
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Github ODP bot
>> Sent: Wednesday, October 25, 2017 12:00 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH API-NEXT v4 1/3] api: ipsec: rework
>> ODP_IPSEC_SA_DISABLE into packet error
>>
>> From: Dmitry Eremin-Solenikov 
>>
>> According to the discussion on mailing list, most of implementations
>> will not be able to support odp_ipsec_sa_disable() status event
>> directly.  Instead they will submit a dummy packet to that SA. Then
>> after receiving this packet after odp_ipsec_result() will detect this
>> packet and will report it as a packet with
>> odp_ipsec_error_t->sa_disabled bit set.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov 
>> Cc: Nikhil Agarwal 
>> Cc: Balasubramanian Manoharan 
>> ---
>> /** Email created from pull request 256 (lumag:ipsec_sa_disable_v2)
>>  ** https://github.com/Linaro/odp/pull/256
>>  ** Patch: https://github.com/Linaro/odp/pull/256.patch
>>  ** Base sha: 825f75ed8644ef57c5648961e7982daf13cd9375
>>  ** Merge commit sha: ba520d0a3f4c46777c7aedca029e9979a89c69e7
>>  **/
>>  include/odp/api/spec/ipsec.h | 44 ---
>> -
>>  1 file changed, 20 insertions(+), 24 deletions(-)
>>
>> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
>> index 26e852fca..b9ad282ce 100644
>> --- a/include/odp/api/spec/ipsec.h
>> +++ b/include/odp/api/spec/ipsec.h
>> @@ -843,10 +843,12 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const
>> odp_ipsec_sa_param_t *param);
>>   *
>>   * When in synchronous operation mode, the call will return when it's
>> possible
>>   * to destroy the SA. In asynchronous mode, the same is indicated by an
>> - * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA.
>> The
>> - * status event is guaranteed to be the last event for the SA, i.e. all
>> - * in-progress operations have completed and resulting events (including
>> status
>> - * events) have been enqueued before it.
>> + * artificial packet event sent to the queue specified for the SA having
>> + * sa_disabled error bit set in the odp_ipsec_packet_result_t returned by
>> + * odp_ipsec_result(). The packet is guaranteed to be the last event for
>> + * the SA, i.e. all in-progress operations have completed and resulting
>> events
>> + * (including status events) have been enqueued before it. No packets
>> will come
>> + * from SA after this one.
> 
> This still lacks the definition of what is the difference between an 
> artificial packet vs a normal packet. We could define it e.g. by saying that 
> length is always zero and application must not do anything else with it than 
> free it. But then, why it's a packet anyway? Why it would not then be e.g. a 
> ipsec status event (which is not a packet, but could be implemented as an 
> artificial packet).

No difference from my POV. Processing path for all packets coming from
IPsec:
- Error packet. Process error flags, drop the packet.
- Not an error. Process warning flags, forward the packet.

> 
> The idea of event type vs sub-event type is that:
>  1) all events of the same base type (e.g. packet) contain the same metadata 
> and can be processed the same way. For example, someone may write a generic 
> packet statistics (application) module, and plug that before and after an 
> ipsec termination (application) module, without need to know that packets 
> before ipsec module carry extra ipsec metadata (from inline inbound ipsec).

As long as they don't carry error flag. odp_packet_has_error(), etc.
BTW: I should check that my implementation sets that flag.

>  2) sub-type adds metadata and other properties to the base type
> 
> An artificial packet would not fit in either category, it would be a 
> non-packet.

I somewhat agree with you here. I would prefer separate event for
SA_DISABLE. However some (most?) hardware ATM will not be able to
support such an event directly. And an application will need separate
processing for error packets anyway.

> Usually, application receives multiple event types anyway: e.g. packets and 
> timeouts. So, for application it would not be an issue to have one additional 
> switch-case for IPSEC status events. API integrity is more important than 
> (potential) save of couple if-else branches.

It is not a problem of application, but rather an implementation problem.

> So, I think this solution is not complete yet and I don't see how it would in 
> the end make a real difference to the current status event API.



-- 
With best wishes
Dmitry

[lng-odp] [PATCH API-NEXT v3 2/3] linux-gen: packet: dummy ones complement implementation

[Github ODP bot]

From: Petri Savolainen 

Added dummy implementation of ones complement calls. Linux
generic implementation does not calculate the sum for all
incoming packets as it would be wasteful in SW. It's better
to wait until application asks it with odp_chksum_ones_comp16().
Later on, the sum could be stored into the packet header,
if we found a way to get it from the HW.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 242 (psavol:next-checksum-metadata)
 ** https://github.com/Linaro/odp/pull/242
 ** Patch: https://github.com/Linaro/odp/pull/242.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 5c16247e4ce2735df80c66f11dd9c9708e8c905f
 **/
 platform/linux-generic/odp_packet.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/platform/linux-generic/odp_packet.c 
b/platform/linux-generic/odp_packet.c
index 603ac7181..f153ea2db 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -1255,6 +1255,14 @@ int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t 
offset)
return 0;
 }
 
+uint16_t odp_packet_ones_comp(odp_packet_t pkt, odp_packet_data_range_t *range)
+{
+   (void)pkt;
+   range->length = 0;
+   range->offset = 0;
+   return 0;
+}
+
 void odp_packet_flow_hash_set(odp_packet_t pkt, uint32_t flow_hash)
 {
odp_packet_hdr_t *pkt_hdr = packet_hdr(pkt);

[lng-odp] [PATCH API-NEXT v3 0/3] api: ones complement metadata

[Github ODP bot]

Added packet metadata for ones complement sum over IP
payload in a packet. Some NICs calculate the sum
during packet input (at least for IP fragments) and
store the value into the packet descriptor. This offloads
L4 checksum calculation for IP fragments as SW does not
need sum all payload data, but just combine pre-calculated
sums from packet descriptors and remove extra header fields
from the sum.

github
/** Email created from pull request 242 (psavol:next-checksum-metadata)
 ** https://github.com/Linaro/odp/pull/242
 ** Patch: https://github.com/Linaro/odp/pull/242.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 5c16247e4ce2735df80c66f11dd9c9708e8c905f
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 26 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 14 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 55 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [PATCH 2.0 v1 0/6] Make public modular framework and subsystem headers

[Github ODP bot]

Make public modular framework and subsystem headers

github
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 184 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 58 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 54 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 54 lines checked


to_send-p-003.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 70 lines checked


to_send-p-004.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 46 lines checked


to_send-p-005.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [PATCH 2.0 v1 4/6] linux-gen: modular-framework: make public queue subsystem header

[Github ODP bot]

From: Bogdan Pricope 

Make public queue subsystem header.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 .../odp/subsystem/spec/queue_subsystem.h   | 0
 include/odp_mf.h   | 1 +
 platform/Makefile.inc  | 3 ++-
 platform/linux-dpdk/Makefile.am| 1 -
 platform/linux-generic/Makefile.am | 1 -
 platform/linux-generic/queue/generic.c | 2 +-
 platform/linux-generic/queue/scalable.c| 2 +-
 platform/linux-generic/queue/subsystem.c   | 2 +-
 8 files changed, 6 insertions(+), 6 deletions(-)
 rename platform/linux-generic/include/odp_queue_subsystem.h => 
include/odp/subsystem/spec/queue_subsystem.h (100%)

diff --git a/platform/linux-generic/include/odp_queue_subsystem.h 
b/include/odp/subsystem/spec/queue_subsystem.h
similarity index 100%
rename from platform/linux-generic/include/odp_queue_subsystem.h
rename to include/odp/subsystem/spec/queue_subsystem.h
diff --git a/include/odp_mf.h b/include/odp_mf.h
index 9b83e8680..ce5ff5b65 100644
--- a/include/odp_mf.h
+++ b/include/odp_mf.h
@@ -21,6 +21,7 @@ extern C {
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 }
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index bb928c83c..6965a0e4b 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -85,7 +85,8 @@ odpmfspecinclude_HEADERS = \
 odpsubsystemspecincludedir= $(includedir)/odp/subsytem/spec
 odpsubsystemspecinclude_HEADERS = \
  $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h \
- $(top_srcdir)/include/odp/subsystem/spec/pool_subsystem.h
+ $(top_srcdir)/include/odp/subsystem/spec/pool_subsystem.h \
+ $(top_srcdir)/include/odp/subsystem/spec/queue_subsystem.h
 
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index cf3e822e9..3ac7df565 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -206,7 +206,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_posix_extensions.h \
  
${top_srcdir}/platform/linux-generic/include/odp_queue_internal.h \
  ${top_srcdir}/platform/linux-generic/include/odp_queue_if.h \
- 
${top_srcdir}/platform/linux-generic/include/odp_queue_subsystem.h \
  
${top_srcdir}/platform/linux-generic/include/odp_ring_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_schedule_if.h \
  
${top_srcdir}/platform/linux-generic/include/odp_schedule_subsystem.h \
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index a871afae2..8172244b1 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -185,7 +185,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_pktio_ops_tap.h \
  ${srcdir}/include/odp_pktio_ops_subsystem.h \
  ${srcdir}/include/odp_pkt_queue_internal.h \
- ${srcdir}/include/odp_queue_subsystem.h \
  ${srcdir}/include/odp_pool_internal.h \
  ${srcdir}/include/odp_posix_extensions.h \
  ${srcdir}/include/odp_queue_internal.h \
diff --git a/platform/linux-generic/queue/generic.c 
b/platform/linux-generic/queue/generic.c
index ab2b97048..3099fe158 100644
--- a/platform/linux-generic/queue/generic.c
+++ b/platform/linux-generic/queue/generic.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platform/linux-generic/queue/scalable.c 
b/platform/linux-generic/queue/scalable.c
index 00cd8da65..ab592a130 100644
--- a/platform/linux-generic/queue/scalable.c
+++ b/platform/linux-generic/queue/scalable.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include <_ishm_internal.h>
 #include <_ishmpool_internal.h>
diff --git a/platform/linux-generic/queue/subsystem.c 
b/platform/linux-generic/queue/subsystem.c
index 05e8edb8e..2fba9f374 100644
--- a/platform/linux-generic/queue/subsystem.c
+++ b/platform/linux-generic/queue/subsystem.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 ODP_SUBSYSTEM_DEFINE(queue, "queue public APIs", QUEUE_SUBSYSTEM_VERSION);
 

Re: [lng-odp] [PATCH API-NEXT v6] API: Pool: Return address range for pool objects

[Github ODP bot]

Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/pool.h
line 7
@@ -294,6 +294,22 @@ odp_pool_t odp_pool_lookup(const char *name);
 typedef struct odp_pool_info_t {
const char *name;  /**< pool name */
odp_pool_param_t params;   /**< pool parameters */
+
+   /** Minimum data address.
+* This is the minimum address that application accessible
+* data of any * object (event) allocated from the pool may


Comment:
There's an extra * on this line.

> brbrooks wrote
> "maybe" -> "may be"


>> brbrooks wrote
>> "maybe" -> "may be"


>>> sachin-saxena wrote
>>> Sure.


 Petri Savolainen(psavol) wrote:
 While adding commit log text, modify the style in these comments to begin 
 each row with a *.
 
 /**
   *
   *
   */


> sachin-saxena wrote
> Looks much better. Thank you @psavol for your suggestions.


>> Petri Savolainen(psavol) wrote:
>> This spec should apply for all pool types (also other than packet). 0 
>> address may be used when there's no data in an event (e.g. timeout).
>> 
>> /** Minimum data address.
>>* This is the minimum address that application accessible data of any 
>>* object (event) allocated from the pool may locate. When there's no 
>>* application accessible data (e.g. ODP_POOL_TIMEOUT pools), the 
>>* value maybe zero. */
>> uintptr_t min_data_addr;
>> 
>> /** Maximum data address.
>>* This is the maximum address that application accessible data of any 
>>* object (event) allocated from the pool may locate. When there's no 
>>* application accessible data (e.g. ODP_POOL_TIMEOUT pools), the 
>>* value maybe zero.  */
>> uintptr_t max_data_addr;


>>> sachin-saxena wrote
>>> I will wait for other's comments, if any, before sending V3 patchset


 sachin-saxena wrote
 1.  Agreed for first suggestion.
 2.  For Second, As per my understanding, the VPP only needs to know 
 the range of addresses in order to calculate OFFSET within. VPP 
 doesn't assume/store packet address beyond its lifetime (Rx to Tx)


> sachin-saxena wrote
> OK. agreed


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> The only other ambiguity is whether the address that applications 
>> see for a packet is constant. VPP clearly assumes this but this is 
>> not implied by the ODP spec. The "lifetime" of packet visibility is 
>> from the time a call like `odp_packet_data()` is made until the 
>> thread releases the `odp_packet_t` that was used to obtain this 
>> address. If some other thread receives that handle and calls 
>> `odp_packet_data()` there's no requirement or guarantee that it will 
>> get the same address as the previous owner. 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> I'd change these to "visible address" rather than "address". The 
>>> point is that the spec says nothing about how packets are 
>>> represented within an implementation. It only states what 
>>> applications may see by using other ODP APIs that manipulate 
>>> odp_packet_t object.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 I'd delete this note as it's not necessary and not complete for 
 the ODP API spec. 


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> As we discussed earlier today. We should only need an extension 
> to `odp_pool_info()` to return the `min_addr` and `max_addr` of 
> any packet contained in the pool. This can simply be added to the 
> end of the `odp_pool_info_t` struct. The application (in this 
> case VPP) can then verify that the range is usable by it (_i.e.,_ 
> is containable in 32 bits) and can store the info it needs to do 
> its indexing from this info. 


>> Petri Savolainen(psavol) wrote:
>> How sparse a "linear pool" may be? All implementations can claim 
>> linear pool support by returning info.first_addr = 0, 
>> info.last_addr = (uintptr_t) -1, where address size may be 
>> 64bits.
>> 
>> Addresses could be used for debugging, but not much more than 
>> that. What VPP is going to do with this information ?
>>  
>> 
>> 


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> @muvarov To your points:
>>> 
>>> 1. No, VPP only deals with packets so there's no need to 
>>> generalize this since it is an accommodation for VPP, not 
>>> something we want to encourage other applications to use.
>>> 
>>> 2. We abandoned that approach because it required the 

[lng-odp] [PATCH API-NEXT v3 3/3] validation: packet: add call to ones complement

[Github ODP bot]

From: Petri Savolainen 

Call ones complement function. Actual validation of
correctness of the sum is to be done, when an implementation
exist which sets the sum on packet input.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 242 (psavol:next-checksum-metadata)
 ** https://github.com/Linaro/odp/pull/242
 ** Patch: https://github.com/Linaro/odp/pull/242.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 5c16247e4ce2735df80c66f11dd9c9708e8c905f
 **/
 test/validation/api/packet/packet.c |  6 ++
 test/validation/api/pktio/pktio.c   | 25 +
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/test/validation/api/packet/packet.c 
b/test/validation/api/packet/packet.c
index 431444cf3..f03fa1d84 100644
--- a/test/validation/api/packet/packet.c
+++ b/test/validation/api/packet/packet.c
@@ -503,6 +503,7 @@ void packet_test_basic_metadata(void)
 {
odp_packet_t pkt = test_packet;
odp_time_t ts;
+   odp_packet_data_range_t range;
 
CU_ASSERT_PTR_NOT_NULL(odp_packet_head(pkt));
CU_ASSERT_PTR_NOT_NULL(odp_packet_data(pkt));
@@ -512,6 +513,11 @@ void packet_test_basic_metadata(void)
CU_ASSERT(odp_packet_input(pkt) == ODP_PKTIO_INVALID);
CU_ASSERT(odp_packet_input_index(pkt) < 0);
 
+   /* Packet was not received from a packet IO, shouldn't have ones
+* complement calculated. */
+   odp_packet_ones_comp(pkt, &range);
+   CU_ASSERT(range.length == 0);
+
odp_packet_flow_hash_set(pkt, UINT32_MAX);
CU_ASSERT(odp_packet_has_flow_hash(pkt));
CU_ASSERT(odp_packet_flow_hash(pkt) == UINT32_MAX);
diff --git a/test/validation/api/pktio/pktio.c 
b/test/validation/api/pktio/pktio.c
index 720707358..ee5de8401 100644
--- a/test/validation/api/pktio/pktio.c
+++ b/test/validation/api/pktio/pktio.c
@@ -48,6 +48,9 @@ static int num_ifaces;
 interface that just become up.*/
 static bool wait_for_network;
 
+/* Dummy global variable to avoid compiler optimizing out API calls */
+uint64_t odp_valid_test_pktio_u64;
+
 /** local container for pktio attributes */
 typedef struct {
const char *name;
@@ -661,10 +664,24 @@ static void pktio_txrx_multi(pktio_info_t *pktio_a, 
pktio_info_t *pktio_b,
CU_ASSERT(num_rx == num_pkts);
 
for (i = 0; i < num_rx; ++i) {
-   CU_ASSERT_FATAL(rx_pkt[i] != ODP_PACKET_INVALID);
-   CU_ASSERT(odp_packet_input(rx_pkt[i]) == pktio_b->id);
-   CU_ASSERT(odp_packet_has_error(rx_pkt[i]) == 0);
-   odp_packet_free(rx_pkt[i]);
+   odp_packet_data_range_t range;
+   uint16_t sum;
+   odp_packet_t pkt = rx_pkt[i];
+
+   CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
+   CU_ASSERT(odp_packet_input(pkt) == pktio_b->id);
+   CU_ASSERT(odp_packet_has_error(pkt) == 0);
+
+   /* Dummy read to ones complement in case pktio has set it */
+   sum = odp_packet_ones_comp(pkt, &range);
+   if (range.length > 0)
+   odp_valid_test_pktio_u64 += sum;
+
+   /* Dummy read to flow hash in case pktio has set it */
+   if (odp_packet_has_flow_hash(pkt))
+   odp_valid_test_pktio_u64 += odp_packet_flow_hash(pkt);
+
+   odp_packet_free(pkt);
}
 }
 

[lng-odp] [PATCH API-NEXT v3 1/3] api: packet: ones complement sum

[Github ODP bot]

From: Petri Savolainen 

Added packet metadata for ones complement sum over
packet data. Some NICs calculate the sum during packet
input (at least for IP fragments) and store the value
into the packet descriptor. This offloads L4 checksum
calculation for IP fragments as SW does not need sum
all payload data, but just combine pre-calculated
sums from packet descriptors and remove extra header fields
from the sum.

Signed-off-by: Petri Savolainen 
---
/** Email created from pull request 242 (psavol:next-checksum-metadata)
 ** https://github.com/Linaro/odp/pull/242
 ** Patch: https://github.com/Linaro/odp/pull/242.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 5c16247e4ce2735df80c66f11dd9c9708e8c905f
 **/
 include/odp/api/spec/packet.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/odp/api/spec/packet.h b/include/odp/api/spec/packet.h
index 62ecf70e1..ae927d6e9 100644
--- a/include/odp/api/spec/packet.h
+++ b/include/odp/api/spec/packet.h
@@ -1437,6 +1437,26 @@ void odp_packet_l3_chksum_insert(odp_packet_t pkt, int 
l3);
 void odp_packet_l4_chksum_insert(odp_packet_t pkt, int l4);
 
 /**
+ * Ones' complement sum of packet data
+ *
+ * Returns 16-bit ones' complement sum that was calculated over a portion of
+ * packet data during a packet processing operation (e.g. packet input or
+ * IPSEC offload). The data range is output with 'range' parameter, and usually
+ * includes IP payload (L4 headers and payload). When 'range.length' is zero,
+ * the sum has not been calculated. In case of odd number of bytes,
+ * calculation uses a zero byte as padding at the end. The sum may be used as
+ * part of e.g. UDP/TCP checksum checking, especially with IP fragments.
+ *
+ * @param  pktPacket handle
+ * @param[out] range  Data range of the sum (output). The calculation started
+ *from range.offset and included range.length bytes. When
+ *range.length is zero, the sum has not been calculated.
+ *
+ * @return Ones' complement sum over the data range
+ */
+uint16_t odp_packet_ones_comp(odp_packet_t pkt, odp_packet_data_range_t 
*range);
+
+/**
  * Packet flow hash value
  *
  * Returns the hash generated from the packet header. Use

[lng-odp] [PATCH 2.0 v1 5/6] linux-gen: modular-framework: make public schedule subsystem header

[Github ODP bot]

From: Bogdan Pricope 

Make public schedule subsystem header.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 .../odp/subsystem/spec/schedule_subsystem.h| 0
 include/odp_mf.h   | 1 +
 platform/Makefile.inc  | 3 ++-
 platform/linux-dpdk/Makefile.am| 1 -
 platform/linux-generic/Makefile.am | 1 -
 platform/linux-generic/schedule/generic.c  | 2 +-
 platform/linux-generic/schedule/iquery.c   | 2 +-
 platform/linux-generic/schedule/scalable.c | 2 +-
 platform/linux-generic/schedule/sp.c   | 2 +-
 platform/linux-generic/schedule/subsystem.c| 2 +-
 10 files changed, 8 insertions(+), 8 deletions(-)
 rename platform/linux-generic/include/odp_schedule_subsystem.h => 
include/odp/subsystem/spec/schedule_subsystem.h (100%)

diff --git a/platform/linux-generic/include/odp_schedule_subsystem.h 
b/include/odp/subsystem/spec/schedule_subsystem.h
similarity index 100%
rename from platform/linux-generic/include/odp_schedule_subsystem.h
rename to include/odp/subsystem/spec/schedule_subsystem.h
diff --git a/include/odp_mf.h b/include/odp_mf.h
index ce5ff5b65..a03040c23 100644
--- a/include/odp_mf.h
+++ b/include/odp_mf.h
@@ -22,6 +22,7 @@ extern C {
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 }
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 6965a0e4b..da1fb52e3 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -86,7 +86,8 @@ odpsubsystemspecincludedir= $(includedir)/odp/subsytem/spec
 odpsubsystemspecinclude_HEADERS = \
  $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h \
  $(top_srcdir)/include/odp/subsystem/spec/pool_subsystem.h \
- $(top_srcdir)/include/odp/subsystem/spec/queue_subsystem.h
+ $(top_srcdir)/include/odp/subsystem/spec/queue_subsystem.h \
+ $(top_srcdir)/include/odp/subsystem/spec/schedule_subsystem.h
 
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index 3ac7df565..96915e818 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -208,7 +208,6 @@ noinst_HEADERS = \
  ${top_srcdir}/platform/linux-generic/include/odp_queue_if.h \
  
${top_srcdir}/platform/linux-generic/include/odp_ring_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_schedule_if.h \
- 
${top_srcdir}/platform/linux-generic/include/odp_schedule_subsystem.h \
  
${top_srcdir}/platform/linux-generic/include/odp_sorted_list_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_shm_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_time_internal.h \
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 8172244b1..027e54fd8 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -195,7 +195,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_schedule_scalable.h \
  ${srcdir}/include/odp_schedule_scalable_config.h \
  ${srcdir}/include/odp_schedule_scalable_ordered.h \
- ${srcdir}/include/odp_schedule_subsystem.h \
  ${srcdir}/include/odp_sorted_list_internal.h \
  ${srcdir}/include/odp_shm_internal.h \
  ${srcdir}/include/odp_time_internal.h \
diff --git a/platform/linux-generic/schedule/generic.c 
b/platform/linux-generic/schedule/generic.c
index 73fef40cb..39bf2d4f5 100644
--- a/platform/linux-generic/schedule/generic.c
+++ b/platform/linux-generic/schedule/generic.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 /* Should remove this dependency */
diff --git a/platform/linux-generic/schedule/iquery.c 
b/platform/linux-generic/schedule/iquery.c
index 5de229832..13f6ade26 100644
--- a/platform/linux-generic/schedule/iquery.c
+++ b/platform/linux-generic/schedule/iquery.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 /* Should remove this dependency */
diff --git a/platform/linux-generic/schedule/scalable.c 
b/platform/linux-generic/schedule/scalable.c
index d8f538202..0266bd1c4 100644
--- a/platform/linux-generic/

[lng-odp] [PATCH 2.0 v1 6/6] linux-gen: modular-framework: make public pktio_ops subsystem header

[Github ODP bot]

From: Bogdan Pricope 

Make public pktio_ops subsystem header.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 .../odp/subsystem/spec/pktio_ops_subsystem.h   | 0
 include/odp_mf.h   | 1 +
 platform/Makefile.inc  | 3 ++-
 platform/linux-dpdk/Makefile.am| 1 -
 platform/linux-dpdk/include/odp_packet_io_internal.h   | 2 +-
 platform/linux-generic/Makefile.am | 1 -
 platform/linux-generic/include/odp_packet_io_internal.h| 2 +-
 7 files changed, 5 insertions(+), 5 deletions(-)
 rename platform/linux-generic/include/odp_pktio_ops_subsystem.h => 
include/odp/subsystem/spec/pktio_ops_subsystem.h (100%)

diff --git a/platform/linux-generic/include/odp_pktio_ops_subsystem.h 
b/include/odp/subsystem/spec/pktio_ops_subsystem.h
similarity index 100%
rename from platform/linux-generic/include/odp_pktio_ops_subsystem.h
rename to include/odp/subsystem/spec/pktio_ops_subsystem.h
diff --git a/include/odp_mf.h b/include/odp_mf.h
index a03040c23..cd293a80f 100644
--- a/include/odp_mf.h
+++ b/include/odp_mf.h
@@ -23,6 +23,7 @@ extern C {
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 }
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index da1fb52e3..696f92cf2 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -87,7 +87,8 @@ odpsubsystemspecinclude_HEADERS = \
  $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h \
  $(top_srcdir)/include/odp/subsystem/spec/pool_subsystem.h \
  $(top_srcdir)/include/odp/subsystem/spec/queue_subsystem.h \
- $(top_srcdir)/include/odp/subsystem/spec/schedule_subsystem.h
+ $(top_srcdir)/include/odp/subsystem/spec/schedule_subsystem.h 
\
+ $(top_srcdir)/include/odp/subsystem/spec/pktio_ops_subsystem.h
 
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index 96915e818..63dd99250 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -194,7 +194,6 @@ noinst_HEADERS = \
  ${srcdir}/pktio/dpdk.h \
  ${srcdir}/include/odp_packet_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_ipc.h \
- 
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_subsystem.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_socket.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_loopback.h \
  
${top_srcdir}/platform/linux-generic/include/odp_name_table_internal.h \
diff --git a/platform/linux-dpdk/include/odp_packet_io_internal.h 
b/platform/linux-dpdk/include/odp_packet_io_internal.h
index 089ad38c5..fb4df032c 100644
--- a/platform/linux-dpdk/include/odp_packet_io_internal.h
+++ b/platform/linux-dpdk/include/odp_packet_io_internal.h
@@ -32,7 +32,7 @@ extern "C" {
 
 /* Forward declaration */
 typedef union pktio_entry_u pktio_entry_t;
-#include 
+#include 
 
 #define PKTIO_NAME_LEN 256
 
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 027e54fd8..d73b6bf10 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -183,7 +183,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_pktio_ops_pcap.h \
  ${srcdir}/include/odp_pktio_ops_socket.h \
  ${srcdir}/include/odp_pktio_ops_tap.h \
- ${srcdir}/include/odp_pktio_ops_subsystem.h \
  ${srcdir}/include/odp_pkt_queue_internal.h \
  ${srcdir}/include/odp_pool_internal.h \
  ${srcdir}/include/odp_posix_extensions.h \
diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index b26a35d25..8559bedeb 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -35,7 +35,7 @@ extern "C" {
 #define PKTIO_MAX_QUEUES 64
 /* Forward declaration */
 typedef union pktio_entry_u pktio_entry_t;
-#include 
+#include 
 
 #define PKTIO_NAME_LEN 256
 

[lng-odp] [PATCH 2.0 v1 2/6] linux-gen: modular-framework: make public buffer subsystem header

[Github ODP bot]

From: Bogdan Pricope 

Make public buffer subsystem header.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 .../odp/subsystem/spec/buffer_subsystem.h | 1 -
 include/odp_mf.h  | 1 +
 platform/Makefile.inc | 4 
 platform/linux-dpdk/Makefile.am   | 1 -
 platform/linux-dpdk/buffer/dpdk.c | 2 +-
 platform/linux-generic/Makefile.am| 1 -
 platform/linux-generic/buffer/generic.c   | 2 +-
 platform/linux-generic/buffer/subsystem.c | 2 +-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename platform/linux-generic/include/odp_buffer_subsystem.h => 
include/odp/subsystem/spec/buffer_subsystem.h (99%)

diff --git a/platform/linux-generic/include/odp_buffer_subsystem.h 
b/include/odp/subsystem/spec/buffer_subsystem.h
similarity index 99%
rename from platform/linux-generic/include/odp_buffer_subsystem.h
rename to include/odp/subsystem/spec/buffer_subsystem.h
index b8f6a6953..011ad448c 100644
--- a/platform/linux-generic/include/odp_buffer_subsystem.h
+++ b/include/odp/subsystem/spec/buffer_subsystem.h
@@ -61,4 +61,3 @@ typedef ODP_MODULE_CLASS(buffer) {
 
 #include 
 #endif
-
diff --git a/include/odp_mf.h b/include/odp_mf.h
index f8998f280..747c6dc4d 100644
--- a/include/odp_mf.h
+++ b/include/odp_mf.h
@@ -19,6 +19,7 @@ extern C {
 #endif
 
 #include 
+#include 
 
 #ifdef __cplusplus
 }
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index e6270f6cd..0d38d377e 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -82,6 +82,10 @@ odpmfspecinclude_HEADERS = \
  $(top_srcdir)/include/odp/mf/spec/module.h \
  $(top_srcdir)/include/odp/mf/spec/list.h
 
+odpsubsystemspecincludedir= $(includedir)/odp/subsytem/spec
+odpsubsystemspecinclude_HEADERS = \
+ $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h
+
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
$(top_srcdir)/include/odp/arch/default/api/abi/buffer.h \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index 14bd1b866..e1074cc23 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -172,7 +172,6 @@ odpdrvplatinclude_HEADERS = \
 
 
 noinst_HEADERS = \
- 
${top_srcdir}/platform/linux-generic/include/odp_buffer_subsystem.h \
  
${top_srcdir}/platform/linux-generic/include/_fdserver_internal.h \
  ${top_srcdir}/platform/linux-generic/include/_ishm_internal.h 
\
  
${top_srcdir}/platform/linux-generic/include/_ishmphy_internal.h \
diff --git a/platform/linux-dpdk/buffer/dpdk.c 
b/platform/linux-dpdk/buffer/dpdk.c
index 704468eea..65bb6b03c 100644
--- a/platform/linux-dpdk/buffer/dpdk.c
+++ b/platform/linux-dpdk/buffer/dpdk.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index e5a776a25..4acd9236f 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -160,7 +160,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_bitmap_internal.h \
  ${srcdir}/include/odp_bitset.h \
  ${srcdir}/include/odp_buffer_internal.h \
- ${srcdir}/include/odp_buffer_subsystem.h \
  ${srcdir}/include/odp_classification_datamodel.h \
  ${srcdir}/include/odp_classification_inlines.h \
  ${srcdir}/include/odp_classification_internal.h \
diff --git a/platform/linux-generic/buffer/generic.c 
b/platform/linux-generic/buffer/generic.c
index 3281119be..70b1a73d7 100644
--- a/platform/linux-generic/buffer/generic.c
+++ b/platform/linux-generic/buffer/generic.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/platform/linux-generic/buffer/subsystem.c 
b/platform/linux-generic/buffer/subsystem.c
index 767113975..2e1bf59a3 100644
--- a/platform/linux-generic/buffer/subsystem.c
+++ b/platform/linux-generic/buffer/subsystem.c
@@ -6,7 +6,7 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 #include 
-#include 
+#include 
 #include 
 
 ODP_SUBSYSTEM_DEFINE(buffer, "memory buffer public APIs",

[lng-odp] [PATCH 2.0 v1 1/6] linux-gen: modular-framework: make public modular framework headers

[Github ODP bot]

From: Bogdan Pricope 

Make public modular framework headers.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 frameworks/modular/module.h| 20 
 frameworks/modular/odp_module.c|  2 +-
 {frameworks/modular => include/odp/mf/spec}/list.h |  0
 .../odp_module.h => include/odp/mf/spec/module.h   |  0
 include/odp_mf.h   | 27 ++
 platform/Makefile.inc  |  5 
 platform/linux-dpdk/Makefile.am|  7 +++---
 platform/linux-generic/Makefile.am |  7 +++---
 platform/linux-generic/buffer/subsystem.c  |  1 -
 .../linux-generic/include/odp_buffer_subsystem.h   |  2 +-
 .../include/odp_pktio_ops_subsystem.h  |  2 +-
 .../linux-generic/include/odp_pool_subsystem.h |  2 +-
 .../linux-generic/include/odp_queue_subsystem.h|  2 +-
 .../linux-generic/include/odp_schedule_subsystem.h |  2 +-
 platform/linux-generic/pool/subsystem.c|  1 -
 platform/linux-generic/queue/subsystem.c   |  1 -
 platform/linux-generic/schedule/subsystem.c|  1 -
 17 files changed, 64 insertions(+), 18 deletions(-)
 create mode 100644 frameworks/modular/module.h
 rename {frameworks/modular => include/odp/mf/spec}/list.h (100%)
 rename frameworks/modular/odp_module.h => include/odp/mf/spec/module.h (100%)
 create mode 100644 include/odp_mf.h

diff --git a/frameworks/modular/module.h b/frameworks/modular/module.h
new file mode 100644
index 0..f7445bef3
--- /dev/null
+++ b/frameworks/modular/module.h
@@ -0,0 +1,20 @@
+/* Copyright (c) 2013, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_CORE_MODULE_H_
+#define ODP_CORE_MODULE_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* ODP_CORE_MODULE_H_ */
+
diff --git a/frameworks/modular/odp_module.c b/frameworks/modular/odp_module.c
index 475bcd5e2..596befd55 100644
--- a/frameworks/modular/odp_module.c
+++ b/frameworks/modular/odp_module.c
@@ -10,7 +10,7 @@
 
 #include 
 #include 
-#include "odp_module.h"
+#include "module.h"
 
 #define MODULE_FRAMEWORK_VERSION 0x0001UL
 ODP_SUBSYSTEM_DEFINE(module, "module framework", MODULE_FRAMEWORK_VERSION);
diff --git a/frameworks/modular/list.h b/include/odp/mf/spec/list.h
similarity index 100%
rename from frameworks/modular/list.h
rename to include/odp/mf/spec/list.h
diff --git a/frameworks/modular/odp_module.h b/include/odp/mf/spec/module.h
similarity index 100%
rename from frameworks/modular/odp_module.h
rename to include/odp/mf/spec/module.h
diff --git a/include/odp_mf.h b/include/odp_mf.h
new file mode 100644
index 0..f8998f280
--- /dev/null
+++ b/include/odp_mf.h
@@ -0,0 +1,27 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * The OpenDataPlane modular framework programming interface
+ *
+ */
+
+#ifndef ODP_MF_H_
+#define ODP_MF_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include 
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* ODP_MF_H_ */
+
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 4d9280b50..e6270f6cd 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -77,6 +77,11 @@ odpdrvspecinclude_HEADERS = \
  $(top_srcdir)/include/odp/drv/spec/std_types.h \
  $(top_srcdir)/include/odp/drv/spec/sync.h
 
+odpmfspecincludedir= $(includedir)/odp/mf/spec
+odpmfspecinclude_HEADERS = \
+ $(top_srcdir)/include/odp/mf/spec/module.h \
+ $(top_srcdir)/include/odp/mf/spec/list.h
+
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
$(top_srcdir)/include/odp/arch/default/api/abi/buffer.h \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index c99cfaa1c..14bd1b866 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -19,7 +19,6 @@ AM_CPPFLAGS +=  -I$(top_srcdir)/platform/linux-dpdk/include
 AM_CPPFLAGS +=  -I$(top_srcdir)/platform/linux-generic/include
 AM_CPPFLAGS +=  -I$(srcdir)/include
 AM_CPPFLAGS +=  -I$(top_srcdir)/include
-AM_CPPFLAGS +=  -I$(top_srcdir)/frameworks/modular
 AM_CPPFLAGS +=  -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@
 AM_CPPFLAGS +=  -I$(top_builddir)/include
 AM_CPPFLAGS +=  -Iinclude
@@ -35,7 +34,8 @@ AM_CPPFLAGS +=  $(LIBCONFIG_CFLAGS)
 include_HEADERS = \
  $(top_srcdir)/include/odp.h \
  $(top_srcdir)/include/odp_api.h \
- $(top_srcdir)/include/odp_drv.h

[lng-odp] [PATCH 2.0 v1 3/6] linux-gen: modular-framework: make public pool subsystem header

[Github ODP bot]

From: Bogdan Pricope 

Make public pool subsystem header.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 261 (bogdanPricope:2_0_mf_include_pr)
 ** https://github.com/Linaro/odp/pull/261
 ** Patch: https://github.com/Linaro/odp/pull/261.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 4a263f664ff0e7916e1fe52f09afeed0db9a11dc
 **/
 .../odp/subsystem/spec/pool_subsystem.h| 0
 include/odp_mf.h   | 1 +
 platform/Makefile.inc  | 3 ++-
 platform/linux-dpdk/Makefile.am| 1 -
 platform/linux-dpdk/include/odp_pool_internal.h| 2 +-
 platform/linux-generic/Makefile.am | 1 -
 platform/linux-generic/include/odp_pool_internal.h | 2 +-
 platform/linux-generic/pool/subsystem.c| 2 +-
 8 files changed, 6 insertions(+), 6 deletions(-)
 rename platform/linux-generic/include/odp_pool_subsystem.h => 
include/odp/subsystem/spec/pool_subsystem.h (100%)

diff --git a/platform/linux-generic/include/odp_pool_subsystem.h 
b/include/odp/subsystem/spec/pool_subsystem.h
similarity index 100%
rename from platform/linux-generic/include/odp_pool_subsystem.h
rename to include/odp/subsystem/spec/pool_subsystem.h
diff --git a/include/odp_mf.h b/include/odp_mf.h
index 747c6dc4d..9b83e8680 100644
--- a/include/odp_mf.h
+++ b/include/odp_mf.h
@@ -20,6 +20,7 @@ extern C {
 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 }
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 0d38d377e..bb928c83c 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -84,7 +84,8 @@ odpmfspecinclude_HEADERS = \
 
 odpsubsystemspecincludedir= $(includedir)/odp/subsytem/spec
 odpsubsystemspecinclude_HEADERS = \
- $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h
+ $(top_srcdir)/include/odp/subsystem/spec/buffer_subsystem.h \
+ $(top_srcdir)/include/odp/subsystem/spec/pool_subsystem.h
 
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index e1074cc23..cf3e822e9 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -203,7 +203,6 @@ noinst_HEADERS = \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_io_ring_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pkt_queue_internal.h \
  ${srcdir}/include/odp_pool_internal.h \
- 
${top_srcdir}/platform/linux-generic/include/odp_pool_subsystem.h \
  ${srcdir}/include/odp_posix_extensions.h \
  
${top_srcdir}/platform/linux-generic/include/odp_queue_internal.h \
  ${top_srcdir}/platform/linux-generic/include/odp_queue_if.h \
diff --git a/platform/linux-dpdk/include/odp_pool_internal.h 
b/platform/linux-dpdk/include/odp_pool_internal.h
index 2b3fc18c0..938843436 100644
--- a/platform/linux-dpdk/include/odp_pool_internal.h
+++ b/platform/linux-dpdk/include/odp_pool_internal.h
@@ -20,7 +20,7 @@ extern "C" {
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 4acd9236f..a871afae2 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -187,7 +187,6 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_pkt_queue_internal.h \
  ${srcdir}/include/odp_queue_subsystem.h \
  ${srcdir}/include/odp_pool_internal.h \
- ${srcdir}/include/odp_pool_subsystem.h \
  ${srcdir}/include/odp_posix_extensions.h \
  ${srcdir}/include/odp_queue_internal.h \
  ${srcdir}/include/odp_queue_scalable_internal.h \
diff --git a/platform/linux-generic/include/odp_pool_internal.h 
b/platform/linux-generic/include/odp_pool_internal.h
index 35dd013e7..15b381935 100644
--- a/platform/linux-generic/include/odp_pool_internal.h
+++ b/platform/linux-generic/include/odp_pool_internal.h
@@ -21,7 +21,7 @@ extern "C" {
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platform/linux-generic/pool/subsystem.c 
b/platform/linux-generic/pool/subsystem.c
index 073a9fa98..dca9284a7 100644
--- a/platform/linux-generic/pool/subsystem.c
+++ b/platform/linux-generic/pool/subsystem.c
@@ -7,7 +7,7 @@
  */
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define SUBSYSTEM_VERSION 0x0001UL

Re: [lng-odp] [PATCH API-NEXT v4 1/3] api: ipsec: rework ODP_IPSEC_SA_DISABLE into packet error

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Wednesday, October 25, 2017 12:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v4 1/3] api: ipsec: rework
> ODP_IPSEC_SA_DISABLE into packet error
> 
> From: Dmitry Eremin-Solenikov 
> 
> According to the discussion on mailing list, most of implementations
> will not be able to support odp_ipsec_sa_disable() status event
> directly.  Instead they will submit a dummy packet to that SA. Then
> after receiving this packet after odp_ipsec_result() will detect this
> packet and will report it as a packet with
> odp_ipsec_error_t->sa_disabled bit set.
> 
> Signed-off-by: Dmitry Eremin-Solenikov 
> Cc: Nikhil Agarwal 
> Cc: Balasubramanian Manoharan 
> ---
> /** Email created from pull request 256 (lumag:ipsec_sa_disable_v2)
>  ** https://github.com/Linaro/odp/pull/256
>  ** Patch: https://github.com/Linaro/odp/pull/256.patch
>  ** Base sha: 825f75ed8644ef57c5648961e7982daf13cd9375
>  ** Merge commit sha: ba520d0a3f4c46777c7aedca029e9979a89c69e7
>  **/
>  include/odp/api/spec/ipsec.h | 44 ---
> -
>  1 file changed, 20 insertions(+), 24 deletions(-)
> 
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index 26e852fca..b9ad282ce 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -843,10 +843,12 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const
> odp_ipsec_sa_param_t *param);
>   *
>   * When in synchronous operation mode, the call will return when it's
> possible
>   * to destroy the SA. In asynchronous mode, the same is indicated by an
> - * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA.
> The
> - * status event is guaranteed to be the last event for the SA, i.e. all
> - * in-progress operations have completed and resulting events (including
> status
> - * events) have been enqueued before it.
> + * artificial packet event sent to the queue specified for the SA having
> + * sa_disabled error bit set in the odp_ipsec_packet_result_t returned by
> + * odp_ipsec_result(). The packet is guaranteed to be the last event for
> + * the SA, i.e. all in-progress operations have completed and resulting
> events
> + * (including status events) have been enqueued before it. No packets
> will come
> + * from SA after this one.

This still lacks the definition of what is the difference between an artificial 
packet vs a normal packet. We could define it e.g. by saying that length is 
always zero and application must not do anything else with it than free it. But 
then, why it's a packet anyway? Why it would not then be e.g. a ipsec status 
event (which is not a packet, but could be implemented as an artificial packet).

The idea of event type vs sub-event type is that:
 1) all events of the same base type (e.g. packet) contain the same metadata 
and can be processed the same way. For example, someone may write a generic 
packet statistics (application) module, and plug that before and after an ipsec 
termination (application) module, without need to know that packets before 
ipsec module carry extra ipsec metadata (from inline inbound ipsec).
 2) sub-type adds metadata and other properties to the base type

An artificial packet would not fit in either category, it would be a non-packet.

Usually, application receives multiple event types anyway: e.g. packets and 
timeouts. So, for application it would not be an issue to have one additional 
switch-case for IPSEC status events. API integrity is more important than 
(potential) save of couple if-else branches.

So, I think this solution is not complete yet and I don't see how it would in 
the end make a real difference to the current status event API.

-Petri

Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata

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

I sent v3 which adds data range as output. There are small differences between 
NICs on what is included to the sum, e.g. some include IP options, others 
don't. So, it's better not to force all implementations to the same data range, 
since (as Janne said) it would cause implementations to always adjust the sum - 
also when an application is not interested about it. Sum cannot be "lazy" 
adjusted as application might have modified the data already.

-Petri


> -Original Message-
> From: Peltonen, Janne (Nokia - FI/Espoo)
> Sent: Thursday, October 26, 2017 11:45 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) ;
> Github ODP bot ; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement
> metadata
> 
> As discussed offline with Petri, I feel that it would be useful
> to let the ODP implementation tell from which packet offset the
> sum calculation starts (or even let the implementation specify
> the range, i.e. also the end).
> 
> The rationale is that even though starting from L4 offset is
> reasonable from API point-of-view, different HW may start the
> sum calculation from different offsets and fixing the sum in
> SW is somewhat costly in those cases where the application is
> not actually interested in the sum, for example:
> 
> - An application both forwards packets receives packets locally
>   and needs checksum checking only for the locally received packets.
> - An application receives all incoming traffic locally, but drops
>   some of it before it event wants to check the checksum (e.g.
>   QoS filtering, one fragment lost, packet to wrong TCP port).
> 
>   Janne
> 
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Savolainen, Petri
> > (Nokia - FI/Espoo)
> > Sent: Thursday, October 26, 2017 10:00 AM
> > To: Github ODP bot ; lng-odp@lists.linaro.org
> > Subject: Suspected SPAM - Re: [lng-odp] [PATCH API-NEXT v2 0/3] api:
> ones complement
> > metadata
> >
> > [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn
> > about spoofing at http://aka.ms/LearnAboutSpoofing]
> >
> > Ping.
> >
> > > -Original Message-
> > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > > Github ODP bot
> > > Sent: Monday, October 23, 2017 1:00 PM
> > > To: lng-odp@lists.linaro.org
> > > Subject: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement
> metadata
> > >
> > > Added packet metadata for ones complement sum over IP
> > > payload in a packet. Some NICs calculate the sum
> > > during packet input (at least for IP fragments) and
> > > store the value into the packet descriptor. This offloads
> > > L4 checksum calculation for IP fragments as SW does not
> > > need sum all payload data, but just combine pre-calculated
> > > sums from packet descriptors and remove extra header fields
> > > from the sum.

[lng-odp] [PATCH API-NEXT v1 1/1] validation: shmem: compare info page size to all supported huge page sizes

[Github ODP bot]

From: Matias Elo 

Compare odp_shm_info_t.page_size to all supported page sizes on the system.
This enables passing the test when shmem is not allocated using the
system's default huge page size.

Signed-off-by: Matias Elo 
---
/** Email created from pull request 260 (matiaselo:dev/update_shmem_test)
 ** https://github.com/Linaro/odp/pull/260
 ** Patch: https://github.com/Linaro/odp/pull/260.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 785d0e1f77855f70bff3e787b2c9c7fc340eae13
 **/
 test/validation/api/shmem/shmem.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/test/validation/api/shmem/shmem.c 
b/test/validation/api/shmem/shmem.c
index d5335afa9..d1abc62bb 100644
--- a/test/validation/api/shmem/shmem.c
+++ b/test/validation/api/shmem/shmem.c
@@ -80,6 +80,7 @@ static int run_test_basic_thread(void *arg ODP_UNUSED)
odp_shm_t shm;
shared_test_data_t *shared_test_data;
int thr;
+   int pagesz_match = 0;
 
thr = odp_thread_id();
printf("Thread %i starts\n", thr);
@@ -98,8 +99,27 @@ static int run_test_basic_thread(void *arg ODP_UNUSED)
CU_ASSERT(0 == info.flags);
CU_ASSERT(shared_test_data == info.addr);
CU_ASSERT(sizeof(shared_test_data_t) <= info.size);
-   CU_ASSERT((info.page_size == odp_sys_huge_page_size()) ||
- (info.page_size == odp_sys_page_size()))
+
+   if (info.page_size == odp_sys_page_size()) {
+   pagesz_match = 1;
+   } else {
+   int num = odp_sys_huge_page_size_all(NULL, 0);
+
+   if (num > 0) {
+   uint64_t pagesz_tbs[num];
+   int i;
+
+   num = odp_sys_huge_page_size_all(pagesz_tbs, num);
+   for (i = 0; i < num; i++) {
+   if (info.page_size == pagesz_tbs[i]) {
+   pagesz_match = 1;
+   break;
+   }
+   }
+   }
+   }
+   CU_ASSERT(pagesz_match == 1);
+
odp_shm_print_all();
 
fflush(stdout);

[lng-odp] [PATCH API-NEXT v1 0/1] validation: shmem: compare info page size to all supported huge page sizes

[Github ODP bot]

Compare odp_shm_info_t.page_size to all supported page sizes on the system.
This enables passing the test when shmem is not allocated using the
system's default huge page size.
Signed-off-by: Matias Elo matias@nokia.com

github
/** Email created from pull request 260 (matiaselo:dev/update_shmem_test)
 ** https://github.com/Linaro/odp/pull/260
 ** Patch: https://github.com/Linaro/odp/pull/260.patch
 ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
 ** Merge commit sha: 785d0e1f77855f70bff3e787b2c9c7fc340eae13
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 36 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

Re: [lng-odp] API-next branch

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

Hi,

It's not so trivial to draw a line what is a small change. E.g. one word change 
in documentation may be a big change for an application: "ODP maintains packet 
order during operation X" vs "... does not maintain order ..."

So, it's much simpler if all API changes go through the same branch, and that 
branch is released often.

One of the largest motivation to change to github was to enable easy (and fast) 
release cycle, since all commits are always check automatically in Travis. So, 
there should be now less work to make a release. 

Tomorrow is the last Friday of the month and a perfect day for making a release 
(1.16) of everything that is ready in api-next... Maybe it's only couple of new 
APIs and some typo corrections, but it still makes the delta that much smaller.

-Petri


From: Maxim Uvarov [mailto:maxim.uva...@linaro.org] 
Sent: Thursday, October 26, 2017 10:30 AM
To: Savolainen, Petri (Nokia - FI/Espoo) 
Cc: Bill Fischofer ; Dmitry Eremin-Solenikov 
; lng-odp-forward 
Subject: Re: [lng-odp] API-next branch

1. we have api-next branch to collect all api changes with implementation in 
tests in one places. A lot of people said that it's useful.
2. Yes it's hard to find patches which are in api-next and not in master.
3.  New API acceptance period is not very clean.  If we can improve that than 
probably we will resolve merge issue.

I.e. my proposal is  - if feature is complete (api, impl, tests) and  accepted 
(members can implement it)  all patches for this feature should be moved to 
master branch. No need to wait for release date.
From other point there is no need for small api changes (like debug prints, 
pktio capabilities, small improvements) stage in api-next. They can go directly 
to master.
The other deal is complex things which need several months for review.  This 
should go to staging branch api-next .

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

How about that?

Maxim.


On 26 October 2017 at 09:57, Savolainen, Petri (Nokia - FI/Espoo) 
 wrote:
We need one branch that holds all new API changes before those are released (> 
4 months currently): either it's master or api-next. If we change API 
development to master, then applications would need follow the latest release 
branch instead of master. At least previous there was resistance to change 
master into API development branch.

Separate topic branches for API changes won't scale ... we would not have a 
common view (e.g. for 4 months) what the API is before all those are merged 
together. Implementation changes are easier in topic branches as there's less 
dependency to other files and applications (other files and apps already agree 
what the API is).

Api-next does not cause the problem (big delta), it's caused by the lack of 
steady release cycle. The big  delta won't go away before we have a short 
enough release cycle (merge often => small delta).

-Petri



> -Original Message-
> From: lng-odp [mailto:mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Bill
> Fischofer
> Sent: Wednesday, October 25, 2017 6:53 PM
> To: Dmitry Eremin-Solenikov 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] API-next branch
>
> I'm all for using topic branches, especially since we've switched to
> GitHub
> and most contributors are now familiar with it and using pull requests
> rather than raw patches sent to the mailing list. The whole reason for
> api-next was to separate in-progress API changes from regular maintenance
> patches since they were all mixed together on the mailing list. The PR
> structure is much cleaner in that regard.
>
> IPsec in particular clearly could have been a separate branch. We've
> talked
> about doing this in the context of 2.0 as well since that's also going to
> involve some major subsystems that could benefit from collaborative
> development before being merged back into the 2.0 main development branch.
>
>
> On Wed, Oct 25, 2017 at 10:39 AM, Dmitry Eremin-Solenikov <
> mailto:dmitry.ereminsoleni...@linaro.org> wrote:
>
> > Hello,
> >
> > I tried to actually check, which patches are sitting in the api-next.
> > And actually I failed
> > to do that in a timely manner. git cherry produces a list of patches,
> > that contains a lot of patches, which already landed to the master.
> >
> > Quick proposal would be to stop using api-next as a long-lived branch
> > which received updates from master and rather use it as a branch being
> > regularly rebased on top of current master.
> >
> > Another possiblity would be to abandon api-next completely, develop
> > features on topic branches, which get merged to master, rather than to
> > api-next. At least this would save us from situations, when there is
> > API definition (or change)

[lng-odp] [PATCH 2.0 v1 2/2] linux-gen: packet: add generic implementation module

[Github ODP bot]

From: Kevin Wang 

Signed-off-by: Kevin Wang 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Yi He 
---
/** Email created from pull request 259 (kevinwangsk:2.0-packet-PR)
 ** https://github.com/Linaro/odp/pull/259
 ** Patch: https://github.com/Linaro/odp/pull/259.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 829dfecf60422dc6aa72a05aba3ebe3526526c6a
 **/
 platform/linux-generic/Makefile.am |   6 +-
 .../include/odp/api/plat/packet_flag_inlines.h |  16 -
 .../include/odp/api/plat/packet_flag_inlines_api.h |  41 --
 .../include/odp/api/plat/packet_inlines.h  |  13 -
 .../include/odp/api/plat/packet_inlines_api.h  | 113 ---
 .../linux-generic/include/odp_packet_internal.h|   1 +
 .../linux-generic/include/odp_packet_subsystem.h   |  34 +-
 platform/linux-generic/odp_packet_flags.c  | 306 
 .../{odp_packet.c => packet/generic.c} | 811 ++---
 platform/linux-generic/packet/subsystem.c  | 678 +
 10 files changed, 1397 insertions(+), 622 deletions(-)
 delete mode 100644 
platform/linux-generic/include/odp/api/plat/packet_flag_inlines_api.h
 delete mode 100644 
platform/linux-generic/include/odp/api/plat/packet_inlines_api.h
 delete mode 100644 platform/linux-generic/odp_packet_flags.c
 rename platform/linux-generic/{odp_packet.c => packet/generic.c} (67%)

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 06c1d8a24..d618a9414 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -97,9 +97,7 @@ odpapiplatinclude_HEADERS = \
  $(srcdir)/include/odp/api/plat/init_types.h \
  $(srcdir)/include/odp/api/plat/ipsec_types.h \
  $(srcdir)/include/odp/api/plat/packet_flag_inlines.h \
- $(srcdir)/include/odp/api/plat/packet_flag_inlines_api.h \
  $(srcdir)/include/odp/api/plat/packet_inlines.h \
- $(srcdir)/include/odp/api/plat/packet_inlines_api.h \
  $(srcdir)/include/odp/api/plat/packet_types.h \
  $(srcdir)/include/odp/api/plat/packet_io_types.h \
  $(srcdir)/include/odp/api/plat/pool_types.h \
@@ -238,9 +236,8 @@ __LIB__libodp_linux_la_SOURCES = \
   odp_impl.c \
   odp_ipsec.c \
   odp_name_table.c \
-  odp_packet.c \
-  odp_packet_flags.c \
   odp_packet_io.c \
+  packet/generic.c \
   packet/subsystem.c \
   pktio/ethtool.c \
   pktio/subsystem.c \
@@ -356,6 +353,7 @@ endif
 
 pool/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 buffer/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
+packet/generic.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 if ODP_SCHEDULE_SCALABLE
 schedule/scalable.lo: AM_CFLAGS += -DIM_ACTIVE_MODULE
 else
diff --git a/platform/linux-generic/include/odp/api/plat/packet_flag_inlines.h 
b/platform/linux-generic/include/odp/api/plat/packet_flag_inlines.h
index 42003e317..ed41fb92f 100644
--- a/platform/linux-generic/include/odp/api/plat/packet_flag_inlines.h
+++ b/platform/linux-generic/include/odp/api/plat/packet_flag_inlines.h
@@ -70,20 +70,4 @@ static inline int _odp_packet_has_ts(odp_packet_t pkt)
return flags.timestamp;
 }
 
-/* Include inlined versions of API functions */
-#include 
-#if ODP_ABI_COMPAT == 0
-
-/** @ingroup odp_packet
- *  @{
- */
-
-#include 
-
-/**
- * @}
- */
-
-#endif
-
 #endif
diff --git 
a/platform/linux-generic/include/odp/api/plat/packet_flag_inlines_api.h 
b/platform/linux-generic/include/odp/api/plat/packet_flag_inlines_api.h
deleted file mode 100644
index f4e143aa0..0
--- a/platform/linux-generic/include/odp/api/plat/packet_flag_inlines_api.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/* Copyright (c) 2017, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @file
- *
- * Packet inline functions
- */
-
-#ifndef _ODP_PLAT_PACKET_FLAG_INLINES_API_H_
-#define _ODP_PLAT_PACKET_FLAG_INLINES_API_H_
-
-_ODP_INLINE int odp_packet_has_l2(odp_packet_t pkt)
-{
-   return _odp_packet_has_l2(pkt);
-}
-
-_ODP_INLINE int odp_packet_has_eth(odp_packet_t pkt)
-{
-   return _odp_packet_has_eth(pkt);
-}
-
-_ODP_INLINE int odp_packet_has_jumbo(odp_packet_t pkt)
-{
-   return _odp_packet_has_jumbo(pkt);
-}
-
-_ODP_INLINE int odp_packet_has_flow_hash(odp_packet_t pkt)
-{
-   return _odp_packet_has_flow_hash(pkt);
-}
-
-_ODP_INLINE int odp_packet_has_ts(odp_packet_t pkt)
-{
-   return _odp_packet_has_ts(pkt);
-}
-
-#endif
diff --git a/platform/linux-generic/include/odp/api/plat/packet_inlines.h 
b/platform/linux-generic/include/odp/api/plat/packet_inlines.h
index 1804fa6f2..8ed5ffbf0 100644
--- a/platform/linux-generic/include/odp/api/p

[lng-odp] [PATCH 2.0 v1 0/2] Move packet to modular framework

[Github ODP bot]

github
/** Email created from pull request 259 (kevinwangsk:2.0-packet-PR)
 ** https://github.com/Linaro/odp/pull/259
 ** Patch: https://github.com/Linaro/odp/pull/259.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 829dfecf60422dc6aa72a05aba3ebe3526526c6a
 **/
/github

checkpatch.pl
WARNING: line over 80 characters
#135: FILE: platform/linux-generic/include/odp_packet_subsystem.h:84:
+ODP_SUBSYSTEM_API(packet, odp_packet_t, copy, odp_packet_t pkt, odp_pool_t 
pool);

WARNING: line over 80 characters
#143: FILE: platform/linux-generic/include/odp_packet_subsystem.h:92:
+ uint32_t dst_offset, odp_packet_t src, uint32_t src_offset, 
uint32_t len);

WARNING: line over 80 characters
#151: FILE: platform/linux-generic/include/odp_packet_subsystem.h:100:
+ODP_SUBSYSTEM_API(packet, void, user_ptr_set, odp_packet_t pkt, const void 
*ctx);

WARNING: line over 80 characters
#156: FILE: platform/linux-generic/include/odp_packet_subsystem.h:105:
+ODP_SUBSYSTEM_API(packet, int, l2_offset_set, odp_packet_t pkt, uint32_t 
offset);

WARNING: line over 80 characters
#159: FILE: platform/linux-generic/include/odp_packet_subsystem.h:108:
+ODP_SUBSYSTEM_API(packet, int, l3_offset_set, odp_packet_t pkt, uint32_t 
offset);

WARNING: line over 80 characters
#162: FILE: platform/linux-generic/include/odp_packet_subsystem.h:111:
+ODP_SUBSYSTEM_API(packet, int, l4_offset_set, odp_packet_t pkt, uint32_t 
offset);

WARNING: line over 80 characters
#166: FILE: platform/linux-generic/include/odp_packet_subsystem.h:115:
+ODP_SUBSYSTEM_API(packet, void, flow_hash_set, odp_packet_t pkt, uint32_t 
flow_hash);

WARNING: line over 80 characters
#170: FILE: platform/linux-generic/include/odp_packet_subsystem.h:119:
+ODP_SUBSYSTEM_API(packet, void, color_set, odp_packet_t pkt, 
odp_packet_color_t color);

WARNING: line over 80 characters
#172: FILE: platform/linux-generic/include/odp_packet_subsystem.h:121:
+ODP_SUBSYSTEM_API(packet, void, drop_eligible_set, odp_packet_t pkt, 
odp_bool_t status);

WARNING: line over 80 characters
#174: FILE: platform/linux-generic/include/odp_packet_subsystem.h:123:
+ODP_SUBSYSTEM_API(packet, void, shaper_len_adjust_set, odp_packet_t pkt, 
int8_t adj);

WARNING: line over 80 characters
#309: FILE: platform/linux-generic/include/odp_packet_subsystem.h:258:
+   odp_api_proto(packet, shaper_len_adjust_set) 
packet_shaper_len_adjust_set;

total: 0 errors, 11 warnings, 0 checks, 350 lines checked


to_send-p-000.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WARNING: Macros with flow control statements should be avoided
#712: FILE: platform/linux-generic/packet/generic.c:30:
+#define retflag(pkt, x) do { \
+   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt); \
+   return pkt_hdr->p.x; \
+   } while (0)
+

total: 0 errors, 1 warnings, 0 checks, 2101 lines checked


to_send-p-001.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
/checkpatch.pl

[lng-odp] [PATCH 2.0 v1 1/2] linux-gen: packet: apply modular framework and create subsystem

[Github ODP bot]

From: Kevin Wang 

Signed-off-by: Kevin Wang 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Brian Brooks 
Reviewed-by: Yi He 
---
/** Email created from pull request 259 (kevinwangsk:2.0-packet-PR)
 ** https://github.com/Linaro/odp/pull/259
 ** Patch: https://github.com/Linaro/odp/pull/259.patch
 ** Base sha: d37aa7f1c0480273fb0ccfded44a13e3e5a8e42f
 ** Merge commit sha: 829dfecf60422dc6aa72a05aba3ebe3526526c6a
 **/
 platform/linux-generic/Makefile.am |   2 +
 .../linux-generic/include/odp_packet_subsystem.h   | 318 +
 platform/linux-generic/packet/subsystem.c  |  18 ++
 3 files changed, 338 insertions(+)
 create mode 100644 platform/linux-generic/include/odp_packet_subsystem.h
 create mode 100644 platform/linux-generic/packet/subsystem.c

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 277418142..06c1d8a24 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -175,6 +175,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_packet_internal.h \
  ${srcdir}/include/odp_packet_io_internal.h \
  ${srcdir}/include/odp_packet_io_ring_internal.h \
+ ${srcdir}/include/odp_packet_subsystem.h \
  ${srcdir}/pktio/ethtool.h \
  ${srcdir}/pktio/common.h \
  ${srcdir}/pktio/dpdk.h \
@@ -240,6 +241,7 @@ __LIB__libodp_linux_la_SOURCES = \
   odp_packet.c \
   odp_packet_flags.c \
   odp_packet_io.c \
+  packet/subsystem.c \
   pktio/ethtool.c \
   pktio/subsystem.c \
   pktio/ipc.c \
diff --git a/platform/linux-generic/include/odp_packet_subsystem.h 
b/platform/linux-generic/include/odp_packet_subsystem.h
new file mode 100644
index 0..1160b96b8
--- /dev/null
+++ b/platform/linux-generic/include/odp_packet_subsystem.h
@@ -0,0 +1,318 @@
+/* Copyright (c) 2017, ARM Limited. All rights reserved.
+ *
+ * Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+#ifndef ODP_PACKET_SUBSYSTEM_H_
+#define ODP_PACKET_SUBSYSTEM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+
+#define PACKET_SUBSYSTEM_VERSION 0x0001UL
+
+/* ODP packet public APIs subsystem */
+ODP_SUBSYSTEM_DECLARE(packet);
+
+/* Subsystem APIs declarations */
+ODP_SUBSYSTEM_API(packet, odp_packet_t, alloc, odp_pool_t pool,
+ uint32_t len);
+ODP_SUBSYSTEM_API(packet, int, alloc_multi, odp_pool_t pool,
+ uint32_t len, odp_packet_t pkt[], int num);
+ODP_SUBSYSTEM_API(packet, void, free, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, void, free_multi, const odp_packet_t pkt[], int num);
+ODP_SUBSYSTEM_API(packet, int, has_error, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, void, prefetch, odp_packet_t pkt,
+ uint32_t offset, uint32_t len);
+ODP_SUBSYSTEM_API(packet, void *, data, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, int, input_index, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, int, reset, odp_packet_t pkt, uint32_t len);
+ODP_SUBSYSTEM_API(packet, odp_packet_t, from_event, odp_event_t ev);
+ODP_SUBSYSTEM_API(packet, odp_event_t, to_event, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, void *, head, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, uint32_t, buf_len, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, uint32_t, seg_len, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, uint32_t, len, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, uint32_t, headroom, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, uint32_t, tailroom, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, void *, tail, odp_packet_t pkt);
+ODP_SUBSYSTEM_API(packet, void *, offset, odp_packet_t pkt, uint32_t offset,
+ uint32_t *len, odp_packet_seg_t *seg);
+ODP_SUBSYSTEM_API(packet, void *, push_head, odp_packet_t pkt, uint32_t len);
+ODP_SUBSYSTEM_API(packet, void *, pull_head, odp_packet_t pkt, uint32_t len);
+ODP_SUBSYSTEM_API(packet, void *, push_tail, odp_packet_t pkt, uint32_t len);
+ODP_SUBSYSTEM_API(packet, void *, pull_tail, odp_packet_t pkt, uint32_t len);
+ODP_SUBSYSTEM_API(packet, int, extend_head, odp_packet_t *pkt,
+ uint32_t len, void **data_ptr, uint32_t *seg_len);
+ODP_SUBSYSTEM_API(packet, int, trunc_head, odp_packet_t *pkt,
+ uint32_t len, void **data_ptr, uint32_t *seg_len);
+ODP_SUBSYSTEM_API(packet, int, extend_tail, odp_packet_t *pkt,
+ uint32_t len, void **data_ptr, uint32_t *seg_len);
+ODP_SUBSYSTEM_API(packet, int, trunc_tail, odp_packet_t *pkt,
+ uint32_t len, void **tail_ptr, uint32_t *tailroom);
+ODP_SUBSYSTEM_API(packet, int, add_data, odp_packet_t *pkt,
+ uint32_t offset, uint32_t len);
+ODP_SUBSYSTEM_API(packet, int, rem_data, odp_packet_t *pkt,
+   

Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata

[Peltonen, Janne (Nokia - FI/Espoo)]

As discussed offline with Petri, I feel that it would be useful
to let the ODP implementation tell from which packet offset the
sum calculation starts (or even let the implementation specify
the range, i.e. also the end).

The rationale is that even though starting from L4 offset is
reasonable from API point-of-view, different HW may start the
sum calculation from different offsets and fixing the sum in
SW is somewhat costly in those cases where the application is
not actually interested in the sum, for example:

- An application both forwards packets receives packets locally
  and needs checksum checking only for the locally received packets.
- An application receives all incoming traffic locally, but drops
  some of it before it event wants to check the checksum (e.g.
  QoS filtering, one fragment lost, packet to wrong TCP port).

Janne

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Savolainen, Petri
> (Nokia - FI/Espoo)
> Sent: Thursday, October 26, 2017 10:00 AM
> To: Github ODP bot ; lng-odp@lists.linaro.org
> Subject: Suspected SPAM - Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones 
> complement
> metadata
> 
> [This sender failed our fraud detection checks and may not be who they appear 
> to be. Learn
> about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> Ping.
> 
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Github ODP bot
> > Sent: Monday, October 23, 2017 1:00 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata
> >
> > Added packet metadata for ones complement sum over IP
> > payload in a packet. Some NICs calculate the sum
> > during packet input (at least for IP fragments) and
> > store the value into the packet descriptor. This offloads
> > L4 checksum calculation for IP fragments as SW does not
> > need sum all payload data, but just combine pre-calculated
> > sums from packet descriptors and remove extra header fields
> > from the sum.

[lng-odp] [Linaro/odp] 4fafec: linux-gen: netmap: use thread id to make vdev mac ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/Linaro/odp
  Commit: 4fafec8378b6e7d0b353d851e724ab27eb002b27
  
https://github.com/Linaro/odp/commit/4fafec8378b6e7d0b353d851e724ab27eb002b27
  Author: Matias Elo 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M platform/linux-generic/pktio/netmap.c

  Log Message:
  ---
  linux-gen: netmap: use thread id to make vdev mac addresses unique

Previously the mac addresses of virtual netmap devices would clash if
multiple odp processes were run on the same host.

Signed-off-by: Matias Elo 
Signed-off-by: Bill Fischofer 


  Commit: bd1b1adf37dd8d252f7daf761d4ae9a6d1ef156a
  
https://github.com/Linaro/odp/commit/bd1b1adf37dd8d252f7daf761d4ae9a6d1ef156a
  Author: Matias Elo 
  Date:   2017-10-26 (Thu, 26 Oct 2017)

  Changed paths:
M platform/linux-generic/pktio/netmap.c

  Log Message:
  ---
  linux-gen: netmap: remove minimum frame len check

Checking the minimum frame length is unnecessary as netmap drops truncated
frames internally.

Signed-off-by: Matias Elo 
Signed-off-by: Bill Fischofer 


Compare: https://github.com/Linaro/odp/compare/82419a31e6d1...bd1b1adf37dd

Re: [lng-odp] [PATCH v1] Netmap pktio fixes

[Github ODP bot]

muvarov replied on github web page:

platform/linux-generic/pktio/netmap.c
line 14
@@ -388,13 +389,22 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
 
if (pkt_nm->is_virtual) {
static unsigned mac;
+   uint32_t tid = syscall(SYS_gettid);
+
+   if ((int)tid == -1)


Comment:
@matiaselo @lumag  yep, I forgot that some syscalls might be not implemented on 
some systems, that  also will return error.

> Dmitry Eremin-Solenikov(lumag) wrote:
> @matiaselo yes, so this is fine.


>> Matias Elo(matiaselo) wrote:
>> syscall() specification still defines -1 as an error return value and we 
>> should adhere to the spec regardless of the function implementation which 
>> may change.


>>> muvarov wrote
>>> .


 muvarov wrote
 man gettid says that it always passes.
 
 kernel code is also:
 pid_t __task_pid_nr_ns(struct task_struct *task, enum pid_type type,
struct pid_namespace *ns)
 {
pid_t nr = 0;
 
rcu_read_lock();
if (!ns)
ns = task_active_pid_ns(current);
if (likely(pid_alive(task))) {
if (type != PIDTYPE_PID)
task = task->group_leader;
nr = pid_nr_ns(rcu_dereference(task->pids[type].pid), ns);
}
rcu_read_unlock();
 
return nr;
 }
 EXPORT_SYMBOL(__task_pid_nr_ns);
 
 I.e. it will return init process tid 0 in worst case. So this check is not 
 correct and not needed.
 
 It might be needed additional cast:
 uint32_t tid = (uint32_t)syscall(SYS_gettid) because of syscall returns 
 pid_t.


> muvarov wrote
> @lumag  we also use SYS_gettid() in shm and timer. I think that is not 
> subject for this PR. Just general clean up.


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> See 
>> [here](https://stackoverflow.com/questions/21279649/getting-error-in-c-program-undefined-reference-to-gettid)
>>  for an interesting discussion of why gettid() is not used.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> @matiaselo @muvarov Hmm. I thought that there is already a Glibc 
>>> wrapper. I would prefer this as a separate function, but it is of minor 
>>> priority then.


 muvarov wrote
 it was copied from netmap source  I think. gittid() will generate 
 warning due to missing glibc wrapper: 
 https://stackoverflow.com/questions/30680550/c-gettid-was-not-declared-in-this-scope
  Maybe something already changed...


> Matias Elo(matiaselo) wrote:
> What's the benefit from using gettid()? It seems like the only 
> difference is that gettid() cannot fail.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Why don't you use `gettid()` function? Then you can check for its 
>> existence in `configure.ac` and provide replacement implementation. 


https://github.com/Linaro/odp/pull/237#discussion_r147060031
updated_at 2017-10-26 07:09:00

Re: [lng-odp] API-next branch

[Maxim Uvarov]

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

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

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

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

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

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

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

How about that?

Maxim.


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

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

Re: [lng-odp] [PATCH API-NEXT v3 0/8] api: pool subparameters

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

Ping.

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Monday, October 23, 2017 3:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v3 0/8] api: pool subparameters
> 
> Added packet pool parameters for more fine grained pool
> configuration. The basic usage of the parameters is not changed,
> except that implementation may now round up 'num' by default.
> Application can limit the round up with new 'max_num' parameter.
> If application does not limit max_num (but is still interested on
> max_num value), it can check the new info.pkt.max_num.
> The new specification allows implementation to use sub-pools,
> also application is able to request e.g. this kind of pool:

Re: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata

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

Ping.

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Monday, October 23, 2017 1:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v2 0/3] api: ones complement metadata
> 
> Added packet metadata for ones complement sum over IP
> payload in a packet. Some NICs calculate the sum
> during packet input (at least for IP fragments) and
> store the value into the packet descriptor. This offloads
> L4 checksum calculation for IP fragments as SW does not
> need sum all payload data, but just combine pre-calculated
> sums from packet descriptors and remove extra header fields
> from the sum.