Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files

2017-06-02 Thread Honnappa Nagarahalli
On 1 June 2017 at 02:43, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org]
>> Sent: Wednesday, May 31, 2017 9:03 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> Cc: Brian Brooks ; lng-odp@lists.linaro.org; Ola
>> Liljedahl 
>> Subject: Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files
>>
>> On 31 May 2017 at 03:02, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org]
>> >> Sent: Wednesday, May 31, 2017 6:11 AM
>> >> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> >> Cc: Brian Brooks ; lng-odp@lists.linaro.org; Ola
>> >> Liljedahl 
>> >> Subject: Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files
>> >>
>> >> On 24 May 2017 at 06:55, Savolainen, Petri (Nokia - FI/Espoo)
>> >>  wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org]
>> >> >> Sent: Wednesday, May 24, 2017 6:59 AM
>> >> >> To: Savolainen, Petri (Nokia - FI/Espoo)
>> 
>> >> >> Cc: Brian Brooks ; lng-odp@lists.linaro.org;
>> Ola
>> >> >> Liljedahl 
>> >> >> Subject: Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files
>> >> >>
>> >> >> On 23 May 2017 at 02:10, Savolainen, Petri (Nokia - FI/Espoo)
>> >> >>  wrote:
>> >> >> >> diff --git a/platform/linux-generic/arch/powerpc/odp_cpu.h
>> >> >> >> b/platform/linux-generic/arch/powerpc/odp_cpu.h
>> >> >> >> new file mode 100644
>> >> >> >> index ..e118e709
>> >> >> >> --- /dev/null
>> >> >> >> +++ b/platform/linux-generic/arch/powerpc/odp_cpu.h
>> >> >> >> @@ -0,0 +1,10 @@
>> >> >> >> +/* Copyright (c) 2017, Linaro Limited
>> >> >> >> + * All rights reserved.
>> >> >> >> + *
>> >> >> >> + * SPDX-License-Identifier: BSD-3-Clause
>> >> >> >> + */
>> >> >> >> +
>> >> >> >> +#ifndef ODP_POWERPC_CPU_H_
>> >> >> >> +#define ODP_POWERPC_CPU_H_
>> >> >> >> +
>> >> >> >> +#endif
>> >> >> >
>> >> >> >
>> >> >> > Does this patch break build for all other archs but arm and x86?
>> >> >> Shouldn't you do the same (dummy) definitions for all architectures,
>> as
>> >> >> you do for x86?
>> >> >> >
>> >> >> > Odp-linux should be usable in any system that runs Linux. It's not
>> >> >> practical to test on every arch, but we should always offer the
>> default
>> >> >> code path that builds and should work fine on any arch. For example,
>> I
>> >> did
>> >> >> cross compile my latest x86 specific changes for PowerPC to see that
>> a
>> >> >> non-x86 path also builds.
>> >> >> >
>> >> >>
>> >> >> We do not have the environment to compile for PowerPC or MIPS. Even
>> if
>> >> >> we write dummy functions, we will not be able to compile the code
>> for
>> >> >> those targets. During our earlier discussions, there was an
>> agreement
>> >> >> that we will not do this for PowerPC or MIPS. Respective arch owners
>> >> >> have to create those functions.
>> >> >
>> >> > ODP dependencies file have some instructions for cross compiling.
>> With
>> >> Ubuntu you just need to install some extra packages. E.g.
>> >> >
>> >> > sudo apt-get install gcc-powerpc-linux-gnu
>> >> >
>> >> > So, you have the environment to build for e.g. PowerPC. Since odp-
>> linux
>> >> is for everybody (not only x86 and arm), you must not break the build
>> for
>> >> others. You may offer the minimal support, dummy functions, something
>> that
>> >> is functionally correct but not optimized - but you must not break the
>> >> build.
>> >> >
>> >>
>> >> Why would we have code which is not tested? Successful compilation
>> >> does not mean, the code would work. It is better that compilation
>> >> fails rather than things not work during run time.
>> >>
>> >> Does ODP claim it supports PowerPC? As far as I know, it claims it is
>> >> supported on Linux. In that case, why not use the 'default' in arch
>> >> directory for PowerPC?
>> >>
>> >> What about MIPS?
>> >>
>> >> What about Kalray?
>> >>
>> >> What is the version of the gcc compiler that needs to be used?
>> >>
>> >> What about support for Clang on PowerPC and MIPS? What is the Clang
>> >> version we need to support?
>> >>
>> >> These builds are in ODP CI.
>> >>
>> >> We had agreed that support for PowerPC and MIPS needs to come from
>> >> respective owners.
>> >
>> >
>> > Odp-linux should build and run where ever you have Linux. Obviously, we
>> cannot guarantee the quality without testing, but we must not deliberately
>> break the build. After every commit, makefiles rules and potential arch
>> files/functions must be present to build for MIPS/PPC/Kalray etc. You
>> 

Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files

2017-06-02 Thread Honnappa Nagarahalli
On 1 June 2017 at 02:22, Dmitry Eremin-Solenikov
 wrote:
> On 31.05.2017 21:03, Honnappa Nagarahalli wrote:
>> On 31 May 2017 at 03:02, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>>>
>>>
>>> Arch specific code is not commonly added into odp-linux, but when you do 
>>> add it you need to try hard not to break the code for others. You can test 
>>> the C generic also on ARM/x86, before turning the asm optimized version the 
>>> default. So, also without a PPC target you can develop/test the C generic 
>>> path (on ARM/x86) and build it for PPC to check that makefiles and #ifdefs 
>>> are OK.
>>
>> This is how the scope of the work increases unnecessarily. As we had
>> agreed during our discussions, functions for MIPS and PowerPC code
>> should be provided by the respective maintainers. It is not possible
>> to compile for 8 different targets ourselves.
>>
>> ODP does not run the CI for these 2 targets.
>>
>> Why not fold these two targets into default?
>
> Exactly. Do you provide default target non-specific implementation?

The 'default' directory in arch directory cannot be compiled. The code
under x86 is generic enough and is non-target specific implementation.

>
> --
> With best wishes
> Dmitry


[lng-odp] [PATCH API-NEXT v5 1/1] linux-generic: queue: modular queue interface

2017-06-02 Thread Github ODP bot
From: Honnappa Nagarahalli 

Created abstract queue type. Queue APIs and functions towards the
internal components are converted into function pointers.

Signed-off-by: Honnappa Nagarahalli 
---
/** Email created from pull request 43 (nagarahalli:api-next-mod-queue1)
 ** https://github.com/Linaro/odp/pull/43
 ** Patch: https://github.com/Linaro/odp/pull/43.patch
 ** Base sha: 57783b35f4383bdfdd146f2abbc8bb995896
 ** Merge commit sha: 9b21e1979ace878bb44efcfb9b40922b706ea7e8
 **/
 platform/linux-generic/Makefile.am |   2 +
 .../include/odp_classification_datamodel.h |   4 +-
 .../linux-generic/include/odp_packet_io_queue.h|  20 +-
 platform/linux-generic/include/odp_queue_if.h  | 104 
 .../linux-generic/include/odp_queue_internal.h |  41 +---
 platform/linux-generic/include/odp_schedule_if.h   |   2 +-
 .../include/odp_traffic_mngr_internal.h|   4 +-
 platform/linux-generic/odp_classification.c|  10 +-
 platform/linux-generic/odp_init.c  |  17 +-
 platform/linux-generic/odp_packet_io.c |  90 ---
 platform/linux-generic/odp_queue.c | 261 +++--
 platform/linux-generic/odp_queue_if.c  | 103 
 platform/linux-generic/odp_schedule.c  |   6 +-
 platform/linux-generic/odp_schedule_iquery.c   |   6 +-
 platform/linux-generic/odp_schedule_sp.c   |   4 +-
 platform/linux-generic/odp_traffic_mngr.c  |  21 +-
 platform/linux-generic/pktio/loop.c|  13 +-
 17 files changed, 515 insertions(+), 193 deletions(-)
 create mode 100644 platform/linux-generic/include/odp_queue_if.h
 create mode 100644 platform/linux-generic/odp_queue_if.c

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 79f0e70c..58c73767 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -170,6 +170,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_posix_extensions.h \
  ${srcdir}/include/odp_queue_internal.h \
  ${srcdir}/include/odp_ring_internal.h \
+ ${srcdir}/include/odp_queue_if.h \
  ${srcdir}/include/odp_schedule_if.h \
  ${srcdir}/include/odp_sorted_list_internal.h \
  ${srcdir}/include/odp_shm_internal.h \
@@ -225,6 +226,7 @@ __LIB__libodp_linux_la_SOURCES = \
   odp_pkt_queue.c \
   odp_pool.c \
   odp_queue.c \
+  odp_queue_if.c \
   odp_rwlock.c \
   odp_rwlock_recursive.c \
   odp_schedule.c \
diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index 9df756bf..fbe10cb4 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -24,7 +24,7 @@ extern "C" {
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 /* Maximum Class Of Service Entry */
@@ -85,7 +85,7 @@ typedef struct pmr_term_value {
 Class Of Service
 */
 struct cos_s {
-   queue_entry_t *queue;   /* Associated Queue */
+   queue_t queue;  /* Associated Queue */
odp_pool_t pool;/* Associated Buffer pool */
union pmr_u *pmr[ODP_PMR_PER_COS_MAX];  /* Chained PMR */
union cos_u *linked_cos[ODP_PMR_PER_COS_MAX]; /* Chained CoS with PMR*/
diff --git a/platform/linux-generic/include/odp_packet_io_queue.h 
b/platform/linux-generic/include/odp_packet_io_queue.h
index d1d4b225..71333ddc 100644
--- a/platform/linux-generic/include/odp_packet_io_queue.h
+++ b/platform/linux-generic/include/odp_packet_io_queue.h
@@ -18,7 +18,7 @@
 extern "C" {
 #endif
 
-#include 
+#include 
 #include 
 #include 
 
@@ -28,20 +28,18 @@ extern "C" {
 ODP_STATIC_ASSERT(ODP_PKTIN_QUEUE_MAX_BURST >= QUEUE_MULTI_MAX,
  "ODP_PKTIN_DEQ_MULTI_MAX_ERROR");
 
-int pktin_enqueue(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr);
-odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *queue);
+int pktin_enqueue(queue_t queue, odp_buffer_hdr_t *buf_hdr);
+odp_buffer_hdr_t *pktin_dequeue(queue_t queue);
 
-int pktin_enq_multi(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr[], int 
num);
-int pktin_deq_multi(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr[], int 
num);
+int pktin_enq_multi(queue_t queue, odp_buffer_hdr_t *buf_hdr[], int num);
+int pktin_deq_multi(queue_t queue, odp_buffer_hdr_t *buf_hdr[], int num);
 
 
-int pktout_enqueue(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr);
-odp_buffer_hdr_t *pktout_dequeue(queue_entry_t *queue);
+int pktout_enqueue(queue_t queue, odp_buffer_hdr_t *buf_hdr);
+odp_buffer_hdr_t *pktout_dequeue(queue_t queue);
 

[lng-odp] [API-NEXT PATCH] linux-generic: time: add additional doxygen doc for time type

2017-06-02 Thread Bill Fischofer
Latest doxygen requires all items to be documented so add doxygen for
enclosing union around variant time types.

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp/api/plat/time_types.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/platform/linux-generic/include/odp/api/plat/time_types.h 
b/platform/linux-generic/include/odp/api/plat/time_types.h
index 71e354e6..e7111c8c 100644
--- a/platform/linux-generic/include/odp/api/plat/time_types.h
+++ b/platform/linux-generic/include/odp/api/plat/time_types.h
@@ -26,6 +26,7 @@ extern "C" {
  * implementations.
  */
 typedef struct odp_time_t {
+   /** @internal Variant mappings for time type */
union {
/** @internal Used with generic 64 bit operations */
uint64_t u64;
-- 
2.11.0



Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Maxim Uvarov
On 06/02/17 18:36, Brian Brooks wrote:
> On 06/02 15:07:48, Maxim Uvarov wrote:
>> I think this patch has to be spit on several patches. Having patch which
>> correct unrelated things is strange and make it hard to merge/cherry-pick.
> 
> They are all related to things that break the build with GCC 7. It's
> unnecessary and extra complexity to split it up into more than one patch.
> The single patch is small and easily reviewable anyway.
> 

Idea here is the following. Different odp implementations can inherit
specific parts of mainline ODP to their code. For example changes to
configure.ac might be sufficient for odp-dpdk and change to fix pktio
name is not. Other platform developers prefer to take entire commit
from linux-generic with git cherry-pick  command.

Maxim.




>>
>> Maxim.



[lng-odp] [PATCH API-NEXT v4 1/1] linux-generic: queue: modular queue interface

2017-06-02 Thread Github ODP bot
From: Honnappa Nagarahalli 

Created abstract queue type. Queue APIs and functions towards the
internal components are converted into function pointers.

Signed-off-by: Honnappa Nagarahalli 
---
/** Email created from pull request 43 (nagarahalli:api-next-mod-queue1)
 ** https://github.com/Linaro/odp/pull/43
 ** Patch: https://github.com/Linaro/odp/pull/43.patch
 ** Base sha: 57783b35f4383bdfdd146f2abbc8bb995896
 ** Merge commit sha: d1f6ee1b79970b51c9675eac32faa2435256a8be
 **/
 platform/linux-generic/Makefile.am |   2 +
 .../include/odp_classification_datamodel.h |   5 +-
 .../linux-generic/include/odp_packet_io_queue.h|  21 +-
 platform/linux-generic/include/odp_queue_if.h  | 104 
 .../linux-generic/include/odp_queue_internal.h |  41 +---
 platform/linux-generic/include/odp_schedule_if.h   |   2 +-
 .../include/odp_traffic_mngr_internal.h|   4 +-
 platform/linux-generic/odp_classification.c|  10 +-
 platform/linux-generic/odp_init.c  |  17 +-
 platform/linux-generic/odp_packet_io.c |  90 ---
 platform/linux-generic/odp_queue.c | 261 +++--
 platform/linux-generic/odp_queue_if.c  | 103 
 platform/linux-generic/odp_schedule.c  |   6 +-
 platform/linux-generic/odp_schedule_iquery.c   |   6 +-
 platform/linux-generic/odp_schedule_sp.c   |   4 +-
 platform/linux-generic/odp_traffic_mngr.c  |  21 +-
 platform/linux-generic/pktio/loop.c|  13 +-
 17 files changed, 517 insertions(+), 193 deletions(-)
 create mode 100644 platform/linux-generic/include/odp_queue_if.h
 create mode 100644 platform/linux-generic/odp_queue_if.c

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 79f0e70c..58c73767 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -170,6 +170,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_posix_extensions.h \
  ${srcdir}/include/odp_queue_internal.h \
  ${srcdir}/include/odp_ring_internal.h \
+ ${srcdir}/include/odp_queue_if.h \
  ${srcdir}/include/odp_schedule_if.h \
  ${srcdir}/include/odp_sorted_list_internal.h \
  ${srcdir}/include/odp_shm_internal.h \
@@ -225,6 +226,7 @@ __LIB__libodp_linux_la_SOURCES = \
   odp_pkt_queue.c \
   odp_pool.c \
   odp_queue.c \
+  odp_queue_if.c \
   odp_rwlock.c \
   odp_rwlock_recursive.c \
   odp_schedule.c \
diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index 9df756bf..15768294 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -24,7 +24,8 @@ extern "C" {
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 /* Maximum Class Of Service Entry */
@@ -85,7 +86,7 @@ typedef struct pmr_term_value {
 Class Of Service
 */
 struct cos_s {
-   queue_entry_t *queue;   /* Associated Queue */
+   queue_t queue;  /* Associated Queue */
odp_pool_t pool;/* Associated Buffer pool */
union pmr_u *pmr[ODP_PMR_PER_COS_MAX];  /* Chained PMR */
union cos_u *linked_cos[ODP_PMR_PER_COS_MAX]; /* Chained CoS with PMR*/
diff --git a/platform/linux-generic/include/odp_packet_io_queue.h 
b/platform/linux-generic/include/odp_packet_io_queue.h
index d1d4b225..1995dc04 100644
--- a/platform/linux-generic/include/odp_packet_io_queue.h
+++ b/platform/linux-generic/include/odp_packet_io_queue.h
@@ -18,7 +18,8 @@
 extern "C" {
 #endif
 
-#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -28,20 +29,18 @@ extern "C" {
 ODP_STATIC_ASSERT(ODP_PKTIN_QUEUE_MAX_BURST >= QUEUE_MULTI_MAX,
  "ODP_PKTIN_DEQ_MULTI_MAX_ERROR");
 
-int pktin_enqueue(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr);
-odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *queue);
+int pktin_enqueue(queue_t queue, odp_buffer_hdr_t *buf_hdr);
+odp_buffer_hdr_t *pktin_dequeue(queue_t queue);
 
-int pktin_enq_multi(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr[], int 
num);
-int pktin_deq_multi(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr[], int 
num);
+int pktin_enq_multi(queue_t queue, odp_buffer_hdr_t *buf_hdr[], int num);
+int pktin_deq_multi(queue_t queue, odp_buffer_hdr_t *buf_hdr[], int num);
 
 
-int pktout_enqueue(queue_entry_t *queue, odp_buffer_hdr_t *buf_hdr);
-odp_buffer_hdr_t *pktout_dequeue(queue_entry_t *queue);
+int pktout_enqueue(queue_t queue, odp_buffer_hdr_t *buf_hdr);
+odp_buffer_hdr_t 

[lng-odp] [PATCH API-NEXT v4 0/1] Modular queue interface

2017-06-02 Thread Github ODP bot


github
/** Email created from pull request 43 (nagarahalli:api-next-mod-queue1)
 ** https://github.com/Linaro/odp/pull/43
 ** Patch: https://github.com/Linaro/odp/pull/43.patch
 ** Base sha: 57783b35f4383bdfdd146f2abbc8bb995896
 ** Merge commit sha: d1f6ee1b79970b51c9675eac32faa2435256a8be
 **/
/github

checkpatch.pl
WARNING: externs should be avoided in .c files
#1193: FILE: platform/linux-generic/odp_queue_if.c:9:
+extern const queue_api_t queue_default_api;

WARNING: externs should be avoided in .c files
#1194: FILE: platform/linux-generic/odp_queue_if.c:10:
+extern const queue_fn_t queue_default_fn;

total: 0 errors, 2 warnings, 0 checks, 1293 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.
/checkpatch.pl


[lng-odp] [Bug 3017] Travis: time main test out of boundaries

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3017

--- Comment #6 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/ee0168245dd03125158ae623a37499be7a2f3658
2017-06-02T21:55:46+03:00
Maxim Uvarov maxim.uva...@linaro.org
test: time: do not fail under gcov

code coverage gcov make test very slow and it does not pass
accepted boundaries. Test if env TEST=coverage variable is set
and do no generate fail result if some boundaries are missing.
https://bugs.linaro.org/show_bug.cgi?id=3017

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

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

Re: [lng-odp] Release needed

2017-06-02 Thread Maxim Uvarov
done, and also commit:

d4983d155f3172344dd55196b3918fc14b1c5d8b... abi: event: add
ODP_EVENT_IPSEC_STATUS

removed.

Maxim.


On 06/02/17 21:53, Bill Fischofer wrote:
> Maxim, should commit 033cd2a5c7c7dbc325d792c8e91389af7aa2eef0 be part
> of this release?
> 
> abi: event: add ODP_EVENT_IPSEC_RESULT
> 
> Update ABI spec with the new IPSEC event type.
> 
> Signed-off-by: Petri Savolainen 
> Signed-off-by: Dmitry Eremin-Solenikov 
> Reviewed-by: Dmitry Eremin-Solenikov 
> Signed-off-by: Maxim Uvarov 
> 
> This is part of IPsec which isn't ready for release yet.
> 
> On Fri, Jun 2, 2017 at 1:38 PM, Bill Fischofer
>  wrote:
>> On Fri, Jun 2, 2017 at 1:34 PM, Maxim Uvarov  wrote:
>>> everything is prepared and only changelog and tagging is needed.
>>>
>>> Bill can you take care about that? I tested this branch on my
>>> github/travis and it was ok. Results for main repo have to be updated by
>>> travis in few hours.
>>
>> Sure. I'll post a patch today.
>>
>>>
>>> Maxim.
>>>
>>> On 06/02/17 10:54, Savolainen, Petri (Nokia - FI/Espoo) wrote:

 As I mentioned yesterday:

 * ipsec.h is still in next branch, but should be removed from there. IPsec 
 API should not be released yet.

 * Crypto rework ([PATCH API-NEXT v5 00/23] Major cryptography code rework) 
 should be merged into api-next and from there to next branch, since it 
 fixes many crypto test and implementation issues, as well as updates 
 implementation to the current crypto API level.


 Otherwise, next branch seems OK.


 -Petri


> -Original Message-
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Friday, June 02, 2017 12:22 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bill Fischofer ; LNG ODP Mailman List  o...@lists.linaro.org>
> Subject: Re: Release needed
>
> Petri, next builds now. Will exclude patches you listed bellow and it
> will be ready. Please let me know if there any update.
>
> On 06/01/17 15:18, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> * partial packet.h
>>   * addition of odp_packet_data_range_t
>>   * keep in api-next: chksum_insert
>> * partial packet_io.h
>>   * addition of parse config
>>   * keep in api-next: ipsec config
>
> Thank you,
> Maxim.
>>>



[lng-odp] [Bug 3003] AES-GCM returns 'valid' tag when checking invalid tag

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3003

--- Comment #4 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/d44cc8192e4da1fabb4c1da7f543ee95c7c9c147
2017-06-02T21:55:45+03:00
Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org
linux: crypto: fix checking of GCM tags

Currently odp_crypto code will happily accept wrong tags, because the
check for EVP_DecryptFinal_ex return code is incorrect. This function
returns 0 if tag is incorrect, not < 0.
https://bugs.linaro.org/show_bug.cgi?id=3003

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

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

[lng-odp] [Linaro/odp] 395060: api: crypto: add sha-1 and sha-512 enumerations

2017-06-02 Thread GitHub
  Branch: refs/heads/next
  Home:   https://github.com/Linaro/odp
  Commit: 395060921f9307ad08fe5c914cca6fb17a999e70
  
https://github.com/Linaro/odp/commit/395060921f9307ad08fe5c914cca6fb17a999e70
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  api: crypto: add sha-1 and sha-512 enumerations

Added enumerations for HMAC-SHA-1 and HMAC-SHA-256 authentication
algorithms.

Signed-off-by: Petri Savolainen 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 


  Commit: ebdd9f9cae61bc36c129abc8fdb20208f58dec77
  
https://github.com/Linaro/odp/commit/ebdd9f9cae61bc36c129abc8fdb20208f58dec77
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-gen: crypto: sha-1 and sha-512 not implemented yet

Explicitly set capabilities to zero.

Signed-off-by: Petri Savolainen 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 


  Commit: aa25a995281abb09c75a9274e002e2c88e62e32c
  
https://github.com/Linaro/odp/commit/aa25a995281abb09c75a9274e002e2c88e62e32c
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M include/odp/api/spec/crypto.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  api: crypto: enforce deprecated API status

Used ODP_DEPRECATE() to control if deprecated API
definitions are visible in the API or not.

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


  Commit: 1e84f775b4b3e96fbcb216461421eb8866febe3b
  
https://github.com/Linaro/odp/commit/1e84f775b4b3e96fbcb216461421eb8866febe3b
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  api: crypto: add digest length session parameter

Authentication capabilities list supported digest lengths
per algorithm, but application did not have means to select which
length is used.

Signed-off-by: Petri Savolainen 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 


  Commit: 1403fb77fd6c6792aac97022668dee0b0ba7c603
  
https://github.com/Linaro/odp/commit/1403fb77fd6c6792aac97022668dee0b0ba7c603
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  api: crypto: add AAD operation parameters

Authentication capabilities list supported AAD lengths
per algorithm, but application did not have means to select which
length is used. Also pointer to AAD is added, since it may be
constructed also outside of packet data.

Signed-off-by: Petri Savolainen 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 


  Commit: ed5ea6b9b50a6046a0ae1babfb0e4d6ed7528e07
  
https://github.com/Linaro/odp/commit/ed5ea6b9b50a6046a0ae1babfb0e4d6ed7528e07
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M include/odp/api/spec/crypto.h
M include/odp/api/spec/packet.h
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h

  Log Message:
  ---
  api: packet: introduce odp_packet_data_range_t

Rename odp_crypto_data_range_t to odp_packet_data_range_t, as it is
relevant not only to the crypto interface.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: f54a2193c4f285f690f3b2883e2297cca2248400
  
https://github.com/Linaro/odp/commit/f54a2193c4f285f690f3b2883e2297cca2248400
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M configure.ac
M doc/application-api-guide/api_guide_lines.dox
M doc/platform-api-guide/Doxyfile
M doc/process-guide/release-guide.adoc
M include/odp/api/spec/.gitignore
A include/odp/api/spec/deprecated.h.in
M include/odp_api.h
M platform/Makefile.inc
M platform/linux-generic/Makefile.am
A 

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #28 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/f3dad75cc1328bce2127c15c9b1a36951094aed6
2017-06-02T21:55:45+03:00
Bill Fischofer bill.fischo...@linaro.org
linux-generic: types: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #29 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/c0b3f40ffef2f6c8a2a5f5838c30671d470905b0
2017-06-02T21:55:45+03:00
Bill Fischofer bill.fischo...@linaro.org
helper: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #26 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/5684a7150114f8bfeaab623837b26c810a868026
2017-06-02T21:55:45+03:00
Bill Fischofer bill.fischo...@linaro.org
api: pool: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #27 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/ab890b2d01bacc60ecbf6580d56e5d008552ec92
2017-06-02T21:55:45+03:00
Bill Fischofer bill.fischo...@linaro.org
api: tm: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

Re: [lng-odp] Release needed

2017-06-02 Thread Maxim Uvarov
On 06/02/17 21:53, Bill Fischofer wrote:
> Maxim, should commit 033cd2a5c7c7dbc325d792c8e91389af7aa2eef0 be part
> of this release?
> 

No, thanks for review, will remove it now.

Maxim.

> abi: event: add ODP_EVENT_IPSEC_RESULT
> 
> Update ABI spec with the new IPSEC event type.
> 
> Signed-off-by: Petri Savolainen 
> Signed-off-by: Dmitry Eremin-Solenikov 
> Reviewed-by: Dmitry Eremin-Solenikov 
> Signed-off-by: Maxim Uvarov 
> 
> This is part of IPsec which isn't ready for release yet.
> 
> On Fri, Jun 2, 2017 at 1:38 PM, Bill Fischofer
>  wrote:
>> On Fri, Jun 2, 2017 at 1:34 PM, Maxim Uvarov  wrote:
>>> everything is prepared and only changelog and tagging is needed.
>>>
>>> Bill can you take care about that? I tested this branch on my
>>> github/travis and it was ok. Results for main repo have to be updated by
>>> travis in few hours.
>>
>> Sure. I'll post a patch today.
>>
>>>
>>> Maxim.
>>>
>>> On 06/02/17 10:54, Savolainen, Petri (Nokia - FI/Espoo) wrote:

 As I mentioned yesterday:

 * ipsec.h is still in next branch, but should be removed from there. IPsec 
 API should not be released yet.

 * Crypto rework ([PATCH API-NEXT v5 00/23] Major cryptography code rework) 
 should be merged into api-next and from there to next branch, since it 
 fixes many crypto test and implementation issues, as well as updates 
 implementation to the current crypto API level.


 Otherwise, next branch seems OK.


 -Petri


> -Original Message-
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Friday, June 02, 2017 12:22 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bill Fischofer ; LNG ODP Mailman List  o...@lists.linaro.org>
> Subject: Re: Release needed
>
> Petri, next builds now. Will exclude patches you listed bellow and it
> will be ready. Please let me know if there any update.
>
> On 06/01/17 15:18, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> * partial packet.h
>>   * addition of odp_packet_data_range_t
>>   * keep in api-next: chksum_insert
>> * partial packet_io.h
>>   * addition of parse config
>>   * keep in api-next: ipsec config
>
> Thank you,
> Maxim.
>>>



Re: [lng-odp] Release needed

2017-06-02 Thread Bill Fischofer
Maxim, should commit 033cd2a5c7c7dbc325d792c8e91389af7aa2eef0 be part
of this release?

abi: event: add ODP_EVENT_IPSEC_RESULT

Update ABI spec with the new IPSEC event type.

Signed-off-by: Petri Savolainen 
Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Dmitry Eremin-Solenikov 
Signed-off-by: Maxim Uvarov 

This is part of IPsec which isn't ready for release yet.

On Fri, Jun 2, 2017 at 1:38 PM, Bill Fischofer
 wrote:
> On Fri, Jun 2, 2017 at 1:34 PM, Maxim Uvarov  wrote:
>> everything is prepared and only changelog and tagging is needed.
>>
>> Bill can you take care about that? I tested this branch on my
>> github/travis and it was ok. Results for main repo have to be updated by
>> travis in few hours.
>
> Sure. I'll post a patch today.
>
>>
>> Maxim.
>>
>> On 06/02/17 10:54, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>>
>>> As I mentioned yesterday:
>>>
>>> * ipsec.h is still in next branch, but should be removed from there. IPsec 
>>> API should not be released yet.
>>>
>>> * Crypto rework ([PATCH API-NEXT v5 00/23] Major cryptography code rework) 
>>> should be merged into api-next and from there to next branch, since it 
>>> fixes many crypto test and implementation issues, as well as updates 
>>> implementation to the current crypto API level.
>>>
>>>
>>> Otherwise, next branch seems OK.
>>>
>>>
>>> -Petri
>>>
>>>
 -Original Message-
 From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
 Sent: Friday, June 02, 2017 12:22 AM
 To: Savolainen, Petri (Nokia - FI/Espoo) 
 Cc: Bill Fischofer ; LNG ODP Mailman List >>> o...@lists.linaro.org>
 Subject: Re: Release needed

 Petri, next builds now. Will exclude patches you listed bellow and it
 will be ready. Please let me know if there any update.

 On 06/01/17 15:18, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> * partial packet.h
>   * addition of odp_packet_data_range_t
>   * keep in api-next: chksum_insert
> * partial packet_io.h
>   * addition of parse config
>   * keep in api-next: ipsec config

 Thank you,
 Maxim.
>>


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Bill Fischofer
On Fri, Jun 2, 2017 at 12:09 PM, Dmitry Eremin-Solenikov
 wrote:
> On 02.06.2017 18:34, Brian Brooks wrote:
>> On 06/02 10:39:18, Dmitry Eremin-Solenikov wrote:
>>> On 01.06.2017 22:05, Brian Brooks wrote:
 Signed-off-by: Brian Brooks 
 Reviewed-by: Ola Liljedahl 
 Reviewed-by: Honnappa Nagarahalli 
 ---
  configure.ac  | 5 +
  platform/linux-generic/m4/configure.m4| 4 
  platform/linux-generic/pktio/ipc.c| 6 --
  platform/linux-generic/pktio/sysfs.c  | 2 +-
  test/common_plat/validation/api/pktio/pktio.c | 4 +++-
  5 files changed, 17 insertions(+), 4 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 7569ebe0..5eabe4d4 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
 -Wold-style-definition -Wpointer-
  ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
 -Wformat-nonliteral"
  ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
  ODP_CFLAGS="$ODP_CFLAGS -std=c99"
 +
 +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
 +  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
 +fi
 +
>>>
>>> Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
>>> warning?
>>
>> Not every fallthrough is commented.
>>
>> Please read the manual if you would like to know more:
>> https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options
>
> So, it would be better to add necessary comments in my opinion.
> The warning is useful.
>
  # Extra flags for example to suppress certain warning types
  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"

 diff --git a/platform/linux-generic/m4/configure.m4 
 b/platform/linux-generic/m4/configure.m4
 index a2a25408..3e2978b5 100644
 --- a/platform/linux-generic/m4/configure.m4
 +++ b/platform/linux-generic/m4/configure.m4
 @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
  echo "Use newer version. For gcc > 4.7.0"
  exit -1)

 +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
 +  AM_LDFLAGS="$AM_LDFLAGS -latomic"
 +fi
 +
>>>
>>> This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS
>>
>> I don't think so. The link to libatomic is needed based on the compiler
>> version, not based on whether a program compiles with -latomic or not
>> which is AC_CHECK_LIB behavior. If you disagree, please show me how it
>> can be done.
>>
>> This is also a very simple (3 line) solution.
>
> Simple solution:
>
> AC_SEARCH_LIBS([your_atomic_func], [atomic])
>
> Cleaner solution:
>
> AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])], [ATOMIC_LIBS=""],
> [OLDLIBS=$LIBS
> LIBS="$LIBS -latomic"
> AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])],
> [ATOMIC_LIBS="-latomic"],
> [AC_MSG_FAILURE([your_atomic_func is not available])])
> LIBS=$OLDLIBS])
> AC_SUBST([ATOMIC_LIBS])
>
> Then you can use $(ATOMIC_LIBS) when you need to use your_atomic_function().
>
>
  m4_include([platform/linux-generic/m4/odp_pthread.m4])
  m4_include([platform/linux-generic/m4/odp_openssl.m4])
  m4_include([platform/linux-generic/m4/odp_pcap.m4])
 diff --git a/platform/linux-generic/pktio/ipc.c 
 b/platform/linux-generic/pktio/ipc.c
 index 06175e5a..29c3a546 100644
 --- a/platform/linux-generic/pktio/ipc.c
 +++ b/platform/linux-generic/pktio/ipc.c
 @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)

 if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
 snprintf(name, sizeof(name), "ipc:%s", tail);
 -   else
 -   snprintf(name, sizeof(name), "%s", dev);
 +   else {
 +   strncpy(name, dev, sizeof(name));
 +   name[sizeof(name) - 1] = '\0';
 +   }
>>>
>>> Why?
>>
>> New -Wformat-truncation=level behavior. Please read the manual if you'd like
>> to know more.
>
> I'd suggest instead to disable -Wformat-truncation.
>
> Related question: why do we have PKTIO_NAME_LEN of 256?

The reason for the length is the syntax supported by the pcap driver
(see pktio/pcap.c):

 * PCAP pktio type
 *
 * This file provides a pktio interface that allows for reading from
 * and writing to pcap capture files. It is intended to be used as
 * simple way of injecting test packets into an application for the
 * purpose of functional testing.
 *
 * To use this interface the name passed to odp_pktio_open() must begin
 * with "pcap:" and be in the format;
 *
 * pcap:in=test.pcap:out=test_out.pcap:loops=10

With file path names, this can easily grow "long" so 256 was picked as
a round number that should accommodate most "reasonable" pcap paths.

>

 /* unlink this pktio info for both master and slave */
 

Re: [lng-odp] Release needed

2017-06-02 Thread Bill Fischofer
On Fri, Jun 2, 2017 at 1:34 PM, Maxim Uvarov  wrote:
> everything is prepared and only changelog and tagging is needed.
>
> Bill can you take care about that? I tested this branch on my
> github/travis and it was ok. Results for main repo have to be updated by
> travis in few hours.

Sure. I'll post a patch today.

>
> Maxim.
>
> On 06/02/17 10:54, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>
>> As I mentioned yesterday:
>>
>> * ipsec.h is still in next branch, but should be removed from there. IPsec 
>> API should not be released yet.
>>
>> * Crypto rework ([PATCH API-NEXT v5 00/23] Major cryptography code rework) 
>> should be merged into api-next and from there to next branch, since it fixes 
>> many crypto test and implementation issues, as well as updates 
>> implementation to the current crypto API level.
>>
>>
>> Otherwise, next branch seems OK.
>>
>>
>> -Petri
>>
>>
>>> -Original Message-
>>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>>> Sent: Friday, June 02, 2017 12:22 AM
>>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>>> Cc: Bill Fischofer ; LNG ODP Mailman List >> o...@lists.linaro.org>
>>> Subject: Re: Release needed
>>>
>>> Petri, next builds now. Will exclude patches you listed bellow and it
>>> will be ready. Please let me know if there any update.
>>>
>>> On 06/01/17 15:18, Savolainen, Petri (Nokia - FI/Espoo) wrote:
 * partial packet.h
   * addition of odp_packet_data_range_t
   * keep in api-next: chksum_insert
 * partial packet_io.h
   * addition of parse config
   * keep in api-next: ipsec config
>>>
>>> Thank you,
>>> Maxim.
>


[lng-odp] [PATCH v2] Fixes for GCC 7

2017-06-02 Thread Brian Brooks
The GCC 7 series introduces changes that expose ODP compilation
issues. These include case statement fall through warnings, and
stricter checks on potential string overflows and other semantic
analysis.

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

Signed-off-by: Brian Brooks 
Reviewed-by: Ola Liljedahl 
Reviewed-by: Honnappa Nagarahalli 
---
 configure.ac  | 5 +
 platform/linux-generic/m4/configure.m4| 4 
 platform/linux-generic/pktio/ipc.c| 6 --
 platform/linux-generic/pktio/sysfs.c  | 2 +-
 test/common_plat/validation/api/pktio/pktio.c | 4 +++-
 5 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7569ebe0..5eabe4d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
-Wold-style-definition -Wpointer-
 ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
-Wformat-nonliteral"
 ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
 ODP_CFLAGS="$ODP_CFLAGS -std=c99"
+
+if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
+  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
+fi
+
 # Extra flags for example to suppress certain warning types
 ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
 
diff --git a/platform/linux-generic/m4/configure.m4 
b/platform/linux-generic/m4/configure.m4
index a2a25408..3e2978b5 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -28,6 +28,10 @@ AC_LINK_IFELSE(
 echo "Use newer version. For gcc > 4.7.0"
 exit -1)
 
+if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
+  AM_LDFLAGS="$AM_LDFLAGS -latomic"
+fi
+
 m4_include([platform/linux-generic/m4/odp_pthread.m4])
 m4_include([platform/linux-generic/m4/odp_openssl.m4])
 m4_include([platform/linux-generic/m4/odp_pcap.m4])
diff --git a/platform/linux-generic/pktio/ipc.c 
b/platform/linux-generic/pktio/ipc.c
index 06175e5a..29c3a546 100644
--- a/platform/linux-generic/pktio/ipc.c
+++ b/platform/linux-generic/pktio/ipc.c
@@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
 
if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
snprintf(name, sizeof(name), "ipc:%s", tail);
-   else
-   snprintf(name, sizeof(name), "%s", dev);
+   else {
+   strncpy(name, dev, sizeof(name));
+   name[sizeof(name) - 1] = '\0';
+   }
 
/* unlink this pktio info for both master and slave */
odp_shm_free(pktio_entry->s.ipc.pinfo_shm);
diff --git a/platform/linux-generic/pktio/sysfs.c 
b/platform/linux-generic/pktio/sysfs.c
index be0822dd..6e9bc59b 100644
--- a/platform/linux-generic/pktio/sysfs.c
+++ b/platform/linux-generic/pktio/sysfs.c
@@ -43,7 +43,7 @@ static int sysfs_get_val(const char *fname, uint64_t *val)
 int sysfs_stats(pktio_entry_t *pktio_entry,
odp_pktio_stats_t *stats)
 {
-   char fname[256];
+   char fname[300];
const char *dev = pktio_entry->s.name;
int ret = 0;
 
diff --git a/test/common_plat/validation/api/pktio/pktio.c 
b/test/common_plat/validation/api/pktio/pktio.c
index 11fe974f..4d8d2cc7 100644
--- a/test/common_plat/validation/api/pktio/pktio.c
+++ b/test/common_plat/validation/api/pktio/pktio.c
@@ -1429,7 +1429,9 @@ int pktio_check_statistics_counters(void)
 void pktio_test_statistics_counters(void)
 {
odp_pktio_t pktio_rx, pktio_tx;
-   odp_pktio_t pktio[MAX_NUM_IFACES];
+   odp_pktio_t pktio[MAX_NUM_IFACES] = {
+   ODP_PKTIO_INVALID, ODP_PKTIO_INVALID
+   };
odp_packet_t pkt;
odp_packet_t tx_pkt[1000];
uint32_t pkt_seq[1000];
-- 
2.13.0



Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Dmitry Eremin-Solenikov
On 02.06.2017 18:34, Brian Brooks wrote:
> On 06/02 10:39:18, Dmitry Eremin-Solenikov wrote:
>> On 01.06.2017 22:05, Brian Brooks wrote:
>>> Signed-off-by: Brian Brooks 
>>> Reviewed-by: Ola Liljedahl 
>>> Reviewed-by: Honnappa Nagarahalli 
>>> ---
>>>  configure.ac  | 5 +
>>>  platform/linux-generic/m4/configure.m4| 4 
>>>  platform/linux-generic/pktio/ipc.c| 6 --
>>>  platform/linux-generic/pktio/sysfs.c  | 2 +-
>>>  test/common_plat/validation/api/pktio/pktio.c | 4 +++-
>>>  5 files changed, 17 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 7569ebe0..5eabe4d4 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
>>> -Wold-style-definition -Wpointer-
>>>  ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
>>> -Wformat-nonliteral"
>>>  ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
>>>  ODP_CFLAGS="$ODP_CFLAGS -std=c99"
>>> +
>>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
>>> +  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
>>> +fi
>>> +
>>
>> Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
>> warning?
> 
> Not every fallthrough is commented.
> 
> Please read the manual if you would like to know more:
> https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options

So, it would be better to add necessary comments in my opinion.
The warning is useful.

>>>  # Extra flags for example to suppress certain warning types
>>>  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
>>>  
>>> diff --git a/platform/linux-generic/m4/configure.m4 
>>> b/platform/linux-generic/m4/configure.m4
>>> index a2a25408..3e2978b5 100644
>>> --- a/platform/linux-generic/m4/configure.m4
>>> +++ b/platform/linux-generic/m4/configure.m4
>>> @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
>>>  echo "Use newer version. For gcc > 4.7.0"
>>>  exit -1)
>>>  
>>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
>>> +  AM_LDFLAGS="$AM_LDFLAGS -latomic"
>>> +fi
>>> +
>>
>> This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS
> 
> I don't think so. The link to libatomic is needed based on the compiler
> version, not based on whether a program compiles with -latomic or not
> which is AC_CHECK_LIB behavior. If you disagree, please show me how it
> can be done.
> 
> This is also a very simple (3 line) solution.

Simple solution:

AC_SEARCH_LIBS([your_atomic_func], [atomic])

Cleaner solution:

AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])], [ATOMIC_LIBS=""],
[OLDLIBS=$LIBS
LIBS="$LIBS -latomic"
AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])],
[ATOMIC_LIBS="-latomic"],
[AC_MSG_FAILURE([your_atomic_func is not available])])
LIBS=$OLDLIBS])
AC_SUBST([ATOMIC_LIBS])

Then you can use $(ATOMIC_LIBS) when you need to use your_atomic_function().


>>>  m4_include([platform/linux-generic/m4/odp_pthread.m4])
>>>  m4_include([platform/linux-generic/m4/odp_openssl.m4])
>>>  m4_include([platform/linux-generic/m4/odp_pcap.m4])
>>> diff --git a/platform/linux-generic/pktio/ipc.c 
>>> b/platform/linux-generic/pktio/ipc.c
>>> index 06175e5a..29c3a546 100644
>>> --- a/platform/linux-generic/pktio/ipc.c
>>> +++ b/platform/linux-generic/pktio/ipc.c
>>> @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
>>>  
>>> if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
>>> snprintf(name, sizeof(name), "ipc:%s", tail);
>>> -   else
>>> -   snprintf(name, sizeof(name), "%s", dev);
>>> +   else {
>>> +   strncpy(name, dev, sizeof(name));
>>> +   name[sizeof(name) - 1] = '\0';
>>> +   }
>>
>> Why?
> 
> New -Wformat-truncation=level behavior. Please read the manual if you'd like
> to know more.

I'd suggest instead to disable -Wformat-truncation.

Related question: why do we have PKTIO_NAME_LEN of 256?

>>>  
>>> /* unlink this pktio info for both master and slave */
>>> odp_shm_free(pktio_entry->s.ipc.pinfo_shm);

-- 
With best wishes
Dmitry


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Bill Fischofer
On Fri, Jun 2, 2017 at 10:40 AM, Brian Brooks  wrote:
> On 06/01 22:30:16, Bill Fischofer wrote:
>> On Thu, Jun 1, 2017 at 9:48 PM, Brian Brooks  wrote:
>> > On 06/01 15:00:28, Bill Fischofer wrote:
>> >> If this is a bug fix it should reference a Bug that describes in more
>> >> detail what is being fixed.
>> >
>> > Can you elaborate?
>> >
>> > The subject line "Fixes for GCC 7" is sufficient.
>>
>> If this is fixing a bug the commit log should reference the bugzilla
>> entry associated with that bug.
>
> There is no bugzilla or jira. This is solving a minor problem that I have
> because I am using newer GCC release on ARM and x86.

What I normally do in such cases is simply open a Bug describing the
issue and then reference it in the corresponding patch. This allows us
to keep track of fixes as opposed to new APIs or capabilities, etc.
Very glad you found this and have a fix for it.

I've opened Bug https://bugs.linaro.org/show_bug.cgi?id=3027 for you
for this. Please reference this in the commit log. Thanks.


[lng-odp] [Bug 3027] New: Compilation failures using GCC 7 series

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3027

Bug ID: 3027
   Summary: Compilation failures using GCC 7 series
   Product: OpenDataPlane - linux- generic reference
   Version: v1.14.0.0
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: General ODP
  Assignee: brian.bro...@linaro.org
  Reporter: bill.fischo...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

The GCC 7 series introduces changes that expose ODP compilation issues. These
include case statement fall through warnings, and stricter checks on potential
string overflows.

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

Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Brian Brooks
On 06/01 22:30:16, Bill Fischofer wrote:
> On Thu, Jun 1, 2017 at 9:48 PM, Brian Brooks  wrote:
> > On 06/01 15:00:28, Bill Fischofer wrote:
> >> If this is a bug fix it should reference a Bug that describes in more
> >> detail what is being fixed.
> >
> > Can you elaborate?
> >
> > The subject line "Fixes for GCC 7" is sufficient.
> 
> If this is fixing a bug the commit log should reference the bugzilla
> entry associated with that bug.

There is no bugzilla or jira. This is solving a minor problem that I have
because I am using newer GCC release on ARM and x86.


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Brian Brooks
On 06/02 15:07:48, Maxim Uvarov wrote:
> I think this patch has to be spit on several patches. Having patch which
> correct unrelated things is strange and make it hard to merge/cherry-pick.

They are all related to things that break the build with GCC 7. It's
unnecessary and extra complexity to split it up into more than one patch.
The single patch is small and easily reviewable anyway.

> 
> Maxim.


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Brian Brooks
On 06/02 10:39:18, Dmitry Eremin-Solenikov wrote:
> On 01.06.2017 22:05, Brian Brooks wrote:
> > Signed-off-by: Brian Brooks 
> > Reviewed-by: Ola Liljedahl 
> > Reviewed-by: Honnappa Nagarahalli 
> > ---
> >  configure.ac  | 5 +
> >  platform/linux-generic/m4/configure.m4| 4 
> >  platform/linux-generic/pktio/ipc.c| 6 --
> >  platform/linux-generic/pktio/sysfs.c  | 2 +-
> >  test/common_plat/validation/api/pktio/pktio.c | 4 +++-
> >  5 files changed, 17 insertions(+), 4 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 7569ebe0..5eabe4d4 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
> > -Wold-style-definition -Wpointer-
> >  ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
> > -Wformat-nonliteral"
> >  ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
> >  ODP_CFLAGS="$ODP_CFLAGS -std=c99"
> > +
> > +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> > +  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
> > +fi
> > +
> 
> Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
> warning?

Not every fallthrough is commented.

Please read the manual if you would like to know more:
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options

> >  # Extra flags for example to suppress certain warning types
> >  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
> >  
> > diff --git a/platform/linux-generic/m4/configure.m4 
> > b/platform/linux-generic/m4/configure.m4
> > index a2a25408..3e2978b5 100644
> > --- a/platform/linux-generic/m4/configure.m4
> > +++ b/platform/linux-generic/m4/configure.m4
> > @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
> >  echo "Use newer version. For gcc > 4.7.0"
> >  exit -1)
> >  
> > +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> > +  AM_LDFLAGS="$AM_LDFLAGS -latomic"
> > +fi
> > +
> 
> This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS

I don't think so. The link to libatomic is needed based on the compiler
version, not based on whether a program compiles with -latomic or not
which is AC_CHECK_LIB behavior. If you disagree, please show me how it
can be done.

This is also a very simple (3 line) solution.

> >  m4_include([platform/linux-generic/m4/odp_pthread.m4])
> >  m4_include([platform/linux-generic/m4/odp_openssl.m4])
> >  m4_include([platform/linux-generic/m4/odp_pcap.m4])
> > diff --git a/platform/linux-generic/pktio/ipc.c 
> > b/platform/linux-generic/pktio/ipc.c
> > index 06175e5a..29c3a546 100644
> > --- a/platform/linux-generic/pktio/ipc.c
> > +++ b/platform/linux-generic/pktio/ipc.c
> > @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
> >  
> > if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
> > snprintf(name, sizeof(name), "ipc:%s", tail);
> > -   else
> > -   snprintf(name, sizeof(name), "%s", dev);
> > +   else {
> > +   strncpy(name, dev, sizeof(name));
> > +   name[sizeof(name) - 1] = '\0';
> > +   }
> 
> Why?

New -Wformat-truncation=level behavior. Please read the manual if you'd like
to know more.

> >  
> > /* unlink this pktio info for both master and slave */
> > odp_shm_free(pktio_entry->s.ipc.pinfo_shm);
> 
> 
> -- 
> With best wishes
> Dmitry


Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Honnappa Nagarahalli
On 2 June 2017 at 05:17, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Honnappa Nagarahalli
>> Sent: Thursday, June 01, 2017 11:30 PM
>> To: Ola Liljedahl 
>> Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
>> ; Elo, Matias (Nokia - FI/Espoo)
>> ; Kevin Wang ; nd 
>> Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
>>
>> On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
>> >
>> >
>> >
>> >
>> > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
>> >  wrote:
>> >
>> >>On 1 June 2017 at 15:09, Ola Liljedahl  wrote:
>> >>>
>> >>>
>> >>> On 01/06/2017, 21:03, "Bill Fischofer" 
>> >>>wrote:
>> >>>
>> On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
>>  wrote:
>> > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
>> >  wrote:
>> >>
>> >>> On 31 May 2017, at 23:53, Bill Fischofer
>> 
>> >>>wrote:
>> >>>
>> >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo)
>> >>>  wrote:
>> 
>> >>> What¹s the purpose of calling ord_enq_multi() here? To save
>> >>>(stash)
>> >>> packets if the thread is out-of-order?
>> >>> And when the thread is in-order, it is re-enqueueing the
>> packets
>> >>>which
>> >>> again will invoke pktout_enqueue/pktout_enq_multi but this
>> time
>> >>> ord_enq_multi() will not save the packets, instead they will
>> >>>actually be
>> >>> transmitted by odp_pktout_send()?
>> >>>
>> >>
>> >> Since transmitting packets may fail, out-of-order packets
>> cannot
>> >>be
>> >> stashed here.
>> > You mean that the TX queue of the pktio might be full so not all
>> >packets
>> > will actually be enqueued for transmission.
>> 
>>  Yep.
>> 
>> > This is an interesting case but is it a must to know how many
>> >packets are
>> > actually accepted? Packets can always be dropped without notice,
>> >the
>> > question is from which point this is acceptable. If packets
>> >enqueued onto
>> > a pktout (egress) queue are accepted, this means that they must
>> >also be
>> > put onto the driver TX queue (as done by odp_pktout_send)?
>> >
>> 
>>  Currently, the packet_io/queue APIs don't say anything about
>> packets
>> being
>>  possibly dropped after successfully calling odp_queue_enq() to a
>> pktout
>>  event queue. So to be consistent with standard odp_queue_enq()
>> operations I
>>  think it is better to return the number of events actually
>> accepted
>> to the TX queue.
>> 
>>  To have more leeway one option would be to modify the API
>> documentation to
>>  state that packets may still be dropped after a successful
>> odp_queue_enq() call
>>  before reaching the NIC. If the application would like to be sure
>> that the
>>  packets are actually sent, it should use odp_pktout_send()
>> instead.
>> >>>
>> >>> Ordered queues simply say that packets will be delivered to the
>> next
>> >>> queue in the pipeline in the order they originated from their
>> source
>> >>> queue. What happens after that depends on the attributes of the
>> >>>target
>> >>> queue. If the target queue is an exit point from the application,
>> >>>then
>> >>> this is outside of ODP's scope.
>> >>
>> >> My point was that with stashing the application has no way of
>> knowing
>> >>if an
>> >> ordered pktout enqueue call actually succeed. In case of parallel
>> and
>> >>atomic
>> >> queues it does. So my question is, is this acceptable?
>> >>
>> > Also, currently, it is not possible for the application to have a
>> > consistent 'wait/drop on destination queue full' policy for all the
>> > queue types.
>> 
>> Today applications have no way of knowing whether packets sent to a
>> pktout_queue or tm_queue actually make it to the wire or whether they
>> are vaporized as soon as they hit the wire, so there's no change here.
>> An RC of 0 simply says that the packet was "accepted" for transmission
>> and hence the caller no longer owns that packet handle. You need
>> higher-level protocols to track end-to-end transmission and receipt.
>> All that ordered queues say is that packets being sent to TX queues
>> will have those TX calls made in 

[lng-odp] [PATCH v1 8/9] linux-gen: stop poisoning CPPFLAGS with Netmap flags

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Instead of poisoning global AM_CPPFLAGS with Netmap flags,
use fine-grained controls for compiling with Netmap.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 configure.ac| 1 -
 platform/linux-generic/Makefile.am  | 1 +
 platform/linux-generic/m4/odp_netmap.m4 | 7 +--
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5bf33270..3509a6df 100644
--- a/configure.ac
+++ b/configure.ac
@@ -208,7 +208,6 @@ AC_SUBST([testdir])
 ##
 # Set conditionals as computed within platform specific files
 ##
-AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
 AM_CONDITIONAL([SDK_INSTALL_PATH_], [test "x${SDK_INSTALL_PATH_}" = "x1"])
 AM_CONDITIONAL([test_installdir], [test "$testdir" != ""])
 AM_CONDITIONAL([cunit_support], [test x$cunit_support = xyes ])
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 067b5e07..893bce71 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -13,6 +13,7 @@ AM_CFLAGS +=  -D_ODP_PKTIO_IPC
 
 AM_CPPFLAGS +=  $(OPENSSL_CPPFLAGS)
 AM_CPPFLAGS +=  $(DPDK_CPPFLAGS)
+AM_CPPFLAGS +=  $(NETMAP_CPPFLAGS)
 
 include_HEADERS = \
  $(top_srcdir)/include/odp.h \
diff --git a/platform/linux-generic/m4/odp_netmap.m4 
b/platform/linux-generic/m4/odp_netmap.m4
index 880e9d58..dea80626 100644
--- a/platform/linux-generic/m4/odp_netmap.m4
+++ b/platform/linux-generic/m4/odp_netmap.m4
@@ -15,14 +15,14 @@ AC_ARG_WITH([netmap-path],
 AC_HELP_STRING([--with-netmap-path=DIR   path to netmap root directory],
[(or in the default path if not specified).]),
 [NETMAP_PATH=$withval
-AM_CPPFLAGS="$AM_CPPFLAGS -isystem $NETMAP_PATH/sys"
+NETMAP_CPPFLAGS="-isystem $NETMAP_PATH/sys"
 netmap_support=yes],[])
 
 ##
 # Save and set temporary compilation flags
 ##
 OLD_CPPFLAGS=$CPPFLAGS
-CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+CPPFLAGS="$NETMAP_CPPFLAGS $CPPFLAGS"
 
 ##
 # Check for netmap availability
@@ -32,6 +32,7 @@ then
 AC_CHECK_HEADERS([net/netmap_user.h], [],
 [AC_MSG_FAILURE(["can't find netmap header"])])
 ODP_CFLAGS="$ODP_CFLAGS -DODP_NETMAP"
+AC_SUBST([NETMAP_CPPFLAGS])
 else
 netmap_support=no
 fi
@@ -40,3 +41,5 @@ fi
 # Restore old saved variables
 ##
 CPPFLAGS=$OLD_CPPFLAGS
+
+AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])



[lng-odp] [PATCH v1 6/9] linux-gen: stop poisoning CFLAGS/LDFLAGS with threading flags

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Instead of poisoning global AM_CFLAGS/AM_LDFLAGS with threading flags,
use fine-grained controls for compiling/linking with threading.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 platform/Makefile.inc| 2 ++
 platform/linux-generic/Makefile.am   | 1 +
 platform/linux-generic/m4/odp_pthread.m4 | 5 -
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 7059d910..82bd750f 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -16,6 +16,8 @@ AM_CFLAGS += $(VISIBILITY_CFLAGS)
 #The implementation will need to retain the deprecated implementation
 AM_CFLAGS += -Wno-deprecated-declarations
 
+AM_CFLAGS += @PTHREAD_CFLAGS@
+
 odpapispecincludedir= $(includedir)/odp/api/spec
 odpapispecinclude_HEADERS = \
  $(top_srcdir)/include/odp/api/spec/align.h \
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 14fdf35e..616045bc 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -224,6 +224,7 @@ __LIB__libodp_linux_la_SOURCES = \
 
 __LIB__libodp_linux_la_LIBADD = $(OPENSSL_LIBS)
 __LIB__libodp_linux_la_LIBADD += $(DPDK_LIBS) $(DPDK_PMDS)
+__LIB__libodp_linux_la_LIBADD += $(PTHREAD_LIBS)
 
 if HAVE_PCAP
 __LIB__libodp_linux_la_SOURCES += pktio/pcap.c
diff --git a/platform/linux-generic/m4/odp_pthread.m4 
b/platform/linux-generic/m4/odp_pthread.m4
index 7f391039..48615894 100644
--- a/platform/linux-generic/m4/odp_pthread.m4
+++ b/platform/linux-generic/m4/odp_pthread.m4
@@ -6,8 +6,3 @@ AX_PTHREAD([CC="$PTHREAD_CC"], [
 echo "Error! We require pthreads to be available"
 exit -1
 ])
-LIBS="$PTHREAD_LIBS $LIBS"
-AM_CFLAGS="$AM_CFLAGS $PTHREAD_CFLAGS"
-AM_LDFLAGS="$AM_LDFLAGS $PTHREAD_LDFLAGS"
-
-AM_LDFLAGS="$AM_LDFLAGS -pthread -lrt"



[lng-odp] [PATCH v1 5/9] linux-gen: stop poisoning CPPFLAGS/LDFLAGS with CUnit flags

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Instead of poisoning global AM_CPPFLAGS/AM_LDFLAGS with CUnit flags,
use fine-grained controls for compiling/linking with CUnit.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 test/common_plat/common/Makefile.am  |  1 +
 test/common_plat/m4/validation.m4| 19 +++
 test/common_plat/validation/api/Makefile.inc |  2 ++
 test/linux-generic/Makefile.inc  |  2 ++
 4 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/test/common_plat/common/Makefile.am 
b/test/common_plat/common/Makefile.am
index fd41fb42..7d88d2ea 100644
--- a/test/common_plat/common/Makefile.am
+++ b/test/common_plat/common/Makefile.am
@@ -4,6 +4,7 @@ include $(top_srcdir)/test/Makefile.inc
 noinst_LTLIBRARIES = libcunit_common.la libcpumask_common.la 
libthrmask_common.la
 
 libcunit_common_la_SOURCES = odp_cunit_common.c
+libcunit_common_la_LIBADD = $(CUNIT_LIBS)
 
 libcpumask_common_la_SOURCES = mask_common.c
 
diff --git a/test/common_plat/m4/validation.m4 
b/test/common_plat/m4/validation.m4
index d32f675a..67edac7a 100644
--- a/test/common_plat/m4/validation.m4
+++ b/test/common_plat/m4/validation.m4
@@ -26,24 +26,24 @@ AC_ARG_WITH([cunit-path],
 AC_HELP_STRING([--with-cunit-path=DIR   path to CUnit libs and headers],
[(or in the default path if not specified).]),
 [CUNIT_PATH=$withval
-AM_CPPFLAGS="$AM_CPPFLAGS -I$CUNIT_PATH/include"
-AM_LDFLAGS="$AM_LDFLAGS -L$CUNIT_PATH/lib"
-cunit_support=yes],[])
+ CUNIT_CPPFLAGS="-I$CUNIT_PATH/include"
+ CUNIT_LIBS="-L$CUNIT_PATH/lib"
+ cunit_support=yes],[])
 
 ##
 # Save and set temporary compilation flags
 ##
-OLD_LDFLAGS=$LDFLAGS
+OLD_LIBS=$LIBS
 OLD_CPPFLAGS=$CPPFLAGS
-LDFLAGS="$AM_LDFLAGS $LDFLAGS"
-CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+LIBS="$CUNIT_LIBS $LIBS"
+CPPFLAGS="$CUNIT_CPPFLAGS $CPPFLAGS"
 
 ##
 # Check for CUnit availability
 ##
 if test x$cunit_support = xyes
 then
-AC_CHECK_LIB([cunit],[CU_get_error], [],
+AC_CHECK_LIB([cunit],[CU_get_error], [CUNIT_LIBS="$CUNIT_LIBS -lcunit"],
 [AC_MSG_ERROR([CUnit libraries required])])
 AC_CHECK_HEADERS([CUnit/Basic.h], [],
 [AC_MSG_FAILURE(["can't find cunit headers"])])
@@ -51,8 +51,11 @@ else
 cunit_support=no
 fi
 
+AC_SUBST([CUNIT_CPPFLAGS])
+AC_SUBST([CUNIT_LIBS])
+
 ##
 # Restore old saved variables
 ##
-LDFLAGS=$OLD_LDFLAGS
+LIBS=$OLD_LIBS
 CPPFLAGS=$OLD_CPPFLAGS
diff --git a/test/common_plat/validation/api/Makefile.inc 
b/test/common_plat/validation/api/Makefile.inc
index 6069ee6b..177d2ac3 100644
--- a/test/common_plat/validation/api/Makefile.inc
+++ b/test/common_plat/validation/api/Makefile.inc
@@ -11,6 +11,8 @@ AM_CFLAGS += -I$(top_srcdir)/test/common_plat/common
 AM_LDFLAGS += -static
 AM_LDFLAGS += $(DPDK_PMDS)
 
+AM_CPPFLAGS += $(CUNIT_CPPFLAGS)
+
 LIBCUNIT_COMMON = $(COMMON_DIR)/libcunit_common.la
 LIBCPUMASK_COMMON = $(COMMON_DIR)/libcpumask_common.la
 LIBTHRMASK_COMMON = $(COMMON_DIR)/libthrmask_common.la
diff --git a/test/linux-generic/Makefile.inc b/test/linux-generic/Makefile.inc
index 6e165d8d..30b56e26 100644
--- a/test/linux-generic/Makefile.inc
+++ b/test/linux-generic/Makefile.inc
@@ -4,6 +4,8 @@
 
 AM_LDFLAGS += -static
 
+AM_CPPFLAGS += $(CUNIT_CPPFLAGS)
+
 LIBCUNIT_COMMON = $(top_builddir)/test/common_plat/common/libcunit_common.la
 LIB   = $(top_builddir)/lib
 LIBODP = $(LIB)/libodphelper.la $(LIB)/libodp-linux.la $(DPDK_PMDS)



[lng-odp] [PATCH v1 7/9] linux-gen: move timer_create check to platform directory

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 configure.ac   | 2 --
 pkgconfig/libodp-linux.pc.in   | 2 +-
 platform/linux-generic/Makefile.am | 1 +
 platform/linux-generic/m4/configure.m4 | 1 +
 platform/linux-generic/m4/odp_timer.m4 | 8 
 5 files changed, 11 insertions(+), 3 deletions(-)
 create mode 100644 platform/linux-generic/m4/odp_timer.m4

diff --git a/configure.ac b/configure.ac
index d0766f6c..5bf33270 100644
--- a/configure.ac
+++ b/configure.ac
@@ -332,8 +332,6 @@ AC_CONFIG_FILES([Makefile
 pkgconfig/libodphelper.pc
 ])
 
-AC_SEARCH_LIBS([timer_create],[rt posix4])
-
 ##
 # distribute the changed variables among the Makefiles
 
diff --git a/pkgconfig/libodp-linux.pc.in b/pkgconfig/libodp-linux.pc.in
index 172e8d09..fb749dad 100644
--- a/pkgconfig/libodp-linux.pc.in
+++ b/pkgconfig/libodp-linux.pc.in
@@ -7,5 +7,5 @@ Name: libodp-linux
 Description: The ODP packet processing engine
 Version: @PKGCONFIG_VERSION@
 Libs: -L${libdir} -lodp-linux @DPDK_LIBS@
-Libs.private: @OPENSSL_STATIC_LIBS@ @DPDK_PMDS@ @DPDK_LIBS@ @PCAP_LIBS@ 
@PTHREAD_LIBS@ -lrt -lpthread
+Libs.private: @OPENSSL_STATIC_LIBS@ @DPDK_PMDS@ @DPDK_LIBS@ @PCAP_LIBS@ 
@PTHREAD_LIBS@ @TIMER_LIBS@ -lpthread
 Cflags: -I${includedir}
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 616045bc..067b5e07 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -225,6 +225,7 @@ __LIB__libodp_linux_la_SOURCES = \
 __LIB__libodp_linux_la_LIBADD = $(OPENSSL_LIBS)
 __LIB__libodp_linux_la_LIBADD += $(DPDK_LIBS) $(DPDK_PMDS)
 __LIB__libodp_linux_la_LIBADD += $(PTHREAD_LIBS)
+__LIB__libodp_linux_la_LIBADD += $(TIMER_LIBS)
 
 if HAVE_PCAP
 __LIB__libodp_linux_la_SOURCES += pktio/pcap.c
diff --git a/platform/linux-generic/m4/configure.m4 
b/platform/linux-generic/m4/configure.m4
index a2a25408..c6d79b8c 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -29,6 +29,7 @@ AC_LINK_IFELSE(
 exit -1)
 
 m4_include([platform/linux-generic/m4/odp_pthread.m4])
+m4_include([platform/linux-generic/m4/odp_timer.m4])
 m4_include([platform/linux-generic/m4/odp_openssl.m4])
 m4_include([platform/linux-generic/m4/odp_pcap.m4])
 m4_include([platform/linux-generic/m4/odp_netmap.m4])
diff --git a/platform/linux-generic/m4/odp_timer.m4 
b/platform/linux-generic/m4/odp_timer.m4
new file mode 100644
index ..3122c92b
--- /dev/null
+++ b/platform/linux-generic/m4/odp_timer.m4
@@ -0,0 +1,8 @@
+##
+# Check for POSIX timer functions
+##
+
+AC_CHECK_LIB([rt], [timer_create], [TIMER_LIBS="-lrt"],
+[AC_CHECK_LIB([posix4], [timer_create], [TIMER_LIBS="-lposix4"],
+  [AC_MSG_FAILURE([timer_create not found])])])
+AC_SUBST([TIMER_LIBS])



[lng-odp] [PATCH v1 2/9] linux-gen: stop poisoning CPPFLAGS/LDFLAGS with OpenSSL flags

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Instead of poisoning global AM_CPPFLAGS/AM_LDFLAGS with OpenSSL flags,
use fine-grained controls for compiling/linking with OpenSSL.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 pkgconfig/libodp-linux.pc.in |  2 +-
 platform/linux-generic/Makefile.am   |  4 
 platform/linux-generic/m4/odp_openssl.m4 | 17 +++--
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/pkgconfig/libodp-linux.pc.in b/pkgconfig/libodp-linux.pc.in
index bf339fe8..ba36bafa 100644
--- a/pkgconfig/libodp-linux.pc.in
+++ b/pkgconfig/libodp-linux.pc.in
@@ -7,5 +7,5 @@ Name: libodp-linux
 Description: The ODP packet processing engine
 Version: @PKGCONFIG_VERSION@
 Libs: -L${libdir} -lodp-linux
-Libs.private: -lcrypto -ldl -lpcap @PTHREAD_LIBS@ -lrt -lpthread
+Libs.private: @OPENSSL_STATIC_LIBS@ -lpcap @PTHREAD_LIBS@ -lrt -lpthread
 Cflags: -I${includedir}
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 69fdf8b9..0eb31c04 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -11,6 +11,8 @@ AM_CFLAGS +=  -I$(top_builddir)/include
 AM_CFLAGS +=  -Iinclude
 AM_CFLAGS +=  -D_ODP_PKTIO_IPC
 
+AM_CPPFLAGS +=  $(OPENSSL_CPPFLAGS)
+
 include_HEADERS = \
  $(top_srcdir)/include/odp.h \
  $(top_srcdir)/include/odp_api.h
@@ -219,6 +221,8 @@ __LIB__libodp_linux_la_SOURCES = \
   arch/@ARCH_DIR@/odp_cpu_arch.c \
   arch/@ARCH_DIR@/odp_sysinfo_parse.c
 
+__LIB__libodp_linux_la_LIBADD = $(OPENSSL_LIBS)
+
 if HAVE_PCAP
 __LIB__libodp_linux_la_SOURCES += pktio/pcap.c
 endif
diff --git a/platform/linux-generic/m4/odp_openssl.m4 
b/platform/linux-generic/m4/odp_openssl.m4
index 2344914b..1d520077 100644
--- a/platform/linux-generic/m4/odp_openssl.m4
+++ b/platform/linux-generic/m4/odp_openssl.m4
@@ -5,8 +5,8 @@ AC_ARG_WITH([openssl-path],
 AC_HELP_STRING([--with-openssl-path=DIR path to openssl libs and headers],
[(or in the default path if not specified).]),
 [OPENSSL_PATH=$withval
-AM_CPPFLAGS="$AM_CPPFLAGS -I$OPENSSL_PATH/include"
-AM_LDFLAGS="$AM_LDFLAGS -L$OPENSSL_PATH/lib"
+OPENSSL_CPPFLAGS="-I$OPENSSL_PATH/include"
+OPENSSL_LIBS="-L$OPENSSL_PATH/lib"
 ],[])
 
 ##
@@ -14,19 +14,24 @@ AC_HELP_STRING([--with-openssl-path=DIR path to openssl 
libs and headers],
 ##
 OLD_LDFLAGS=$LDFLAGS
 OLD_CPPFLAGS=$CPPFLAGS
-LDFLAGS="$AM_LDFLAGS $LDFLAGS"
-CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+LIBS="$OPENSSL_LIBS $LIBS"
+CPPFLAGS="$OPENSSL_CPPFLAGS $CPPFLAGS"
 
 ##
 # Check for OpenSSL availability
 ##
-AC_CHECK_LIB([crypto], [EVP_EncryptInit], [],
+AC_CHECK_LIB([crypto], [EVP_EncryptInit], [OPENSSL_LIBS="$OPENSSL_LIBS 
-lcrypto"
+  OPENSSL_STATIC_LIBS="$OPENSSL_LIBS 
-ldl"],
  [AC_MSG_FAILURE([OpenSSL libraries required])])
 AC_CHECK_HEADERS([openssl/des.h openssl/rand.h openssl/hmac.h openssl/evp.h], 
[],
  [AC_MSG_ERROR([OpenSSL headers required])])
 
+AC_SUBST([OPENSSL_CPPFLAGS])
+AC_SUBST([OPENSSL_LIBS])
+AC_SUBST([OPENSSL_STATIC_LIBS])
+
 ##
 # Restore old saved variables
 ##
-LDFLAGS=$OLD_LDFLAGS
+LIBS=$OLD_LIBS
 CPPFLAGS=$OLD_CPPFLAGS



[lng-odp] [PATCH v1 1/9] pkgconfig: provide minimal proper static linking flags

2017-06-02 Thread Github ODP bot
From: Dmitry Eremin-Solenikov 

Provide Libs.private for static linking with ODP in minimal case (no
DPDK, no netmap).

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
 pkgconfig/libodp-linux.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pkgconfig/libodp-linux.pc.in b/pkgconfig/libodp-linux.pc.in
index 0769b214..bf339fe8 100644
--- a/pkgconfig/libodp-linux.pc.in
+++ b/pkgconfig/libodp-linux.pc.in
@@ -7,5 +7,5 @@ Name: libodp-linux
 Description: The ODP packet processing engine
 Version: @PKGCONFIG_VERSION@
 Libs: -L${libdir} -lodp-linux
-Libs.private:
+Libs.private: -lcrypto -ldl -lpcap @PTHREAD_LIBS@ -lrt -lpthread
 Cflags: -I${includedir}



[lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries

2017-06-02 Thread Github ODP bot
Currently configure tests add all libraries to AM_LDFLAGS or LIBS, thus making 
all libraries link against everything. For example libodp-linux ends up 
depending on libcunit. Implement fine-grained control of what gets linked 
against which libraries. As a side effect, this allows us to introduce proper 
linking flags to libod-linux.pc, enabling other users to use it properly.

github
/** Email created from pull request 45 (lumag:m4)
 ** https://github.com/Linaro/odp/pull/45
 ** Patch: https://github.com/Linaro/odp/pull/45.patch
 ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847
 ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db
 **/
/github

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


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


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


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


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


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


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


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


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


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


[lng-odp] [Bug 3017] Travis: time main test out of boundaries

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3017

--- Comment #5 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/5056151ea74434572609808b546ab0363b900866
2017-06-02T15:41:43+03:00
Maxim Uvarov maxim.uva...@linaro.org
test: time: do not fail under gcov

code coverage gcov make test very slow and it does not pass
accepted boundaries. Test if env TEST=coverage variable is set
and do no generate fail result if some boundaries are missing.
https://bugs.linaro.org/show_bug.cgi?id=3017

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

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

[lng-odp] [Bug 3003] AES-GCM returns 'valid' tag when checking invalid tag

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3003

--- Comment #3 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/5dee060187c2dbda51a18e28b3691bfc50bd1882
2017-06-02T15:41:43+03:00
Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org
linux: crypto: fix checking of GCM tags

Currently odp_crypto code will happily accept wrong tags, because the
check for EVP_DecryptFinal_ex return code is incorrect. This function
returns 0 if tag is incorrect, not < 0.
https://bugs.linaro.org/show_bug.cgi?id=3003

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #25 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/476b52c41e17940c39368a7bd81149e2780303ac
2017-06-02T15:41:42+03:00
Bill Fischofer bill.fischo...@linaro.org
helper: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #24 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/e167796e4bcb8c3f19737acb5358b5edabcdfa56
2017-06-02T15:41:42+03:00
Bill Fischofer bill.fischo...@linaro.org
linux-generic: types: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #23 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/88e3d6b326a4c84f1b5a1e4c099a3a2519efb1f2
2017-06-02T15:41:42+03:00
Bill Fischofer bill.fischo...@linaro.org
api: tm: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Linaro/odp] 705ed6: api: pktio: add parser configuration

2017-06-02 Thread GitHub
  Branch: refs/heads/next
  Home:   https://github.com/Linaro/odp
  Commit: 705ed6cbd52911ccc439dd43230ac4cf6aee4d5f
  
https://github.com/Linaro/odp/commit/705ed6cbd52911ccc439dd43230ac4cf6aee4d5f
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  api: pktio: add parser configuration

Packet input parsing level configuration is added. An application
may express the maximum layer it is interested about.
Implementations may optimize packet input performance as parsing
can be stopped on the application required level. Implementations
are free to parse more layers than application requests.

Lazy parsing (e.g. in current odp-linux) does not work in practice.
The implementation cannot continue parsing after the application
has got access to packet data, since application may overwrite
some packet headers. Parse results must reflect the format of the
received packet.

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


  Commit: d305e9182802c0522c759ec80b55404ada8ac627
  
https://github.com/Linaro/odp/commit/d305e9182802c0522c759ec80b55404ada8ac627
  Author: Petri Savolainen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/odp_packet_io.c
M test/common_plat/validation/api/pktio/pktio.c

  Log Message:
  ---
  linux-gen: pktio: parser default config

Fill default parser configuration and capability. All pktios
use same parser code, so the capability is the same (all layers).

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


  Commit: fe831783bda53ec4f883cb7f42e585cf37d282db
  
https://github.com/Linaro/odp/commit/fe831783bda53ec4f883cb7f42e585cf37d282db
  Author: Matias Elo 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M example/generator/odp_generator.c
M example/ipsec/odp_ipsec_stream.c
M helper/include/odp/helper/ip.h
M platform/linux-generic/include/protocols/ip.h
M platform/linux-generic/odp_packet.c

  Log Message:
  ---
  linux-gen: packet: recognize ICMPv6 packets

Signed-off-by: Matias Elo 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 41fd88bcac110322424f1418c751707f9b40409c
  
https://github.com/Linaro/odp/commit/41fd88bcac110322424f1418c751707f9b40409c
  Author: Matias Elo 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M example/l2fwd_simple/odp_l2fwd_simple.c
M example/l3fwd/odp_l3fwd.c
M example/switch/odp_switch.c
M test/common_plat/performance/odp_l2fwd.c
M test/common_plat/performance/odp_pktio_ordered.c

  Log Message:
  ---
  examples: use odp_pktio_config() to select required packet parsing level

Select required packet parsing level when full packet parsing is not
required.

Signed-off-by: Matias Elo 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: b40c6127cb52c6d33719f9ff923b6b8ee7f38f21
  
https://github.com/Linaro/odp/commit/b40c6127cb52c6d33719f9ff923b6b8ee7f38f21
  Author: Matias Elo 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/pktio/Makefile.am
A test/common_plat/validation/api/pktio/parser.c
A test/common_plat/validation/api/pktio/parser.h
M test/common_plat/validation/api/pktio/pktio.c
M test/common_plat/validation/api/pktio/pktio.h

  Log Message:
  ---
  validation: pktio: add tests for packet parsing

Test packet parsing using predefined test packets (byte arrays). Test
packets are looped through tested pktio interfaces to force packet parsing.

Signed-off-by: Matias Elo 
Reviewed-and-tested-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: d4983d155f3172344dd55196b3918fc14b1c5d8b
  
https://github.com/Linaro/odp/commit/d4983d155f3172344dd55196b3918fc14b1c5d8b
  Author: Janne Peltonen 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M include/odp/arch/default/api/abi/event.h

  Log Message:
  ---
  abi: event: add ODP_EVENT_IPSEC_STATUS

Update ABI spec with the new IPsec event type.

Signed-off-by: Janne Peltonen 
Reviewed-by: Bill Fischofer 
Signed-off-by: Maxim Uvarov 


  Commit: 91b26ee0ef846979b8a2bfdfb44076a497611d5a
  

[lng-odp] [Bug 2952] doxygen errors and travis does not catch them

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=2952

--- Comment #22 from Maxim Uvarov  ---
https://github.com/Linaro/odp/commit/83031014c51be27b9b64cf5fda10efc7fa1d3ed1
2017-06-02T15:41:42+03:00
Bill Fischofer bill.fischo...@linaro.org
api: pool: add additional doxygen documentation

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding
additional field documentation to avoid problems with doxygen 1.8.13
and higher.

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

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

[lng-odp] [Linaro/odp] 562059: validation: crypto: explicitly pass auth_digest_le...

2017-06-02 Thread GitHub
  Branch: refs/heads/next
  Home:   https://github.com/Linaro/odp
  Commit: 562059f5d7841f30eab228ac218a46d1c3110010
  
https://github.com/Linaro/odp/commit/562059f5d7841f30eab228ac218a46d1c3110010
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h
M test/common_plat/validation/api/crypto/test_vectors_len.h

  Log Message:
  ---
  validation: crypto: explicitly pass auth_digest_len to crypto subsystem

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 60b2c5a0bb2595f7ef5ca3bbc59097674a28ae1d
  
https://github.com/Linaro/odp/commit/60b2c5a0bb2595f7ef5ca3bbc59097674a28ae1d
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h

  Log Message:
  ---
  validation: crypto: explicitly pass AAD to crypto subsystem

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 196521caf9adb8eea4e0b2c79d6aa2f3240c3944
  
https://github.com/Linaro/odp/commit/196521caf9adb8eea4e0b2c79d6aa2f3240c3944
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/performance/odp_crypto.c

  Log Message:
  ---
  test: odp_crypto: update performance test to set auth_digest_length

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 0ee8b0ec8668734a43b57b3d76f37a1bdddf03fb
  
https://github.com/Linaro/odp/commit/0ee8b0ec8668734a43b57b3d76f37a1bdddf03fb
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M example/ipsec/odp_ipsec_cache.c

  Log Message:
  ---
  example: ipsec: set auth_digest_len

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 798182b6930bc70fb759516dd8a3964bcf1812a8
  
https://github.com/Linaro/odp/commit/798182b6930bc70fb759516dd8a3964bcf1812a8
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: use auth_digest_len when calculating HMACs

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: f0968cf3a4281cd45f7c490e1cfc84f93d2a37b6
  
https://github.com/Linaro/odp/commit/f0968cf3a4281cd45f7c490e1cfc84f93d2a37b6
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: add SHA* capabilities for full length digests

In addition to truncated digests (used by IPsec) add full-length
capabilities to SHA* algos.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: aeb33071432c5d4d3c83f4556199fabdbc540164
  
https://github.com/Linaro/odp/commit/aeb33071432c5d4d3c83f4556199fabdbc540164
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: update AES-GCM support to reflect aad and 
auth_digest_len

Make AES-GCM use recently introduced aad and auth_digest_len fields.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 


  Commit: 30bf39b9afb2ee5703bac4227effc5808bb337d7
  
https://github.com/Linaro/odp/commit/30bf39b9afb2ee5703bac4227effc5808bb337d7
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: remote 

Re: [lng-odp] [API-NEXT PATCH] api: system_info: add function for fetching all supported huge page sizes

2017-06-02 Thread Maxim Uvarov
On 06/02/17 12:44, Elo, Matias (Nokia - FI/Espoo) wrote:
>>>
>>> /**
>>> + * System huge page sizes in bytes
>>> + *
>>> + * Returns the number of huge page sizes supported by the system. Outputs 
>>> up to
>>> + * 'num' sizes when the 'size' array pointer is not NULL. If return value 
>>> is
>>> + * larger than 'num', there are more supported sizes than the function was
>>> + * allowed to output. If return value (N) is less than 'num', only sizes
>>> + * [0 ... N-1] have been written. Returned values are ordered from 
>>> smallest to
>>> + * largest.
>>> + *
>>> + * @param[out] size Points to an array of huge page sizes for output
>>> + * @param  num  Maximum number of huge page sizes to output
>>> + *
>>> + * @return Number of supported huge page sizes
>>> + * @retval 0 on no huge pages
>>> + */
>>> +unsigned odp_sys_huge_page_size_all(uint64_t size[], unsigned num);
>>> +
>>
>> I think it has to be int. -1 on error, 0 - no hp, > 0 pages.
>> For linux it might be similar to getpagesizes()
>> https://linux.die.net/man/3/getpagesizes
>> """
>> if pagesizes is NULL and n_elem is 0, then the number of pages the
>> system supports is returned. Otherwise, pagesizes is filled with at most
>> n_elem page sizes.
>> """
>>
> 
> getpagesizes() returns -1 in a case of invalid function arguments. 
> odp_sys_huge_page_size_all() is documented so that the application cannot 
> pass invalid arguments. So an internal error would be the only possibility. I 
> don't see this to be likely as the function is only reading system info.
> 
> Adding -1 return value would also increase application complexity as the 
> error return value would require special handling from application.
> 

We have to be consistent with all odp api functions. We do not have
unsigned function, they are int. This function is not fast path so
additional check is ok. And -1 can be returned on permission error to
assess /proc or /sys files for example or any other internal failure.

Maxim.


>>
>> But why do we need this inside ODP? It time be reasonable to say that
>> it's number of pages/sizes visible to current ODP instance (i.e. not the
>> system global.)
>>
> 
> A system can simultaneously support multiple huge page sizes and an 
> application may
> for example do some alignment decisions based on this information. I found 
> this issues when implementing shm for odp-dpdk and trying to pass the 
> validation tests. This API change enables adding a proper test for 
> odp_shm_info_t.page_size.
> 
> -Matias
> 
> 



[lng-odp] [Linaro/odp] d3602c: validation: crypto: add HMAC-SHA-1 test cases

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: d3602cb56413bb31b4535976dfd3dd723a16bfc9
  
https://github.com/Linaro/odp/commit/d3602cb56413bb31b4535976dfd3dd723a16bfc9
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/crypto.h
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h
M test/common_plat/validation/api/crypto/test_vectors_len.h

  Log Message:
  ---
  validation: crypto: add HMAC-SHA-1 test cases

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 908e27: validation: crypto: add tests for NULL cipher

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 908e27635dfe08e249407f4c4e53aa2c7ce12ea1
  
https://github.com/Linaro/odp/commit/908e27635dfe08e249407f4c4e53aa2c7ce12ea1
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/crypto.h
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h
M test/common_plat/validation/api/crypto/test_vectors_len.h

  Log Message:
  ---
  validation: crypto: add tests for NULL cipher

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] d80e02: crypto: linux-generic: add capabilities for CIPHER...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: d80e025c8baebed0305648737e528580b84fae2a
  
https://github.com/Linaro/odp/commit/d80e025c8baebed0305648737e528580b84fae2a
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/odp_crypto.c
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c

  Log Message:
  ---
  crypto: linux-generic: add capabilities for CIPHER_NULL and AUTH_NULL

There is no point in having separate cases for NULL algorithms. Add
capabilities returning 0 key/digest/iv length.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 33a0da: test: odp_crypto: bail out if odp_crypto_session_c...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 33a0dad444fab1c1567083b289eac7727eab3b31
  
https://github.com/Linaro/odp/commit/33a0dad444fab1c1567083b289eac7727eab3b31
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/performance/odp_crypto.c

  Log Message:
  ---
  test: odp_crypto: bail out if odp_crypto_session_create failed

If odp_crypto_session_create() failed, there is no point in
checking/freeing session, as it might not have been updated.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] d8e464: linux-generic: crypto: make en/decryption work acr...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: d8e4647baa7b1159480dfde4d5a2143146e8c6cb
  
https://github.com/Linaro/odp/commit/d8e4647baa7b1159480dfde4d5a2143146e8c6cb
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: make en/decryption work across packet segments

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 20cc38: linux-generic: crypto: make HMAC work across segme...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 20cc38e36a52f70758c3464014f4f00a94d2139d
  
https://github.com/Linaro/odp/commit/20cc38e36a52f70758c3464014f4f00a94d2139d
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: make HMAC work across segmented packets

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 9bb2a4: linux-generic: crypto: merge AES-CBC and 3DES-CBC ...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 9bb2a439ae2a8751df5a6007a7e242d7bcb963e5
  
https://github.com/Linaro/odp/commit/9bb2a439ae2a8751df5a6007a7e242d7bcb963e5
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/include/odp_crypto_internal.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  linux-generic: crypto: merge AES-CBC and 3DES-CBC support

There is now nearly no difference between AES-CBC and 3DES-CBC code.
Merge it into generic 'cipher' support, easing adding support for other
ciphers in future.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] a6fa9f: linux-generic: crypto: rewrite 3DES-CBC support us...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: a6fa9f3e721dbdb99e2a0bac320f988930e5f874
  
https://github.com/Linaro/odp/commit/a6fa9f3e721dbdb99e2a0bac320f988930e5f874
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/include/odp_crypto_internal.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  linux-generic: crypto: rewrite 3DES-CBC support using EVP functions

Rewrite 3DES-CBC to use generic EVP interface following AES-GCM
implementation.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] b2261b: linux-generic: crypto: rewrite AES-CBC support usi...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: b2261b9485e6993642c5c0c7ea58abb8a2d356a9
  
https://github.com/Linaro/odp/commit/b2261b9485e6993642c5c0c7ea58abb8a2d356a9
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/include/odp_crypto_internal.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  linux-generic: crypto: rewrite AES-CBC support using EVP functions

Rewrite AES-CBC to use generic EVP interface following AES-GCM
implementation.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] c969cc: linux-generic: crypto: explicitly disable padding ...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: c969cc4e6f6e2e0cc5c4e407dd696be069cf4525
  
https://github.com/Linaro/odp/commit/c969cc4e6f6e2e0cc5c4e407dd696be069cf4525
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: explicitly disable padding for AES-GCM

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 3a1832: linux-generic: crypto: make AES-GCM thread safe

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 3a1832865c90865de3fd8bd30103995637e7851c
  
https://github.com/Linaro/odp/commit/3a1832865c90865de3fd8bd30103995637e7851c
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M platform/linux-generic/include/odp_crypto_internal.h
M platform/linux-generic/odp_crypto.c

  Log Message:
  ---
  linux-generic: crypto: make AES-GCM thread safe

Using single context for all operations is not thread safe: multiple
threads can access the same context in parallel, affecting its internal
state. Make AES-GCM functions use local context for en/decryption
operations.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] ab5a09: linux-generic: crypto: remote extra memcpy in AES-...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: ab5a099937bc3d81f610fcfc2a98bfb7e677a06a
  
https://github.com/Linaro/odp/commit/ab5a099937bc3d81f610fcfc2a98bfb7e677a06a
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: remote extra memcpy in AES-GCM

There is no need to memcpy IV if it gets passed to EVP functions.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 9f506f: linux-generic: crypto: update AES-GCM support to r...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 9f506fecfcd408a8af0df0e9627795d0b1059730
  
https://github.com/Linaro/odp/commit/9f506fecfcd408a8af0df0e9627795d0b1059730
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: update AES-GCM support to reflect aad and 
auth_digest_len

Make AES-GCM use recently introduced aad and auth_digest_len fields.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] c184a9: linux-generic: crypto: add SHA* capabilities for f...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: c184a9c8d35c10b30014e7538a862a7bc42556e7
  
https://github.com/Linaro/odp/commit/c184a9c8d35c10b30014e7538a862a7bc42556e7
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: add SHA* capabilities for full length digests

In addition to truncated digests (used by IPsec) add full-length
capabilities to SHA* algos.

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 9ebcb7: linux-generic: crypto: use auth_digest_len when ca...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 9ebcb7c6e2f3226c915c39c81dcd1895dda3639b
  
https://github.com/Linaro/odp/commit/9ebcb7c6e2f3226c915c39c81dcd1895dda3639b
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

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

  Log Message:
  ---
  linux-generic: crypto: use auth_digest_len when calculating HMACs

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 2f137b: example: ipsec: set auth_digest_len

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 2f137b2bc9cb9c03a586d2cb324a6a5659098c39
  
https://github.com/Linaro/odp/commit/2f137b2bc9cb9c03a586d2cb324a6a5659098c39
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M example/ipsec/odp_ipsec_cache.c

  Log Message:
  ---
  example: ipsec: set auth_digest_len

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 2f1a96: test: odp_crypto: update performance test to set a...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 2f1a96d47bb2e6c413ed06749633dcfe33f02b97
  
https://github.com/Linaro/odp/commit/2f1a96d47bb2e6c413ed06749633dcfe33f02b97
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/performance/odp_crypto.c

  Log Message:
  ---
  test: odp_crypto: update performance test to set auth_digest_length

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 4cdaf5: validation: crypto: explicitly pass AAD to crypto ...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 4cdaf5527dba63858080c0942ac1c971c615f066
  
https://github.com/Linaro/odp/commit/4cdaf5527dba63858080c0942ac1c971c615f066
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h

  Log Message:
  ---
  validation: crypto: explicitly pass AAD to crypto subsystem

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Linaro/odp] 77dff4: validation: crypto: explicitly pass auth_digest_le...

2017-06-02 Thread GitHub
  Branch: refs/heads/api-next
  Home:   https://github.com/Linaro/odp
  Commit: 77dff4e05611bc5b06b4bfb5dd86da6d4c3fffa5
  
https://github.com/Linaro/odp/commit/77dff4e05611bc5b06b4bfb5dd86da6d4c3fffa5
  Author: Dmitry Eremin-Solenikov 
  Date:   2017-06-02 (Fri, 02 Jun 2017)

  Changed paths:
M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
M test/common_plat/validation/api/crypto/test_vectors.h
M test/common_plat/validation/api/crypto/test_vectors_len.h

  Log Message:
  ---
  validation: crypto: explicitly pass auth_digest_len to crypto subsystem

Signed-off-by: Dmitry Eremin-Solenikov 
Reviewed-by: Petri Savolainen 
Signed-off-by: Maxim Uvarov 




[lng-odp] [Bug 3026] pktio_ips_run test can fail due to segfault

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3026

Bill Fischofer  changed:

   What|Removed |Added

 CC||bill.fischo...@linaro.org

--- Comment #1 from Bill Fischofer  ---
Interesting. Is this on the current master? How reproducible is this and what
is the nature of the segfault? I've been working with Maxim on a related
anomaly I noticed in trying to get the zero-copy packet reference code ready
for integration. The pktrefs branch of my Github ODP repo reproduces a segfault
every time with this test. 

Debugging seems to indicate that the offset fields of the pkthdrs are somehow
getting corrupted and the pktrefs code is noticing this as attempted frees of
packets that already appear to be free (ref_count == 0). 

Here's where things stand with that debug effort:

=== Bill email

Did some more debugging. I've verified that during
ipc_pktio_recv_lockless() processing, when

_ipc_free_ring_packets(pktio_entry, pktio_entry->s.ipc.tx.free)

is called, all of the packet hdrs show a refcount of 1 and ref_hdr ==
NULL, as expected. However after the subsequent:

pkts = _ring_mc_dequeue_burst(r, ipcbufs_p, len);

call, the for loop processing the dequeued packets see ref_count == 0
and ref_hdr == NULL. This suggests that what's being dequeued are
freed packets, which is why subsequent attempts to free these packets
via odp_packet_free() in _ipc_free_ring_packets() fails

=== Maxim email

did some more debug but without luck:
- removed 2 patches from top;
- set ref count to 1 everywhere in ipc rx/tx;
- set to 1 ref counter for all segments on alloc packet;
- removed decrement for ref counter everywhere.

The same strange thing happens. Looks like phdr is corrupted or offset
to it calculated wrongly due aliment.

=== Bill email

If the offsets are somehow being miscomputed that would explain how
things go bad. Solution would seem to put markers in the phdrs and
then when refcount is seen to be 0 dump the "phdr" to see how it
aligns with the markers that should be there.

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

[lng-odp] [Bug 3026] New: pktio_ips_run test can fail due to segfault

2017-06-02 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=3026

Bug ID: 3026
   Summary: pktio_ips_run test can fail due to segfault
   Product: OpenDataPlane - linux- generic reference
   Version: master
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: Packet IO
  Assignee: maxim.uva...@linaro.org
  Reporter: dmitry.ereminsoleni...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

FAIL: pktio_ipc/pktio_ipc_run
=
 run pktio_ipc1 then pktio_ipc2 
_ishm.c:866:_odp_ishm_reserve():No huge pages, fall back to normal pages.
check: /proc/sys/vm/nr_hugepages.
_ishm.c:866:_odp_ishm_reserve():No huge pages, fall back to normal pages.
check: /proc/sys/vm/nr_hugepages.
 PKTIO: initialized loop interface.
 PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to disable.
 PKTIO: initialized netmap pktio, use export ODP_PKTIO_DISABLE_NETMAP=1 to
disable.
 Netmap prefixes are netmap:eth0 or vale:eth0. Refer to Netmap documentation
for usage information.
 PKTIO: initialized pcap interface.
 PKTIO: initialized ipc interface.
 PKTIO: initialized socket mmap, use export ODP_PKTIO_DISABLE_SOCKET_MMAP=1 to
disable.
 PKTIO: initialized socket mmsg,use export ODP_PKTIO_DISABLE_SOCKET_MMSG=1 to
disable.
ODP system info
---
ODP API version: 1.14.0
CPU model:   Intel(R) Xeon(R) CPU
Running ODP appl: "pktio_ipc1"
-
Using IF:(null)
pktio/dpdk.c:459:dpdk_open():Invalid dpdk netdev: ipc:ipktio
pktio/netmap.c:370:netmap_open():nm_open(netmap:ipc:ipktio) failed
pktio/dpdk.c:459:dpdk_open():Invalid dpdk netdev: ipc:15832:ipktio
pktio/netmap.c:370:netmap_open():nm_open(netmap:ipc:15832:ipkti) failed
pktio_ipc1.c:188:pktio_run_loop():head.seq 0 - cnt_recv 1 =
18446744073709551615
Segmentation fault (core dumped)
ipc_common.c:48:ipc_odp_packet_send_or_free():Send Timeout!
pktio_ipc1.c:256:pktio_run_loop():unable to sending to ipc pktio
pktio_ipc1.c:353:main():return 0
Pool info
-
  pool0
  nameipc_packet_pool
  pool type   packet
  pool shm10
  user area shm   0
  num 8192
  align   64
  headroom66
  data size   8126
  max data len48756
  max seg len 8126
  tailroom0
  block size  8768
  uarea size  0
  shm size71827456
  base addr   0x2b947354f000
  uarea shm size  0
  uarea base addr (nil)
pid: 15832, create IPC pktio ipc:ipktio
normal exit of 2 application
srwxrwxr-x 1 travis travis0 Jun  2 11:32 /tmp/odp-15833-fdserver
-rw-r--r-- 1 travis travis 71827456 Jun  2 11:32
/tmp/odp-15833-ishm-ipc_packet_pool
-rw-rw-r-- 1 travis travis  177 Jun  2 11:32
/tmp/odp-15833-shm-ipc_packet_pool
!!!First stage  FAILED 139!!!

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

Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Maxim Uvarov
I think this patch has to be spit on several patches. Having patch which
correct unrelated things is strange and make it hard to merge/cherry-pick.

Maxim.

On 06/02/17 10:39, Dmitry Eremin-Solenikov wrote:
> On 01.06.2017 22:05, Brian Brooks wrote:
>> Signed-off-by: Brian Brooks 
>> Reviewed-by: Ola Liljedahl 
>> Reviewed-by: Honnappa Nagarahalli 
>> ---
>>  configure.ac  | 5 +
>>  platform/linux-generic/m4/configure.m4| 4 
>>  platform/linux-generic/pktio/ipc.c| 6 --
>>  platform/linux-generic/pktio/sysfs.c  | 2 +-
>>  test/common_plat/validation/api/pktio/pktio.c | 4 +++-
>>  5 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 7569ebe0..5eabe4d4 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
>> -Wold-style-definition -Wpointer-
>>  ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
>> -Wformat-nonliteral"
>>  ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
>>  ODP_CFLAGS="$ODP_CFLAGS -std=c99"
>> +
>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
>> +  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
>> +fi
>> +
> 
> Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
> warning?
> 
>>  # Extra flags for example to suppress certain warning types
>>  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
>>  
>> diff --git a/platform/linux-generic/m4/configure.m4 
>> b/platform/linux-generic/m4/configure.m4
>> index a2a25408..3e2978b5 100644
>> --- a/platform/linux-generic/m4/configure.m4
>> +++ b/platform/linux-generic/m4/configure.m4
>> @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
>>  echo "Use newer version. For gcc > 4.7.0"
>>  exit -1)
>>  
>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
>> +  AM_LDFLAGS="$AM_LDFLAGS -latomic"
>> +fi
>> +
> 
> This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS
> 
>>  m4_include([platform/linux-generic/m4/odp_pthread.m4])
>>  m4_include([platform/linux-generic/m4/odp_openssl.m4])
>>  m4_include([platform/linux-generic/m4/odp_pcap.m4])
>> diff --git a/platform/linux-generic/pktio/ipc.c 
>> b/platform/linux-generic/pktio/ipc.c
>> index 06175e5a..29c3a546 100644
>> --- a/platform/linux-generic/pktio/ipc.c
>> +++ b/platform/linux-generic/pktio/ipc.c
>> @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
>>  
>>  if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
>>  snprintf(name, sizeof(name), "ipc:%s", tail);
>> -else
>> -snprintf(name, sizeof(name), "%s", dev);
>> +else {
>> +strncpy(name, dev, sizeof(name));
>> +name[sizeof(name) - 1] = '\0';
>> +}
> 
> Why?
> 
>>  
>>  /* unlink this pktio info for both master and slave */
>>  odp_shm_free(pktio_entry->s.ipc.pinfo_shm);
> 
> 



Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Peltonen, Janne (Nokia - FI/Espoo)


> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Friday, June 02, 2017 1:54 PM
> To: Peltonen, Janne (Nokia - FI/Espoo) ; 
> Savolainen, Petri
> (Nokia - FI/Espoo) ; Honnappa Nagarahalli
> 
> Cc: Elo, Matias (Nokia - FI/Espoo) ; nd ; 
> Kevin Wang
> ; Honnappa Nagarahalli ; 
> lng-
> o...@lists.linaro.org
> Subject: Re: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add 
> scalable scheduler
> 
> 
> >
> >
> >> -Original Message-
> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> >>Savolainen, Petri
> >> (Nokia - FI/Espoo)
> >> Sent: Friday, June 02, 2017 1:18 PM
> >> To: Honnappa Nagarahalli ; Ola
> >>Liljedahl
> >> 
> >> Cc: Elo, Matias (Nokia - FI/Espoo) ; nd
> >>; Kevin Wang
> >> ; Honnappa Nagarahalli
> >>; lng-
> >> o...@lists.linaro.org
> >> Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add
> >>scalable scheduler
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> >> > Honnappa Nagarahalli
> >> > Sent: Thursday, June 01, 2017 11:30 PM
> >> > To: Ola Liljedahl 
> >> > Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
> >> > ; Elo, Matias (Nokia - FI/Espoo)
> >> > ; Kevin Wang ; nd
> >>
> >> > Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
> >> >
> >> > On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
> >> > >  wrote:
> >> > >
> >> > >>On 1 June 2017 at 15:09, Ola Liljedahl 
> >>wrote:
> >> > >>>
> >> > >>>
> >> > >>> On 01/06/2017, 21:03, "Bill Fischofer" 
> >> > >>>wrote:
> >> > >>>
> >> > On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
> >> >  wrote:
> >> > > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
> >> > >  wrote:
> >> > >>
> >> > >>> On 31 May 2017, at 23:53, Bill Fischofer
> >> > 
> >> > >>>wrote:
> >> > >>>
> >> > >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia -
> >>FI/Espoo)
> >> > >>>  wrote:
> >> > 
> >> > >>> What¹s the purpose of calling ord_enq_multi() here? To
> >>save
> >> > >>>(stash)
> >> > >>> packets if the thread is out-of-order?
> >> > >>> And when the thread is in-order, it is re-enqueueing the
> >> > packets
> >> > >>>which
> >> > >>> again will invoke pktout_enqueue/pktout_enq_multi but this
> >> > time
> >> > >>> ord_enq_multi() will not save the packets, instead they
> >>will
> >> > >>>actually be
> >> > >>> transmitted by odp_pktout_send()?
> >> > >>>
> >> > >>
> >> > >> Since transmitting packets may fail, out-of-order packets
> >> > cannot
> >> > >>be
> >> > >> stashed here.
> >> > > You mean that the TX queue of the pktio might be full so
> >>not all
> >> > >packets
> >> > > will actually be enqueued for transmission.
> >> > 
> >> >  Yep.
> >> > 
> >> > > This is an interesting case but is it a must to know how
> >>many
> >> > >packets are
> >> > > actually accepted? Packets can always be dropped without
> >>notice,
> >> > >the
> >> > > question is from which point this is acceptable. If packets
> >> > >enqueued onto
> >> > > a pktout (egress) queue are accepted, this means that they
> >>must
> >> > >also be
> >> > > put onto the driver TX queue (as done by odp_pktout_send)?
> >> > >
> >> > 
> >> >  Currently, the packet_io/queue APIs don't say anything about
> >> > packets
> >> > being
> >> >  possibly dropped after successfully calling odp_queue_enq()
> >>to a
> >> > pktout
> >> >  event queue. So to be consistent with standard
> >>odp_queue_enq()
> >> > operations I
> >> >  think it is better to return the number of events actually
> >> > accepted
> >> > to the TX queue.
> >> > 
> >> >  To have more leeway one option would be to modify the API
> >> > documentation to
> >> >  state that packets may still be dropped after a successful
> >> > odp_queue_enq() call
> >> >  before reaching the NIC. If the application would like to 

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Ola Liljedahl

On 02/06/2017, 12:53, "Peltonen, Janne (Nokia - FI/Espoo)"
 wrote:

>>> for packet output to first tell application that a packet was "accepted
>>>for transmission" and then drop it silently. Packet out (it's a simple
>>>function) should be able to determine if packet can be accepted for
>>>transmission and if it's accepted the packet will eventually go out.
>>Obviously, packet out is not so simple to implement when considering
>>order
>>restoration etc. The original linux-generic implementation was wrong.
>
>Ordering in the  Linux-generic implementation went accidentally broken
>in January when the new ordered queue implementation was added. I suppose
>it worked before that.
OK so remove the word ³original² from my statement above.



Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Ola Liljedahl

>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>Savolainen, Petri
>> (Nokia - FI/Espoo)
>> Sent: Friday, June 02, 2017 1:18 PM
>> To: Honnappa Nagarahalli ; Ola
>>Liljedahl
>> 
>> Cc: Elo, Matias (Nokia - FI/Espoo) ; nd
>>; Kevin Wang
>> ; Honnappa Nagarahalli
>>; lng-
>> o...@lists.linaro.org
>> Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add
>>scalable scheduler
>> 
>> 
>> 
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> > Honnappa Nagarahalli
>> > Sent: Thursday, June 01, 2017 11:30 PM
>> > To: Ola Liljedahl 
>> > Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
>> > ; Elo, Matias (Nokia - FI/Espoo)
>> > ; Kevin Wang ; nd
>>
>> > Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
>> >
>> > On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
>> > >
>> > >
>> > >
>> > >
>> > > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
>> > >  wrote:
>> > >
>> > >>On 1 June 2017 at 15:09, Ola Liljedahl 
>>wrote:
>> > >>>
>> > >>>
>> > >>> On 01/06/2017, 21:03, "Bill Fischofer" 
>> > >>>wrote:
>> > >>>
>> > On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
>> >  wrote:
>> > > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
>> > >  wrote:
>> > >>
>> > >>> On 31 May 2017, at 23:53, Bill Fischofer
>> > 
>> > >>>wrote:
>> > >>>
>> > >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia -
>>FI/Espoo)
>> > >>>  wrote:
>> > 
>> > >>> What¹s the purpose of calling ord_enq_multi() here? To
>>save
>> > >>>(stash)
>> > >>> packets if the thread is out-of-order?
>> > >>> And when the thread is in-order, it is re-enqueueing the
>> > packets
>> > >>>which
>> > >>> again will invoke pktout_enqueue/pktout_enq_multi but this
>> > time
>> > >>> ord_enq_multi() will not save the packets, instead they
>>will
>> > >>>actually be
>> > >>> transmitted by odp_pktout_send()?
>> > >>>
>> > >>
>> > >> Since transmitting packets may fail, out-of-order packets
>> > cannot
>> > >>be
>> > >> stashed here.
>> > > You mean that the TX queue of the pktio might be full so
>>not all
>> > >packets
>> > > will actually be enqueued for transmission.
>> > 
>> >  Yep.
>> > 
>> > > This is an interesting case but is it a must to know how
>>many
>> > >packets are
>> > > actually accepted? Packets can always be dropped without
>>notice,
>> > >the
>> > > question is from which point this is acceptable. If packets
>> > >enqueued onto
>> > > a pktout (egress) queue are accepted, this means that they
>>must
>> > >also be
>> > > put onto the driver TX queue (as done by odp_pktout_send)?
>> > >
>> > 
>> >  Currently, the packet_io/queue APIs don't say anything about
>> > packets
>> > being
>> >  possibly dropped after successfully calling odp_queue_enq()
>>to a
>> > pktout
>> >  event queue. So to be consistent with standard
>>odp_queue_enq()
>> > operations I
>> >  think it is better to return the number of events actually
>> > accepted
>> > to the TX queue.
>> > 
>> >  To have more leeway one option would be to modify the API
>> > documentation to
>> >  state that packets may still be dropped after a successful
>> > odp_queue_enq() call
>> >  before reaching the NIC. If the application would like to be
>>sure
>> > that the
>> >  packets are actually sent, it should use odp_pktout_send()
>> > instead.
>> > >>>
>> > >>> Ordered queues simply say that packets will be delivered to
>>the
>> > next
>> > >>> queue in the pipeline in the order they originated from their
>> > source
>> > >>> queue. What happens after that depends on the attributes of
>>the
>> > >>>target
>> > >>> queue. If the target queue is an exit point from the
>>application,
>> > >>>then
>> > >>> this is outside of ODP's scope.
>> > >>
>> > >> My point was that with stashing the application has no way of
>> > knowing
>> > >>if an
>> > >> ordered pktout enqueue call actually succeed. In case of
>>parallel
>> > and
>> > >>atomic
>> > >> queues it does. So my question is, is this acceptable?
>> > >>
>> > 

Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Peltonen, Janne (Nokia - FI/Espoo)


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Savolainen, Petri
> (Nokia - FI/Espoo)
> Sent: Friday, June 02, 2017 1:18 PM
> To: Honnappa Nagarahalli ; Ola Liljedahl
> 
> Cc: Elo, Matias (Nokia - FI/Espoo) ; nd ; 
> Kevin Wang
> ; Honnappa Nagarahalli ; 
> lng-
> o...@lists.linaro.org
> Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable 
> scheduler
> 
> 
> 
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Honnappa Nagarahalli
> > Sent: Thursday, June 01, 2017 11:30 PM
> > To: Ola Liljedahl 
> > Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
> > ; Elo, Matias (Nokia - FI/Espoo)
> > ; Kevin Wang ; nd 
> > Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
> >
> > On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
> > >
> > >
> > >
> > >
> > > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
> > >  wrote:
> > >
> > >>On 1 June 2017 at 15:09, Ola Liljedahl  wrote:
> > >>>
> > >>>
> > >>> On 01/06/2017, 21:03, "Bill Fischofer" 
> > >>>wrote:
> > >>>
> > On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
> >  wrote:
> > > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
> > >  wrote:
> > >>
> > >>> On 31 May 2017, at 23:53, Bill Fischofer
> > 
> > >>>wrote:
> > >>>
> > >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo)
> > >>>  wrote:
> > 
> > >>> What¹s the purpose of calling ord_enq_multi() here? To save
> > >>>(stash)
> > >>> packets if the thread is out-of-order?
> > >>> And when the thread is in-order, it is re-enqueueing the
> > packets
> > >>>which
> > >>> again will invoke pktout_enqueue/pktout_enq_multi but this
> > time
> > >>> ord_enq_multi() will not save the packets, instead they will
> > >>>actually be
> > >>> transmitted by odp_pktout_send()?
> > >>>
> > >>
> > >> Since transmitting packets may fail, out-of-order packets
> > cannot
> > >>be
> > >> stashed here.
> > > You mean that the TX queue of the pktio might be full so not all
> > >packets
> > > will actually be enqueued for transmission.
> > 
> >  Yep.
> > 
> > > This is an interesting case but is it a must to know how many
> > >packets are
> > > actually accepted? Packets can always be dropped without notice,
> > >the
> > > question is from which point this is acceptable. If packets
> > >enqueued onto
> > > a pktout (egress) queue are accepted, this means that they must
> > >also be
> > > put onto the driver TX queue (as done by odp_pktout_send)?
> > >
> > 
> >  Currently, the packet_io/queue APIs don't say anything about
> > packets
> > being
> >  possibly dropped after successfully calling odp_queue_enq() to a
> > pktout
> >  event queue. So to be consistent with standard odp_queue_enq()
> > operations I
> >  think it is better to return the number of events actually
> > accepted
> > to the TX queue.
> > 
> >  To have more leeway one option would be to modify the API
> > documentation to
> >  state that packets may still be dropped after a successful
> > odp_queue_enq() call
> >  before reaching the NIC. If the application would like to be sure
> > that the
> >  packets are actually sent, it should use odp_pktout_send()
> > instead.
> > >>>
> > >>> Ordered queues simply say that packets will be delivered to the
> > next
> > >>> queue in the pipeline in the order they originated from their
> > source
> > >>> queue. What happens after that depends on the attributes of the
> > >>>target
> > >>> queue. If the target queue is an exit point from the application,
> > >>>then
> > >>> this is outside of ODP's scope.
> > >>
> > >> My point was that with stashing the application has no way of
> > knowing
> > >>if an
> > >> ordered pktout enqueue call actually succeed. In case of parallel
> > and
> > >>atomic
> > >> queues it does. So my question is, is this acceptable?
> > >>
> > > Also, currently, it is not possible for the application to have a
> > > consistent 'wait/drop on destination queue full' policy for all the
> > 

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

2017-06-02 Thread Ola Liljedahl


On 02/06/2017, 12:17, "Savolainen, Petri (Nokia - FI/Espoo)"
 wrote:

>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Honnappa Nagarahalli
>> Sent: Thursday, June 01, 2017 11:30 PM
>> To: Ola Liljedahl 
>> Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
>> ; Elo, Matias (Nokia - FI/Espoo)
>> ; Kevin Wang ; nd 
>> Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
>> 
>> On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
>> >
>> >
>> >
>> >
>> > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
>> >  wrote:
>> >
>> >>On 1 June 2017 at 15:09, Ola Liljedahl  wrote:
>> >>>
>> >>>
>> >>> On 01/06/2017, 21:03, "Bill Fischofer" 
>> >>>wrote:
>> >>>
>> On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
>>  wrote:
>> > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
>> >  wrote:
>> >>
>> >>> On 31 May 2017, at 23:53, Bill Fischofer
>> 
>> >>>wrote:
>> >>>
>> >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo)
>> >>>  wrote:
>> 
>> >>> What¹s the purpose of calling ord_enq_multi() here? To save
>> >>>(stash)
>> >>> packets if the thread is out-of-order?
>> >>> And when the thread is in-order, it is re-enqueueing the
>> packets
>> >>>which
>> >>> again will invoke pktout_enqueue/pktout_enq_multi but this
>> time
>> >>> ord_enq_multi() will not save the packets, instead they will
>> >>>actually be
>> >>> transmitted by odp_pktout_send()?
>> >>>
>> >>
>> >> Since transmitting packets may fail, out-of-order packets
>> cannot
>> >>be
>> >> stashed here.
>> > You mean that the TX queue of the pktio might be full so not
>>all
>> >packets
>> > will actually be enqueued for transmission.
>> 
>>  Yep.
>> 
>> > This is an interesting case but is it a must to know how many
>> >packets are
>> > actually accepted? Packets can always be dropped without
>>notice,
>> >the
>> > question is from which point this is acceptable. If packets
>> >enqueued onto
>> > a pktout (egress) queue are accepted, this means that they
>>must
>> >also be
>> > put onto the driver TX queue (as done by odp_pktout_send)?
>> >
>> 
>>  Currently, the packet_io/queue APIs don't say anything about
>> packets
>> being
>>  possibly dropped after successfully calling odp_queue_enq() to
>>a
>> pktout
>>  event queue. So to be consistent with standard odp_queue_enq()
>> operations I
>>  think it is better to return the number of events actually
>> accepted
>> to the TX queue.
>> 
>>  To have more leeway one option would be to modify the API
>> documentation to
>>  state that packets may still be dropped after a successful
>> odp_queue_enq() call
>>  before reaching the NIC. If the application would like to be
>>sure
>> that the
>>  packets are actually sent, it should use odp_pktout_send()
>> instead.
>> >>>
>> >>> Ordered queues simply say that packets will be delivered to the
>> next
>> >>> queue in the pipeline in the order they originated from their
>> source
>> >>> queue. What happens after that depends on the attributes of the
>> >>>target
>> >>> queue. If the target queue is an exit point from the
>>application,
>> >>>then
>> >>> this is outside of ODP's scope.
>> >>
>> >> My point was that with stashing the application has no way of
>> knowing
>> >>if an
>> >> ordered pktout enqueue call actually succeed. In case of parallel
>> and
>> >>atomic
>> >> queues it does. So my question is, is this acceptable?
>> >>
>> > Also, currently, it is not possible for the application to have a
>> > consistent 'wait/drop on destination queue full' policy for all
>>the
>> > queue types.
>> 
>> Today applications have no way of knowing whether packets sent to a
>> pktout_queue or tm_queue actually make it to the wire or whether
>>they
>> are vaporized as soon as they hit the wire, so there's no change
>>here.
>> An RC of 0 simply says that the packet was "accepted" for
>>transmission
>> and hence the caller no longer owns that packet handle. You need
>> higher-level protocols to track end-to-end transmission and receipt.
>> All that ordered queues say is that packets being sent to TX queues
>> will have 

Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler

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


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Honnappa Nagarahalli
> Sent: Thursday, June 01, 2017 11:30 PM
> To: Ola Liljedahl 
> Cc: lng-odp@lists.linaro.org; Honnappa Nagarahalli
> ; Elo, Matias (Nokia - FI/Espoo)
> ; Kevin Wang ; nd 
> Subject: Re: [lng-odp] [API-NEXT PATCH v6 6/6] Add scalable scheduler
> 
> On 1 June 2017 at 15:20, Ola Liljedahl  wrote:
> >
> >
> >
> >
> > On 01/06/2017, 22:15, "Honnappa Nagarahalli"
> >  wrote:
> >
> >>On 1 June 2017 at 15:09, Ola Liljedahl  wrote:
> >>>
> >>>
> >>> On 01/06/2017, 21:03, "Bill Fischofer" 
> >>>wrote:
> >>>
> On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli
>  wrote:
> > On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
> >  wrote:
> >>
> >>> On 31 May 2017, at 23:53, Bill Fischofer
> 
> >>>wrote:
> >>>
> >>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo)
> >>>  wrote:
> 
> >>> What¹s the purpose of calling ord_enq_multi() here? To save
> >>>(stash)
> >>> packets if the thread is out-of-order?
> >>> And when the thread is in-order, it is re-enqueueing the
> packets
> >>>which
> >>> again will invoke pktout_enqueue/pktout_enq_multi but this
> time
> >>> ord_enq_multi() will not save the packets, instead they will
> >>>actually be
> >>> transmitted by odp_pktout_send()?
> >>>
> >>
> >> Since transmitting packets may fail, out-of-order packets
> cannot
> >>be
> >> stashed here.
> > You mean that the TX queue of the pktio might be full so not all
> >packets
> > will actually be enqueued for transmission.
> 
>  Yep.
> 
> > This is an interesting case but is it a must to know how many
> >packets are
> > actually accepted? Packets can always be dropped without notice,
> >the
> > question is from which point this is acceptable. If packets
> >enqueued onto
> > a pktout (egress) queue are accepted, this means that they must
> >also be
> > put onto the driver TX queue (as done by odp_pktout_send)?
> >
> 
>  Currently, the packet_io/queue APIs don't say anything about
> packets
> being
>  possibly dropped after successfully calling odp_queue_enq() to a
> pktout
>  event queue. So to be consistent with standard odp_queue_enq()
> operations I
>  think it is better to return the number of events actually
> accepted
> to the TX queue.
> 
>  To have more leeway one option would be to modify the API
> documentation to
>  state that packets may still be dropped after a successful
> odp_queue_enq() call
>  before reaching the NIC. If the application would like to be sure
> that the
>  packets are actually sent, it should use odp_pktout_send()
> instead.
> >>>
> >>> Ordered queues simply say that packets will be delivered to the
> next
> >>> queue in the pipeline in the order they originated from their
> source
> >>> queue. What happens after that depends on the attributes of the
> >>>target
> >>> queue. If the target queue is an exit point from the application,
> >>>then
> >>> this is outside of ODP's scope.
> >>
> >> My point was that with stashing the application has no way of
> knowing
> >>if an
> >> ordered pktout enqueue call actually succeed. In case of parallel
> and
> >>atomic
> >> queues it does. So my question is, is this acceptable?
> >>
> > Also, currently, it is not possible for the application to have a
> > consistent 'wait/drop on destination queue full' policy for all the
> > queue types.
> 
> Today applications have no way of knowing whether packets sent to a
> pktout_queue or tm_queue actually make it to the wire or whether they
> are vaporized as soon as they hit the wire, so there's no change here.
> An RC of 0 simply says that the packet was "accepted" for transmission
> and hence the caller no longer owns that packet handle. You need
> higher-level protocols to track end-to-end transmission and receipt.
> All that ordered queues say is that packets being sent to TX queues
> will have those TX calls made in the same order as the source queue
> they originated from.
> 
> The only way to track packet disposition today is to (a) create a
> reference to the packet you want to transmit, (b) verify that
> 

Re: [lng-odp] [API-NEXT PATCH] api: system_info: add function for fetching all supported huge page sizes

2017-06-02 Thread Elo, Matias (Nokia - FI/Espoo)
>> 
>> /**
>> + * System huge page sizes in bytes
>> + *
>> + * Returns the number of huge page sizes supported by the system. Outputs 
>> up to
>> + * 'num' sizes when the 'size' array pointer is not NULL. If return value is
>> + * larger than 'num', there are more supported sizes than the function was
>> + * allowed to output. If return value (N) is less than 'num', only sizes
>> + * [0 ... N-1] have been written. Returned values are ordered from smallest 
>> to
>> + * largest.
>> + *
>> + * @param[out] size Points to an array of huge page sizes for output
>> + * @param  num  Maximum number of huge page sizes to output
>> + *
>> + * @return Number of supported huge page sizes
>> + * @retval 0 on no huge pages
>> + */
>> +unsigned odp_sys_huge_page_size_all(uint64_t size[], unsigned num);
>> +
> 
> I think it has to be int. -1 on error, 0 - no hp, > 0 pages.
> For linux it might be similar to getpagesizes()
> https://linux.die.net/man/3/getpagesizes
> """
> if pagesizes is NULL and n_elem is 0, then the number of pages the
> system supports is returned. Otherwise, pagesizes is filled with at most
> n_elem page sizes.
> """
> 

getpagesizes() returns -1 in a case of invalid function arguments. 
odp_sys_huge_page_size_all() is documented so that the application cannot pass 
invalid arguments. So an internal error would be the only possibility. I don't 
see this to be likely as the function is only reading system info.

Adding -1 return value would also increase application complexity as the error 
return value would require special handling from application.

> 
> But why do we need this inside ODP? It time be reasonable to say that
> it's number of pages/sizes visible to current ODP instance (i.e. not the
> system global.)
> 

A system can simultaneously support multiple huge page sizes and an application 
may
for example do some alignment decisions based on this information. I found this 
issues when implementing shm for odp-dpdk and trying to pass the validation 
tests. This API change enables adding a proper test for 
odp_shm_info_t.page_size.

-Matias




[lng-odp] [API-NEXT PATCH v2 2/2] api: ipsec: add max number of cos capability

2017-06-02 Thread Petri Savolainen
Added capability for maximum number of different CoS in
CLS pipelining.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 24f9fb18..ed4a470e 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -262,6 +262,12 @@ typedef struct odp_ipsec_capability_t {
 */
odp_support_t pipeline_cls;
 
+   /** Maximum number of different destination CoSes in classification
+*  pipelining. The same CoS may be used for many SAs. This is equal or
+*  less than 'max_cos' capability in classifier API.
+*/
+   uint32_t max_cls_cos;
+
/** Soft expiry limit in seconds support
 *
 *  0: Limit is not supported
@@ -679,7 +685,8 @@ typedef struct odp_ipsec_sa_param_t {
 *  classification through this CoS. Other result events are sent to
 *  'dest_queue'. This field is considered only when 'pipeline' is
 *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
+*  interface default CoS. The maximum number of different CoS supported
+*  is defined by IPsec capability max_cls_cos.
 */
odp_cos_t dest_cos;
 
-- 
2.11.0



[lng-odp] [API-NEXT PATCH v2 1/2] api: ipsec: refine packet order specification

2017-06-02 Thread Petri Savolainen
State more explicitly that async ipsec operations maintain packet
order the same way as odp_queue_enq_multi().

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 40 ++--
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index 3adc65f5..24f9fb18 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -1218,13 +1218,19 @@ int odp_ipsec_out(const odp_ipsec_op_param_t *input,
  * results through one or more ODP_EVENT_IPSEC_RESULT events with the following
  * ordering considerations.
  *
- * Asynchronous mode maintains (operation input) packet order per SA when
- * application calls the operation within an ordered or atomic scheduler 
context
- * of the same queue. Packet order is also maintained when application
- * otherwise guarantees (e.g. using locks) that the operation is not called
- * simultaneously from multiple threads for the same SA(s). Resulting
- * events for the same SA are enqueued in order, and packet handles (for the
- * same SA) are stored in order within an event.
+ * Asynchronous mode maintains packet order per SA when application calls the
+ * operation within an ordered or atomic scheduler context of the same queue.
+ * Resulting events for the same SA are enqueued in order and packet handles
+ * (for the same SA) are stored in order within an event. Packet order per SA 
at
+ * a destination queue is the same as if application would have enqueued 
packets
+ * there with odp_queue_enq_multi().
+ *
+ * Packet order is also maintained when application otherwise guarantees
+ * (e.g. using locks) that the operation is not called simultaneously from
+ * multiple threads for the same SA(s).
+ *
+ * Logically, packet processing (e.g. sequence number check) happens in the
+ * output order as defined above.
  *
  * The function may be used also in inline processing mode, e.g. for IPSEC
  * packets for which inline processing is not possible. Packets for the same SA
@@ -1248,13 +1254,19 @@ int odp_ipsec_in_enq(const odp_ipsec_op_param_t *input);
  * results through one or more ODP_EVENT_IPSEC_RESULT events with the following
  * ordering considerations.
  *
- * Asynchronous mode maintains (operation input) packet order per SA when
- * application calls the operation within an ordered or atomic scheduler 
context
- * of the same queue. Packet order is also maintained when application
- * otherwise guarantees (e.g. using locks) that the operation is not called
- * simultaneously from multiple threads for the same SA(s). Resulting
- * events for the same SA are enqueued in order, and packet handles (for the
- * same SA) are stored in order within an event.
+ * Asynchronous mode maintains packet order per SA when application calls the
+ * operation within an ordered or atomic scheduler context of the same queue.
+ * Resulting events for the same SA are enqueued in order and packet handles
+ * (for the same SA) are stored in order within an event. Packet order per SA 
at
+ * a destination queue is the same as if application would have enqueued 
packets
+ * there with odp_queue_enq_multi().
+ *
+ * Packet order is also maintained when application otherwise guarantees
+ * (e.g. using locks) that the operation is not called simultaneously from
+ * multiple threads for the same SA(s).
+ *
+ * Logically, packet processing (e.g. sequence number assignment) happens in 
the
+ * output order as defined above.
  *
  * The function may be used also in inline processing mode, e.g. for IPSEC
  * packets for which inline processing is not possible.
-- 
2.11.0



[lng-odp] [API-NEXT PATCH v2 0/2] IPsec API update

2017-06-02 Thread Petri Savolainen
Bill has reviewed v1.

v2
* rebase
* removed "api: ipsec: add capability for max packets per result event" from
  the set while we decide if result event are changed to packets
* updated max_cls_cos documentation with CLS capability (Bill)

Petri Savolainen (2):
  api: ipsec: refine packet order specification
  api: ipsec: add max number of cos capability

 include/odp/api/spec/ipsec.h | 49 ++--
 1 file changed, 34 insertions(+), 15 deletions(-)

-- 
2.11.0



Re: [lng-odp] Release needed

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

As I mentioned yesterday:

* ipsec.h is still in next branch, but should be removed from there. IPsec API 
should not be released yet.

* Crypto rework ([PATCH API-NEXT v5 00/23] Major cryptography code rework) 
should be merged into api-next and from there to next branch, since it fixes 
many crypto test and implementation issues, as well as updates implementation 
to the current crypto API level.


Otherwise, next branch seems OK.


-Petri


> -Original Message-
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Friday, June 02, 2017 12:22 AM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> Cc: Bill Fischofer ; LNG ODP Mailman List  o...@lists.linaro.org>
> Subject: Re: Release needed
> 
> Petri, next builds now. Will exclude patches you listed bellow and it
> will be ready. Please let me know if there any update.
> 
> On 06/01/17 15:18, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > * partial packet.h
> >   * addition of odp_packet_data_range_t
> >   * keep in api-next: chksum_insert
> > * partial packet_io.h
> >   * addition of parse config
> >   * keep in api-next: ipsec config
> 
> Thank you,
> Maxim.


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Dmitry Eremin-Solenikov
On 01.06.2017 22:05, Brian Brooks wrote:
> Signed-off-by: Brian Brooks 
> Reviewed-by: Ola Liljedahl 
> Reviewed-by: Honnappa Nagarahalli 
> ---
>  configure.ac  | 5 +
>  platform/linux-generic/m4/configure.m4| 4 
>  platform/linux-generic/pktio/ipc.c| 6 --
>  platform/linux-generic/pktio/sysfs.c  | 2 +-
>  test/common_plat/validation/api/pktio/pktio.c | 4 +++-
>  5 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 7569ebe0..5eabe4d4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations 
> -Wold-style-definition -Wpointer-
>  ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual 
> -Wformat-nonliteral"
>  ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
>  ODP_CFLAGS="$ODP_CFLAGS -std=c99"
> +
> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> +  ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
> +fi
> +

Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
warning?

>  # Extra flags for example to suppress certain warning types
>  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
>  
> diff --git a/platform/linux-generic/m4/configure.m4 
> b/platform/linux-generic/m4/configure.m4
> index a2a25408..3e2978b5 100644
> --- a/platform/linux-generic/m4/configure.m4
> +++ b/platform/linux-generic/m4/configure.m4
> @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
>  echo "Use newer version. For gcc > 4.7.0"
>  exit -1)
>  
> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> +  AM_LDFLAGS="$AM_LDFLAGS -latomic"
> +fi
> +

This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS

>  m4_include([platform/linux-generic/m4/odp_pthread.m4])
>  m4_include([platform/linux-generic/m4/odp_openssl.m4])
>  m4_include([platform/linux-generic/m4/odp_pcap.m4])
> diff --git a/platform/linux-generic/pktio/ipc.c 
> b/platform/linux-generic/pktio/ipc.c
> index 06175e5a..29c3a546 100644
> --- a/platform/linux-generic/pktio/ipc.c
> +++ b/platform/linux-generic/pktio/ipc.c
> @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
>  
>   if (sscanf(dev, "ipc:%d:%s", , tail) == 2)
>   snprintf(name, sizeof(name), "ipc:%s", tail);
> - else
> - snprintf(name, sizeof(name), "%s", dev);
> + else {
> + strncpy(name, dev, sizeof(name));
> + name[sizeof(name) - 1] = '\0';
> + }

Why?

>  
>   /* unlink this pktio info for both master and slave */
>   odp_shm_free(pktio_entry->s.ipc.pinfo_shm);


-- 
With best wishes
Dmitry


Re: [lng-odp] [PATCH] Fixes for GCC 7

2017-06-02 Thread Dmitry Eremin-Solenikov
On 02.06.2017 06:30, Bill Fischofer wrote:
> On Thu, Jun 1, 2017 at 9:48 PM, Brian Brooks  wrote:
>> On 06/01 15:00:28, Bill Fischofer wrote:
>>> If this is a bug fix it should reference a Bug that describes in more
>>> detail what is being fixed.
>>
>> Can you elaborate?
>>
>> The subject line "Fixes for GCC 7" is sufficient.
> 
> If this is fixing a bug the commit log should reference the bugzilla
> entry associated with that bug.

Or please include respective warnings/errors in commit message.

-- 
With best wishes
Dmitry