Re: [lng-odp] [PATCH] helper: remove ring code

[Maxim Uvarov]

merged,
Maxim.

On 02/17/16 21:20, Mike Holmes wrote:



On 17 February 2016 at 05:16, Maxim Uvarov > wrote:


Remove ring and dead api-next code. In api-next pktio ipc patches
moved ring code to linux-generic and updated that test case to
the latest odp api. If we ipc pktio will be accepted to master
than current api-next ring test will be used.

Signed-off-by: Maxim Uvarov mailto:maxim.uva...@linaro.org>>


Reviewed-by Mike Holmes >


---
configure.ac   |   1 -
 helper/Makefile.am   |   2 -
 helper/include/odp/helper/ring.h | 577
---
 helper/ring.c| 634
---
 test/Makefile.am |   2 +-
 test/api_test/.gitignore |   2 -
 test/api_test/Makefile.am|  16 -
 test/api_test/odp_common.c   |  91 --
 test/api_test/odp_common.h   |  42 ---
 test/api_test/odp_ring_test.c| 470 -
 10 files changed, 1 insertion(+), 1836 deletions(-)
 delete mode 100644 helper/include/odp/helper/ring.h
 delete mode 100644 helper/ring.c
 delete mode 100644 test/api_test/.gitignore
 delete mode 100644 test/api_test/Makefile.am
 delete mode 100644 test/api_test/odp_common.c
 delete mode 100644 test/api_test/odp_common.h
 delete mode 100644 test/api_test/odp_ring_test.c

diff --git a/configure.ac  b/configure.ac

index 8108ff2..a7cb035 100644
--- a/configure.ac 
+++ b/configure.ac 
@@ -336,7 +336,6 @@ AC_CONFIG_FILES([Makefile
 pkgconfig/libodphelper.pc
 scripts/Makefile
 test/Makefile
-test/api_test/Makefile
 test/performance/Makefile
 test/validation/Makefile
 test/validation/atomic/Makefile
diff --git a/helper/Makefile.am b/helper/Makefile.am
index a8665b2..6557793 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -10,7 +10,6 @@ AM_CFLAGS += -I$(top_srcdir)/include

 helperincludedir = $(includedir)/odp/helper/
 helperinclude_HEADERS = \
- $(srcdir)/include/odp/helper/ring.h \
  $(srcdir)/include/odp/helper/linux.h \
  $(srcdir)/include/odp/helper/chksum.h\
  $(srcdir)/include/odp/helper/eth.h\
@@ -30,7 +29,6 @@ noinst_HEADERS = \

 __LIB__libodphelper_la_SOURCES = \
linux.c \
-   ring.c \
hashtable.c \
lineartable.c

diff --git a/helper/include/odp/helper/ring.h
b/helper/include/odp/helper/ring.h
deleted file mode 100644
index 65c32ad..000
--- a/helper/include/odp/helper/ring.h
+++ /dev/null
@@ -1,577 +0,0 @@
-/* Copyright (c) 2014, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2013 Intel Corporation. All rights reserved.
- *   All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or
without
- *   modification, are permitted provided that the following
conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above
copyright
- *   notice, this list of conditions and the following
disclaimer.
- * * Redistributions in binary form must reproduce the above
copyright
- *   notice, this list of conditions and the following
disclaimer in
- *   the documentation and/or other materials provided with the
- *   distribution.
- * * Neither the name of Intel Corporation nor the names of its
- *   contributors may be used to endorse or promote products
derived
- *   from this software without specific prior written
permission.
- *
- *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS
- *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT
- *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
- *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
- *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE,
- *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY
- *   THEOR

[lng-odp] [PATCHv2 0/4] shmem docs

[Christophe Milard]

since v1: fixed escape around '+' char. (Bill)

Documentation updates documenting shmem and related items.

Christophe Milard (4):
  doc: glossary: defining ODP thread more precisely
  doc: user-guide: shmem
  doc: user-guide: fixing other typos
  doc: removing invalid characters

 doc/glossary.adoc  |  12 +-
 doc/implementers-guide/implementers-guide.adoc |  34 +++---
 doc/users-guide/users-guide.adoc   | 147 +++--
 3 files changed, 165 insertions(+), 28 deletions(-)

-- 
2.5.0

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

[lng-odp] [PATCHv2 2/4] doc: user-guide: shmem

[Christophe Milard]

section regarding shared memo added.

Signed-off-by: Christophe Milard 
Reviewed-and-tested-by: Bill Fischofer 
---
 doc/users-guide/users-guide.adoc | 129 +++
 1 file changed, 129 insertions(+)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index bbb53a7..d0eb7bc 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -543,6 +543,135 @@ lookup. The lookup function is particularly useful to 
allow an ODP application
 that is divided into multiple processes to obtain the handle for the common
 resource.
 
+== Shared memory
+=== Allocating shared memory
+Blocks of shared memory can be created using the +odp_shm_reserve()+ API
+call. The call expects a shared memory block name, a block size, an alignment
+requirement, and optional flags as parameters. It returns a +odp_shm_t+
+handle. The size and alignment requirement are given in bytes.
+
+.creating a block of shared memory
+[source,c]
+
+#define ALIGNMENT 128
+#define BLKNAME +shared_items+
+
+odp_shm_t shm;
+
+typedef struct {
+...
+} shared_data_t;
+
+shm = odp_shm_reserve(BLKNAME, sizeof(shared_data_t), ALIGNMENT, 0);
+
+
+=== Getting the shared memory block address
+The returned odp_shm_t handle can then be used to retrieve the actual
+address (in the caller's ODP thread virtual address space) of the created
+shared memory block.
+
+.getting the address of a shared memory block
+[source,c]
+
+shared_data_t *shared_data;
+shared_data = odp_shm_addr(shm);
+
+
+The address returned by +odp_shm_addr()+ is valid only in the calling ODP
+thread space: odp_shm_t handles can be shared between ODP threads and remain
+valid within any threads, whereas the address returned by +odp_shm_addr(shm)+
+may differ from ODP threads to ODP threads (for the same 'shm' block), and
+should therefore not be shared between ODP threads.
+For instance, it would be correct to send a shm handle using IPC between two
+ODP threads and let each of these thread do their own +odp_shm_addr()+ to
+get the block address. Directly sending the address returned by
++odp_shm_addr()+ from one ODP thread to another would however possibly fail
+(the address may have no sense in the receiver address space).
+
+The address returned by +odp_shm_addr()+ is nevertheless guaranteed to be
+aligned according to the alignment requirements provided at block creation
+time, even if the call to +odp_shm_addr()+ is performed by a different ODP
+thread than the one which originally called +odp_shm_reserve()+.
+
+All shared memory blocks are contiguous in any ODP thread addressing space:
+'address' to 'address'\+'size' (where 'size' is the shared memory block size,
+as provided in the +odp_shm_reserve()+ call) is read and writeable and
+mapping the shared memory block. There is no fragmentation.
+
+=== Memory behaviour
+By default ODP threads are assumed to behave as cache coherent systems:
+Any change performed on a shared memory block is guaranteed to eventually
+become visible to other ODP threads sharing this memory block.
+(this behaviour may be altered by flags to +odp_shm_reserve()+ in the future).
+Nevertheless, there is no implicit memory barrier associated with any action
+on shared memories: *When* a change performed by an ODP thread becomes visible
+to another ODP thread is not known: An application using shared memory
+blocks has to use some memory barrier provided by ODP to guarantee shared data
+validity between ODP threads.
+
+=== Lookup by name
+As mentioned, shared memory handles can be sent from ODP threads to ODP
+threads using any IPC mechanism, and then the block address retrieved.
+A simpler approach to get the shared memory block handle of an already created
+block is to use the +odp_shm_lookup()+ API function call.
+This nevertheless requires the calling ODP thread to provide the name of the
+shared memory block:
++odp_shm_lookup()+ will return +ODP_SHM_INVALID+ if no shared memory block
+with the provided name is known by ODP.
+
+.retrieving a block handle and address from another ODP task
+[source,c]
+
+#define BLKNAME 'shared_items'
+
+odp_shm_t shm;
+shared_data_t *shared_data;
+
+shm = odp_shm_lookup(BLKNAME);
+if (shm != ODP_SHM_INVALID) {
+   shared_data = odp_shm_addr(shm);
+   ...
+}
+
+
+=== Freeing memory
+Freeing shared memory is performed using the +odp_shm_free()+ API call.
++odp_shm_free()+ takes one single argument, the shared memory block handle.
+Any ODP thread is allowed to perform a +odp_shm_free()+ on a shared memory
+block (i.e. the thread performing the +odp_shm_free()+ may be different
+from the thread which did the +odp_shm_reserve()+). Shared memory blocks should
+be freed only once, and once freed, a shared memory block should no longer
+be referenced by any ODP threads.
+
+.freeing a shared memory block
+[source,c]
+
+if (odp_shm_free(shm) != 0) {
+   ...//handle error
+}
+
+
+=== Memory creation flags
+The last a

[lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

[Christophe Milard]

Signed-off-by: Christophe Milard 
Reviewed-and-tested-by: Bill Fischofer 
---
 doc/glossary.adoc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/glossary.adoc b/doc/glossary.adoc
index 8e514ee..becaf16 100644
--- a/doc/glossary.adoc
+++ b/doc/glossary.adoc
@@ -9,9 +9,17 @@ control thread::
 A control thread is a type of ODP thread. It will be isolated from the host
 operating system house keeping tasks but will be scheduled by it and may
 receive interrupts.
+ODP instantiation process::
+The first process which is started when an ODP application is started.
+There is one single such process per ODP instantiation.
 thread::
-An ODP thread is a flow of execution that in a Linux environment could be
-a Linux process or thread.
+the word thread (without any further specification) refers to an ODP
+thread.
+ODP thread::
+An ODP thread is a flow of execution that belongs to ODP. In a Linux
+environment an ODP thread can be either a Linux process or a linux thread.
+In both cases, a linux process (or thread) is said to be an ODP thread if
+its PID is a descendant of the ODP instantiation process.
 event::
 An event is a notification that can be placed in a queue.
 queue::
-- 
2.5.0

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

[lng-odp] [PATCHv2 3/4] doc: user-guide: fixing other typos

[Christophe Milard]

Signed-off-by: Christophe Milard 
Reviewed-and-tested-by: Bill Fischofer 
---
 doc/users-guide/users-guide.adoc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index d0eb7bc..fd017bb 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -693,8 +693,8 @@ odp_event_t ev = odp_queue_deq(poll_q1);
 int rc = odp_queue_enq(poll_q2, ev);
 
 
-The key distinction is that dequeueing events from POLL queues is an
-application responsibility while dequeueing events from SCHED queues is the
+The key distinction is that dequeuing events from POLL queues is an
+application responsibility while dequeuing events from SCHED queues is the
 responsibility of the ODP scheduler.
 
 .Operations on SCHED queues
@@ -720,7 +720,7 @@ while (1) {
 }
 
 
-With scheduled queues, events are sent to a queue, and the the sender chooses
+With scheduled queues, events are sent to a queue, and the sender chooses
 a queue based on the service it needs. The sender does not need to know
 which ODP thread (on which core) or hardware accelerator will process
 the event, but all the events on a queue are eventually scheduled and 
processed.
@@ -803,7 +803,7 @@ atomic queues may impair scaling.
 
 === Ordered Queues
 Ordered queues provide the best of both worlds by providing the inherent
-scaleabilty of parallel queues, with the easy synchronization of atomic
+scalability of parallel queues, with the easy synchronization of atomic
 queues.
 
 .Ordered Queue Scheduling
-- 
2.5.0

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

[lng-odp] [PATCHv2 4/4] doc: removing invalid characters

[Christophe Milard]

linux "tree" command output contains non printable character 160 which
made its way into the asciidoc. Removed and replaced by space here.

Signed-off-by: Christophe Milard 
Reviewed-and-tested-by: Bill Fischofer 
---
 doc/implementers-guide/implementers-guide.adoc | 34 +-
 doc/users-guide/users-guide.adoc   | 10 
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/doc/implementers-guide/implementers-guide.adoc 
b/doc/implementers-guide/implementers-guide.adoc
index d68354d..7ec2208 100644
--- a/doc/implementers-guide/implementers-guide.adoc
+++ b/doc/implementers-guide/implementers-guide.adoc
@@ -22,25 +22,25 @@ tree, but leave the actual definitions to be defined by the 
specific platform.
 
 ./
 ├── include/
-│   ├── odp/
-│   │   └── api/ <1>
-│   │   └── The Public API and the documentation.
-│   │
-│   └── odp.h <4>  This file should be the only file included by the 
application.
+│   ├── odp/
+│   │   └── api/ <1>
+│   │   └── The Public API and the documentation.
+│   │
+│   └── odp.h <4>  This file should be the only file included by the 
application.
 │
 ├── platform/
-│   ├── /
-│   │   ├── include/
-│   │   │   ├── odp/ <2>
-│   │   │   │   ├── In-line function definitions of the public API for this
-│   │   │   │   │   platform seen by the application.
-│   │   │   │   │
-│   │   │   │   └── plat/ <3>
-│   │   │   │       └── Platform specific types, enums etc as seen by the
-│   │   │   │   application but require overriding by the
-│   │   │   │   implementation.
-│   │   │   │  
-│   │   │   └── Internal header files seen only by the implementation.
+│   ├── /
+│   │   ├── include/
+│   │   │   ├── odp/ <2>
+│   │   │   │   ├── In-line function definitions of the public API for this
+│   │   │   │   │   platform seen by the application.
+│   │   │   │   │
+│   │   │   │   └── plat/ <3>
+│   │   │   │   └── Platform specific types, enums etc as seen by the
+│   │   │   │   application but require overriding by the
+│   │   │   │   implementation.
+│   │   │   │  
+│   │   │   └── Internal header files seen only by the implementation.
 
 
 <1> The doxygen description of the API definition is held in the public api 
file
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index fd017bb..09e5950 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -475,11 +475,11 @@ visible to the application.
 
 ./
 ├── include/
-│   ├── odp/
-│   │   └── api/
-│   │   └── The Public API and the documentation.
-│   │
-│   └── odp.h   This file should be the only file included by the application.
+│   ├── odp/
+│   │   └── api/
+│   │   └── The Public API and the documentation.
+│   │
+│   └── odp.h   This file should be the only file included by the application.
 
 
 === Initialization
-- 
2.5.0

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

Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to enable and disable ipc pktio

[Elo, Matias (Nokia - FI/Espoo)]

Comments below.

-Matias

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Maxim
> Uvarov
> Sent: Wednesday, February 17, 2016 9:43 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to
> enable and disable ipc pktio
> 
> With more options to enable/disable features it's more easy to isolate
> and debug problem if any. For now I have suspitious that in CI make check
> runs in parallel with other make checks which share the same pool memory.
> I.e. one process can corrupt memory for other process. Moving IPC to option
> it will be easy to debug that.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  configure.ac|  3 ++-
>  platform/linux-generic/m4/configure.m4  |  1 +
>  platform/linux-generic/m4/odp_ipc.m4| 29
> +
>  platform/linux-generic/odp_pool.c   |  4 
>  platform/linux-generic/pktio/io_ops.c   |  2 ++
>  platform/linux-generic/test/Makefile.am |  7 +--
>  6 files changed, 43 insertions(+), 3 deletions(-)
>  create mode 100644 platform/linux-generic/m4/odp_ipc.m4
> 
> diff --git a/configure.ac b/configure.ac
> index 257f8c3..200d565 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -85,6 +85,7 @@ AC_SUBST([platform_with_platform_test],
> ["platform/${with_platform}/test"])
>  # Prepare default values for platform specific optional features
> 
> ##
> 
>  netmap_support=no
> +pktio_ipc_support=no
> 
> 
> ##
> 
>  # Run platform specific checks and settings
> @@ -102,7 +103,7 @@ fi
> 
> ##
> 
>  AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
>  AM_CONDITIONAL([HAVE_PCAP], [test $have_pcap = yes])
> -
> +AM_CONDITIONAL([pktio_ipc_support], [test $pktio_ipc_support = yes])
> 
>  AC_ARG_WITH([sdk-install-path],
>  AC_HELP_STRING([--with-sdk-install-path=DIR path to external libs and
> headers],
> diff --git a/platform/linux-generic/m4/configure.m4 b/platform/linux-
> generic/m4/configure.m4
> index 2ac4799..b8c1c52 100644
> --- a/platform/linux-generic/m4/configure.m4
> +++ b/platform/linux-generic/m4/configure.m4
> @@ -21,6 +21,7 @@ m4_include([platform/linux-generic/m4/odp_openssl.m4])
>  m4_include([platform/linux-generic/m4/odp_netmap.m4])
>  m4_include([platform/linux-generic/m4/odp_dpdk.m4])
>  m4_include([platform/linux-generic/m4/odp_pcap.m4])
> +m4_include([platform/linux-generic/m4/odp_ipc.m4])
> 
>  AC_CONFIG_FILES([platform/linux-generic/Makefile
>platform/linux-generic/test/Makefile
> diff --git a/platform/linux-generic/m4/odp_ipc.m4 b/platform/linux-
> generic/m4/odp_ipc.m4
> new file mode 100644
> index 000..30f869d
> --- /dev/null
> +++ b/platform/linux-generic/m4/odp_ipc.m4
> @@ -0,0 +1,29 @@
> +#
> #
> +# Enable IPC pktio support
> +#
> #
> +AC_ARG_ENABLE([pktio_ipc_support],
> +[  --enable-pktio_ipc-support  include ipc IO support],
> +[if test x$enableval = xyes; then
> + pktio_ipc_support=yes
> +fi])
> +
> +#
> #
> +# Save and set temporary compilation flags
> +#
> #
> +OLD_CPPFLAGS=$CPPFLAGS
> +CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"

Is this required as no flags are actually modified?

> +
> +#
> #
> +# Check for IPC pktio availability

Nothing is actually checked here.

> +#
> #
> +if test x$pktio_ipc_support = xyes
> +then
> +ODP_CFLAGS="$ODP_CFLAGS -DODP_PKTIO_IPC"
> +else
> +pktio_ipc_support=no
> +fi

No need for else statement. Could this be done in AC_ARG_ENABLE?

> +
> +#
> #
> +# Restore old saved variables
> +#
> #
> +CPPFLAGS=$OLD_CPPFLAGS

Same thing as above.

> diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
> generic/odp_pool.c
> index 78ccc0f..9eaa0c8 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -421,7 +421,11 @@ odp_pool_t _pool_create(const char *name,
>  odp_pool_t odp_pool_create(const char *name,
>  odp_pool_param_t *params)
>  {
> +#ifdef ODP_PKTIO_IPC
>   return _pool_create(name, params, ODP_SHM_PROC);
> +#else
> + return _pool_create(name, params, 0);
> +#endif
>  }
> 
>  odp_pool_t odp_pool_lookup(const char *name)
> diff --git a/platform/linux-g

Re: [lng-odp] crypto contexts

[Gábor Sándor Enyedi]

OK, so back to the original question: I have up to ~100K users (but 
always higher than 32 by orders of magnitude) all with its own crypto 
key. In worst case, all of them are sending packets at the same time, so 
I need to decrypt a lot of packets from other users, before I face a 
packet from the same user again, so I cannot have 'n' different 
sessions. Since I cannot change the crypto key, the only way to do this 
is creating and destroying a session per packet. I looked into the x86 
code, and it seemed that the code was intentionally written in a way 
that session create/destroy is relatively quick, since there is no 
malloc and free and crypto contexts are not destroyed at all.


I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that creating/destroying 
crypto session is fast, i.e. I can expect that this is a cheap operation 
on each platform.
2. This is just a bug in API, and should be fixed by adding some way to 
change the crypto key.
3. There is already some solution, which I don't know... E.g. the 
cipher_key.data field in the session is just a pointer, one possibility 
is changing the memory content at the address where it points to. :)


Please confirm that #1 is the correct answer.

Gabor


On 02/17/2016 05:56 PM, Bala Manoharan wrote:

Hi,

Crypto key in crypto session cannot be changed and in this case you 
need 'n' different crypto sessions only and it cannot be reused.


Regards,
Bala

On 17 February 2016 at 21:11, Gábor Sándor Enyedi 
> wrote:


How can you change the crypto key? Each user has its own.

Gabor


On 02/17/2016 12:13 PM, Bala Manoharan wrote:

Hi,

There is no need to create a crypto session for each packet. The
application needs to create a crypto session for a unique
cipher/auth key (ie all the parameters in
odp_crypto_session_params_t ).
A crypto session is created so that application can create a
crypto session and reuse it for packets which need similar
processing.  The parameters of crypto session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text; /**< Authenticate/cipher
ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs
async */
odp_cipher_alg_t cipher_alg; /**< Cipher algorithm */
odp_crypto_key_t cipher_key; /**< Cipher key */
odp_crypto_iv_t  iv; /**< Cipher Initialization
Vector (IV) */
odp_auth_alg_t auth_alg; /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue; /**< Async mode completion
event queue */
odp_pool_t output_pool;/**< Output buffer pool */
} odp_crypto_session_params_t

If you see the odp_crypto_operation() function it reuses an
existing crypto session and only provides parameters which are
unique per packet (ie cipher/auth range, input packet, etc )

The limit of 32 crypto sessions is a limitation on the
linux-generic implementation and this value might depend on
individual platforms.

Regards,
Bala

On 16 February 2016 at 18:40, Gábor Sándor Enyedi
mailto:gabor.sandor.eny...@ericsson.com>> wrote:

Hi,

I want to keep up IPSec connections with up to ~100K users
simultaneously. After looking into the code, it seems that
both linux-generic and odp-dpdk can allocate at most 32
crypto sessions (with odp_crypto_session_create). Please
confirm, that this is not a bug, but crypto sessions are
considered to be a very limited resource and an ODP
application should create and destroy a crypto session for
each packet, when all the users are sending traffic at the
same time.
Thanks,

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







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

Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Christophe Milard
> Sent: Thursday, February 18, 2016 10:07 AM
> To: mike.hol...@linaro.org; bill.fischo...@linaro.org
> Cc: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more
> precisely
> 
> Signed-off-by: Christophe Milard 
> Reviewed-and-tested-by: Bill Fischofer 
> ---
>  doc/glossary.adoc | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/glossary.adoc b/doc/glossary.adoc
> index 8e514ee..becaf16 100644
> --- a/doc/glossary.adoc
> +++ b/doc/glossary.adoc
> @@ -9,9 +9,17 @@ control thread::
>  A control thread is a type of ODP thread. It will be isolated from
> the host
>  operating system house keeping tasks but will be scheduled by it and
> may
>  receive interrupts.
> +ODP instantiation process::
> +The first process which is started when an ODP application is
> started.
> +There is one single such process per ODP instantiation.


This is the one that called odp_init_global(). There can be only one global 
init per instance.


>  thread::
> -An ODP thread is a flow of execution that in a Linux environment
> could be
> -a Linux process or thread.
> +the word thread (without any further specification) refers to an ODP
> +thread.
> +ODP thread::
> +An ODP thread is a flow of execution that belongs to ODP. In a Linux
> +environment an ODP thread can be either a Linux process or a linux
> thread.
> +In both cases, a linux process (or thread) is said to be an ODP
> thread if
> +its PID is a descendant of the ODP instantiation process.


An implementation could also support other than child processes joining an 
instance, so this definition is too narrow. We'll need to add an ODP instance 
ID param into local init, but other than that, its implementation specific how 
ODP threads join an ODP instance (not always parent -> child connection). Also, 
can the instantiation process exit ODP? On some implementation it could and the 
instance terminates when the last ODP thread exits it.


So in general terms ODP thread in Linux: any pthread or process that is running 
as part of an ODP instance (have called odp_init_local()). 


-Petri

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

Re: [lng-odp] [PATCHv2 2/4] doc: user-guide: shmem

[Maxim Uvarov]

On 02/18/16 11:06, Christophe Milard wrote:

section regarding shared memo added.

Signed-off-by: Christophe Milard 
Reviewed-and-tested-by: Bill Fischofer 
---
  doc/users-guide/users-guide.adoc | 129 +++
  1 file changed, 129 insertions(+)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index bbb53a7..d0eb7bc 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -543,6 +543,135 @@ lookup. The lookup function is particularly useful to 
allow an ODP application
  that is divided into multiple processes to obtain the handle for the common
  resource.
  
+== Shared memory

+=== Allocating shared memory
+Blocks of shared memory can be created using the +odp_shm_reserve()+ API
+call. The call expects a shared memory block name, a block size, an alignment
+requirement, and optional flags as parameters. It returns a +odp_shm_t+
+handle. The size and alignment requirement are given in bytes.
+
+.creating a block of shared memory
+[source,c]
+
+#define ALIGNMENT 128
+#define BLKNAME +shared_items+


"shared_items"?

do you need this define at all? I think that is also understandable:

shm = odp_shm_reserve("shm name", sizeof(shared_data_t), ALIGNMENT, 0);

but the last argument I think it's better to write as flags. I.e.:

uint32_t shm_flags = 0;

shm = odp_shm_reserve("shm name", sizeof(shared_data_t), ALIGNMENT, shm_flags);




+
+odp_shm_t shm;
+
+typedef struct {
+...
+} shared_data_t;
+
+shm = odp_shm_reserve(BLKNAME, sizeof(shared_data_t), ALIGNMENT, 0);
+
+
+=== Getting the shared memory block address
+The returned odp_shm_t handle can then be used to retrieve the actual
+address (in the caller's ODP thread virtual address space) of the created
+shared memory block.
+
+.getting the address of a shared memory block
+[source,c]
+
+shared_data_t *shared_data;
+shared_data = odp_shm_addr(shm);
+
+
+The address returned by +odp_shm_addr()+ is valid only in the calling ODP
+thread space: odp_shm_t handles can be shared between ODP threads and remain
+valid within any threads, whereas the address returned by +odp_shm_addr(shm)+
+may differ from ODP threads to ODP threads (for the same 'shm' block), and
+should therefore not be shared between ODP threads.
+For instance, it would be correct to send a shm handle using IPC between two
+ODP threads and let each of these thread do their own +odp_shm_addr()+ to
+get the block address. Directly sending the address returned by
++odp_shm_addr()+ from one ODP thread to another would however possibly fail
+(the address may have no sense in the receiver address space).
+
+The address returned by +odp_shm_addr()+ is nevertheless guaranteed to be
+aligned according to the alignment requirements provided at block creation
+time, even if the call to +odp_shm_addr()+ is performed by a different ODP
+thread than the one which originally called +odp_shm_reserve()+.
+
+All shared memory blocks are contiguous in any ODP thread addressing space:
+'address' to 'address'\+'size' (where 'size' is the shared memory block size,
+as provided in the +odp_shm_reserve()+ call) is read and writeable and
+mapping the shared memory block. There is no fragmentation.
+
+=== Memory behaviour
+By default ODP threads are assumed to behave as cache coherent systems:
+Any change performed on a shared memory block is guaranteed to eventually
+become visible to other ODP threads sharing this memory block.
+(this behaviour may be altered by flags to +odp_shm_reserve()+ in the future).
+Nevertheless, there is no implicit memory barrier associated with any action
+on shared memories: *When* a change performed by an ODP thread becomes visible
+to another ODP thread is not known: An application using shared memory
+blocks has to use some memory barrier provided by ODP to guarantee shared data
+validity between ODP threads.
+
+=== Lookup by name
+As mentioned, shared memory handles can be sent from ODP threads to ODP
+threads using any IPC mechanism, and then the block address retrieved.
+A simpler approach to get the shared memory block handle of an already created
+block is to use the +odp_shm_lookup()+ API function call.
+This nevertheless requires the calling ODP thread to provide the name of the
+shared memory block:
++odp_shm_lookup()+ will return +ODP_SHM_INVALID+ if no shared memory block
+with the provided name is known by ODP.
+
+.retrieving a block handle and address from another ODP task
+[source,c]
+
+#define BLKNAME 'shared_items'
+
+odp_shm_t shm;
+shared_data_t *shared_data;
+
+shm = odp_shm_lookup(BLKNAME);
+if (shm != ODP_SHM_INVALID) {
+   shared_data = odp_shm_addr(shm);
+   ...
+}
+
+
+=== Freeing memory
+Freeing shared memory is performed using the +odp_shm_free()+ API call.
++odp_shm_free()+ takes one single argument, the shared memory block handle.
+Any ODP thread is allowed to perform a +odp_shm_free()+ on a shared memory
+block (i.e. the thread performi

Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

[Christophe Milard]

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

>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Christophe Milard
> > Sent: Thursday, February 18, 2016 10:07 AM
> > To: mike.hol...@linaro.org; bill.fischo...@linaro.org
> > Cc: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more
> > precisely
> >
> > Signed-off-by: Christophe Milard 
> > Reviewed-and-tested-by: Bill Fischofer 
> > ---
> >  doc/glossary.adoc | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/glossary.adoc b/doc/glossary.adoc
> > index 8e514ee..becaf16 100644
> > --- a/doc/glossary.adoc
> > +++ b/doc/glossary.adoc
> > @@ -9,9 +9,17 @@ control thread::
> >  A control thread is a type of ODP thread. It will be isolated from
> > the host
> >  operating system house keeping tasks but will be scheduled by it and
> > may
> >  receive interrupts.
> > +ODP instantiation process::
> > +The first process which is started when an ODP application is
> > started.
> > +There is one single such process per ODP instantiation.
>
>
> This is the one that called odp_init_global(). There can be only one
> global init per instance.
>
>
> >  thread::
> > -An ODP thread is a flow of execution that in a Linux environment
> > could be
> > -a Linux process or thread.
> > +the word thread (without any further specification) refers to an ODP
> > +thread.
> > +ODP thread::
> > +An ODP thread is a flow of execution that belongs to ODP. In a Linux
> > +environment an ODP thread can be either a Linux process or a linux
> > thread.
> > +In both cases, a linux process (or thread) is said to be an ODP
> > thread if
> > +its PID is a descendant of the ODP instantiation process.
>
>
> An implementation could also support other than child processes joining an
> instance, so this definition is too narrow. We'll need to add an ODP
> instance ID param into local init, but other than that, its implementation
> specific how ODP threads join an ODP instance (not always parent -> child
> connection). Also, can the instantiation process exit ODP? On some
> implementation it could and the instance terminates when the last ODP
> thread exits it.
>
>
> So in general terms ODP thread in Linux: any pthread or process that is
> running as part of an ODP instance (have called odp_init_local()).
>

Thanks for your comments, Petri:
I understand your point, I was no really sure my definition was the best,
but is was the best Gary and me could find.
Now, you say : " So in general terms ODP thread in Linux: any pthread or
process that is running as part of an ODP instance (have called
odp_init_local())."
Why do you limit that definition to linux?

Can we simply write that the instantiation thread is the one calling
ODP_init_global and ODP threads are those calling ODP_init_local. On any
implementation? If not what is the definition of an ODP thread?
(independentely of the ODP implemetation)

Christophe

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

Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to enable and disable ipc pktio

[Maxim Uvarov]

Hello Matias,

thanks for comments will send v4.

During update I thinge we can not use ODP_ prefix here:
+#ifdef ODP_PKTIO_IPC
&ipc_pktio_ops,
+#endif

as well as in:

+#ifdef ODP_PKTIO_DPDK

+#endif

Because it might be confusing other people thinking that it's related to 
some odp API.


Let's use simple PKTIO_IPC, PKTIO_DPDK, PKTIO_NETMAP and etc. Agree?

Maxim.



On 02/18/16 11:26, Elo, Matias (Nokia - FI/Espoo) wrote:

Comments below.

-Matias


-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Maxim
Uvarov
Sent: Wednesday, February 17, 2016 9:43 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to
enable and disable ipc pktio

With more options to enable/disable features it's more easy to isolate
and debug problem if any. For now I have suspitious that in CI make check
runs in parallel with other make checks which share the same pool memory.
I.e. one process can corrupt memory for other process. Moving IPC to option
it will be easy to debug that.

Signed-off-by: Maxim Uvarov 
---
  configure.ac|  3 ++-
  platform/linux-generic/m4/configure.m4  |  1 +
  platform/linux-generic/m4/odp_ipc.m4| 29
+
  platform/linux-generic/odp_pool.c   |  4 
  platform/linux-generic/pktio/io_ops.c   |  2 ++
  platform/linux-generic/test/Makefile.am |  7 +--
  6 files changed, 43 insertions(+), 3 deletions(-)
  create mode 100644 platform/linux-generic/m4/odp_ipc.m4

diff --git a/configure.ac b/configure.ac
index 257f8c3..200d565 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ AC_SUBST([platform_with_platform_test],
["platform/${with_platform}/test"])
  # Prepare default values for platform specific optional features

##

  netmap_support=no
+pktio_ipc_support=no


##

  # Run platform specific checks and settings
@@ -102,7 +103,7 @@ fi

##

  AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
  AM_CONDITIONAL([HAVE_PCAP], [test $have_pcap = yes])
-
+AM_CONDITIONAL([pktio_ipc_support], [test $pktio_ipc_support = yes])

  AC_ARG_WITH([sdk-install-path],
  AC_HELP_STRING([--with-sdk-install-path=DIR path to external libs and
headers],
diff --git a/platform/linux-generic/m4/configure.m4 b/platform/linux-
generic/m4/configure.m4
index 2ac4799..b8c1c52 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -21,6 +21,7 @@ m4_include([platform/linux-generic/m4/odp_openssl.m4])
  m4_include([platform/linux-generic/m4/odp_netmap.m4])
  m4_include([platform/linux-generic/m4/odp_dpdk.m4])
  m4_include([platform/linux-generic/m4/odp_pcap.m4])
+m4_include([platform/linux-generic/m4/odp_ipc.m4])

  AC_CONFIG_FILES([platform/linux-generic/Makefile
 platform/linux-generic/test/Makefile
diff --git a/platform/linux-generic/m4/odp_ipc.m4 b/platform/linux-
generic/m4/odp_ipc.m4
new file mode 100644
index 000..30f869d
--- /dev/null
+++ b/platform/linux-generic/m4/odp_ipc.m4
@@ -0,0 +1,29 @@
+#
#
+# Enable IPC pktio support
+#
#
+AC_ARG_ENABLE([pktio_ipc_support],
+[  --enable-pktio_ipc-support  include ipc IO support],
+[if test x$enableval = xyes; then
+   pktio_ipc_support=yes
+fi])
+
+#
#
+# Save and set temporary compilation flags
+#
#
+OLD_CPPFLAGS=$CPPFLAGS
+CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"

Is this required as no flags are actually modified?


+
+#
#
+# Check for IPC pktio availability

Nothing is actually checked here.


+#
#
+if test x$pktio_ipc_support = xyes
+then
+ODP_CFLAGS="$ODP_CFLAGS -DODP_PKTIO_IPC"
+else
+pktio_ipc_support=no
+fi

No need for else statement. Could this be done in AC_ARG_ENABLE?


+
+#
#
+# Restore old saved variables
+#
#
+CPPFLAGS=$OLD_CPPFLAGS

Same thing as above.


diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
generic/odp_pool.c
index 78ccc0f..9eaa0c8 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -421,7 +421,11 @@ odp_pool_t _pool_create(const char *name,
  odp_pool_t odp_pool_create(const char *name,
   odp_pool_param_t *para

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Bill Fischofer
> Sent: Wednesday, February 17, 2016 9:37 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add
> odp_crypto_capability() api
> 
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/spec/crypto.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index 41beedb..eaacff1 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
>  } odp_crypto_op_result_t;
> 
>  /**
> + * Crypto capabilities
> + */
> +typedef struct odp_crypto_capability_t {
> + /** Maximum number of sessions */
> + unsigned max_sessions;
> +} odp_crypto_capability_t;
> +
> +/**
> + * Get crypto capabilities
> + *
> + * @param[out] capability Pointer to capability structrue for output

Typo: structure

Otherwise OK.

Reviewed-by: Petri Savolainen 

-Petri


> + *
> + * @retval 0 on success
> + * @retval <0 on failure
> + */
> +int odp_crypto_capability(odp_crypto_capability_t *capability);
> +
> +/**
>   * Crypto session creation (synchronous)
>   *
>   * @param paramsSession parameters
> --
> 2.5.0
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

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

From: EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
Sent: Thursday, February 18, 2016 10:40 AM
To: Savolainen, Petri (Nokia - FI/Espoo) 
Cc: mike.hol...@linaro.org; bill.fischo...@linaro.org; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more 
precisely



On 18 February 2016 at 09:27, Savolainen, Petri (Nokia - FI/Espoo) 
mailto:petri.savolai...@nokia.com>> wrote:


> -Original Message-
> From: lng-odp 
> [mailto:lng-odp-boun...@lists.linaro.org]
>  On Behalf Of EXT
> Christophe Milard
> Sent: Thursday, February 18, 2016 10:07 AM
> To: mike.hol...@linaro.org; 
> bill.fischo...@linaro.org
> Cc: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more
> precisely
>
> Signed-off-by: Christophe Milard 
> mailto:christophe.mil...@linaro.org>>
> Reviewed-and-tested-by: Bill Fischofer 
> mailto:bill.fischo...@linaro.org>>
> ---
>  doc/glossary.adoc | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/doc/glossary.adoc b/doc/glossary.adoc
> index 8e514ee..becaf16 100644
> --- a/doc/glossary.adoc
> +++ b/doc/glossary.adoc
> @@ -9,9 +9,17 @@ control thread::
>  A control thread is a type of ODP thread. It will be isolated from
> the host
>  operating system house keeping tasks but will be scheduled by it and
> may
>  receive interrupts.
> +ODP instantiation process::
> +The first process which is started when an ODP application is
> started.
> +There is one single such process per ODP instantiation.

This is the one that called odp_init_global(). There can be only one global 
init per instance.


>  thread::
> -An ODP thread is a flow of execution that in a Linux environment
> could be
> -a Linux process or thread.
> +the word thread (without any further specification) refers to an ODP
> +thread.
> +ODP thread::
> +An ODP thread is a flow of execution that belongs to ODP. In a Linux
> +environment an ODP thread can be either a Linux process or a linux
> thread.
> +In both cases, a linux process (or thread) is said to be an ODP
> thread if
> +its PID is a descendant of the ODP instantiation process.


An implementation could also support other than child processes joining an 
instance, so this definition is too narrow. We'll need to add an ODP instance 
ID param into local init, but other than that, its implementation specific how 
ODP threads join an ODP instance (not always parent -> child connection). Also, 
can the instantiation process exit ODP? On some implementation it could and the 
instance terminates when the last ODP thread exits it.


So in general terms ODP thread in Linux: any pthread or process that is running 
as part of an ODP instance (have called odp_init_local()).

Thanks for your comments, Petri:
I understand your point, I was no really sure my definition was the best, but 
is was the best Gary and me could find.
Now, you say : " So in general terms ODP thread in Linux: any pthread or 
process that is running as part of an ODP instance (have called 
odp_init_local())."
Why do you limit that definition to linux?

Can we simply write that the instantiation thread is the one calling 
ODP_init_global and ODP threads are those calling ODP_init_local. On any 
implementation? If not what is the definition of an ODP thread? (independentely 
of the ODP implemetation)

Yes, that’s basically the definition. A call to init_global creates an instance 
and a call to init_local joins the calling thread into that instance.

Linux is so common platform that it’s good to use that as an example and 
explicitly state that both pthreads and processes can be “ODP threads”.

-Petri



Christophe


-Petri

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

Re: [lng-odp] [PATCH API-NEXTv2] doc: user-guide documentation for classification

[Christophe Milard]

On 18 February 2016 at 08:54, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:

> Adds user-guide documentation for classification module
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
> v2: Incorporates review comments from Christophe
>
>  doc/users-guide/users-guide-cls.adoc | 220
> +++
>  1 file changed, 220 insertions(+)
>  create mode 100644 doc/users-guide/users-guide-cls.adoc
>
> diff --git a/doc/users-guide/users-guide-cls.adoc
> b/doc/users-guide/users-guide-cls.adoc
> new file mode 100644
> index 000..74cdcaa
> --- /dev/null
> +++ b/doc/users-guide/users-guide-cls.adoc
> @@ -0,0 +1,220 @@
> +== Classification \(CLS)
>

I am not sure whether the backslash here is intentionnal or not. It shows
up in the final html doc.


> +
> +ODP is a framework for software-based packet forwarding/filtering
> applications,
> +and the purpose of the Packet Classification API is to enable
> applications to
> +program the platform hardware or software implementation to assist in
> +prioritization, classification and scheduling of each packet, so that the
> +software application can run faster, scale better and adhere to QoS
> +requirements.
> +
> +The following API abstraction are not modelled after any existing product
> +implementation, but is instead defined in terms of what a typical
> data-plane
> +application may require from such a platform, without sacrificing
> simplicity and
> +avoiding ambiguity. Certain terms that are being used within the context
> of
> +existing products in relation to packet parsing and classification, such
> as
> +access lists are avoided such that not to suggest any relationship
> +between the abstraction used within this API and any particular manner in
> which
> +they may be implemented in hardware.
> +
> +=== Functional Description
> +
> +Following is the functionality that is required of the classification
> API, and
> +its underlying implementation. The details and order of the following
> paragraph
> +is informative, and is only intended to help convey the functional scope
> of a
> +classifier and provide context for the API. In reality, implementations
> may
> +execute many of these steps concurrently, or in different order while
> +maintaining the evident dependencies:
> +
> +1. Apply a set of classification rules to the header of an incoming
> packet,
> +identify the header fields, e.g. ,ethertype, IP version, IP protocol,
> transport
> +layer port numbers, IP DiffServ, VLAN id, 802.1p priority.
> +
> +2. Store these fields as packet meta data for application use, and for the
> +remainder of parser operations. The odp_pktio is also stored as one of
> the meta
> +data fields for subsequent use.
> +
> +3. Compute an odp_cos (Class of Service) value from a subset of supported
> fields
> +from 1) above.
> +
> +4. Based on the odp_cos from 3) above, select the odp_queue through which
> the
> +packet is delivered to the application.
> +
> +5. Validate the packet data integrity (checksums, FCS)  and correctness
> (e.g.,
> +length fields) and store the validation result, along with optional error
> layer
> +and type indicator, in packet meta data. Optionally, if a packet fails
> +validation, override the odp_cos selection in step 3 to a class of service
> +designated for errored packets.
> +
> +6. Based on the odp_cos from 3) above, select the odp_buffer_pool that
> should be
> +used to acquire a buffer to store the packet data and meta data.
> +
> +7. Allocate a buffer from odp_buffer_pool selected in 6) above and
> logically[1]
> +store the packet data and meta data to the allocated buffer, or in
> accordance
> +with class-of-service drop policy and subject to pool buffer availability,
> +optionally discard the packet.
> +
> +8. Enqueue the buffer into the odp_queue selected in 4) above.
> +
> +The above is an abstract description of the classifier functionality, and
> may be
> +applied to a variety of applications in many different ways. The ultimate
> +meaning of how this functionality applies to an application also depends
> on
> +other ODP modules, so the above may not complete a full depiction. For
> instance,
> +the exact meaning of priority, which is a per-queue attribute is
> influenced by
> +the ODP scheduler semantics, and the system behavior under stress depends
> on the
> +ODP buffer pool module behavior.
> +
> +For the sole purpose of illustrating the above abstract functionality,
> here is
> +an example of a Layer-2 (IEEE 802.1D)  bridge application: Such a
> forwarding
> +application that also adheres to IEEE 802.1p/q priority, which has 8
> traffic
> +priority levels, might create 8 odp_buffer_pool instances, one for each
> PCP
> +priority level, and 8 odp_queue instances one per priority level. Incoming
> +packets will be inspected for a VLAN header; the PCP field will be
> extracted,
> +and used to select both the pool and the queue. Because each queue will be
> +assigned a priority value, the packets with hi

Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to enable and disable ipc pktio

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Maxim Uvarov
> Sent: Thursday, February 18, 2016 10:45 AM
> To: Elo, Matias (Nokia - FI/Espoo) ; lng-
> o...@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add
> option to enable and disable ipc pktio
> 
> Hello Matias,
> 
> thanks for comments will send v4.
> 
> During update I thinge we can not use ODP_ prefix here:
> +#ifdef ODP_PKTIO_IPC
>  &ipc_pktio_ops,
> +#endif
> 
> as well as in:
> 
> +#ifdef ODP_PKTIO_DPDK
>  
> +#endif
> 
> Because it might be confusing other people thinking that it's related to
> some odp API.
> 
> Let's use simple PKTIO_IPC, PKTIO_DPDK, PKTIO_NETMAP and etc. Agree?


I think it's better to prefix. Could use _ODP_PKTIO_IPC, ... so that it's 
clearly internal to the implementation.

-Petri

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

Re: [lng-odp] [PATCHv2 2/4] doc: user-guide: shmem

[Christophe Milard]

On 18 February 2016 at 09:29, Maxim Uvarov  wrote:

> On 02/18/16 11:06, Christophe Milard wrote:
>
>> section regarding shared memo added.
>>
>> Signed-off-by: Christophe Milard 
>> Reviewed-and-tested-by: Bill Fischofer 
>> ---
>>   doc/users-guide/users-guide.adoc | 129
>> +++
>>   1 file changed, 129 insertions(+)
>>
>> diff --git a/doc/users-guide/users-guide.adoc
>> b/doc/users-guide/users-guide.adoc
>> index bbb53a7..d0eb7bc 100644
>> --- a/doc/users-guide/users-guide.adoc
>> +++ b/doc/users-guide/users-guide.adoc
>> @@ -543,6 +543,135 @@ lookup. The lookup function is particularly useful
>> to allow an ODP application
>>   that is divided into multiple processes to obtain the handle for the
>> common
>>   resource.
>>   +== Shared memory
>> +=== Allocating shared memory
>> +Blocks of shared memory can be created using the +odp_shm_reserve()+ API
>> +call. The call expects a shared memory block name, a block size, an
>> alignment
>> +requirement, and optional flags as parameters. It returns a +odp_shm_t+
>> +handle. The size and alignment requirement are given in bytes.
>> +
>> +.creating a block of shared memory
>> +[source,c]
>> +
>> +#define ALIGNMENT 128
>> +#define BLKNAME +shared_items+
>>
>
> "shared_items"?
>
> do you need this define at all? I think that is also understandable:
>
> shm = odp_shm_reserve("shm name", sizeof(shared_data_t), ALIGNMENT, 0);
>

I don't agree as the same name is used in the odp_shm_lookup() later on.
Yes, the macro is redefined there as well (so that the example is
complete), but I do think it make sense to keep the macro when multiple
refs are done to the same string.


> but the last argument I think it's better to write as flags. I.e.:
>
> uint32_t shm_flags = 0;
>
> shm = odp_shm_reserve("shm name", sizeof(shared_data_t), ALIGNMENT,
> shm_flags);


You are right. will be in v3.

Christophe.

>
>
>
>
> +
>> +odp_shm_t shm;
>> +
>> +typedef struct {
>> +...
>> +} shared_data_t;
>> +
>> +shm = odp_shm_reserve(BLKNAME, sizeof(shared_data_t), ALIGNMENT, 0);
>> +
>> +
>> +=== Getting the shared memory block address
>> +The returned odp_shm_t handle can then be used to retrieve the actual
>> +address (in the caller's ODP thread virtual address space) of the created
>> +shared memory block.
>> +
>> +.getting the address of a shared memory block
>> +[source,c]
>> +
>> +shared_data_t *shared_data;
>> +shared_data = odp_shm_addr(shm);
>> +
>> +
>> +The address returned by +odp_shm_addr()+ is valid only in the calling ODP
>> +thread space: odp_shm_t handles can be shared between ODP threads and
>> remain
>> +valid within any threads, whereas the address returned by
>> +odp_shm_addr(shm)+
>> +may differ from ODP threads to ODP threads (for the same 'shm' block),
>> and
>> +should therefore not be shared between ODP threads.
>> +For instance, it would be correct to send a shm handle using IPC between
>> two
>> +ODP threads and let each of these thread do their own +odp_shm_addr()+ to
>> +get the block address. Directly sending the address returned by
>> ++odp_shm_addr()+ from one ODP thread to another would however possibly
>> fail
>> +(the address may have no sense in the receiver address space).
>> +
>> +The address returned by +odp_shm_addr()+ is nevertheless guaranteed to be
>> +aligned according to the alignment requirements provided at block
>> creation
>> +time, even if the call to +odp_shm_addr()+ is performed by a different
>> ODP
>> +thread than the one which originally called +odp_shm_reserve()+.
>> +
>> +All shared memory blocks are contiguous in any ODP thread addressing
>> space:
>> +'address' to 'address'\+'size' (where 'size' is the shared memory block
>> size,
>> +as provided in the +odp_shm_reserve()+ call) is read and writeable and
>> +mapping the shared memory block. There is no fragmentation.
>> +
>> +=== Memory behaviour
>> +By default ODP threads are assumed to behave as cache coherent systems:
>> +Any change performed on a shared memory block is guaranteed to eventually
>> +become visible to other ODP threads sharing this memory block.
>> +(this behaviour may be altered by flags to +odp_shm_reserve()+ in the
>> future).
>> +Nevertheless, there is no implicit memory barrier associated with any
>> action
>> +on shared memories: *When* a change performed by an ODP thread becomes
>> visible
>> +to another ODP thread is not known: An application using shared memory
>> +blocks has to use some memory barrier provided by ODP to guarantee
>> shared data
>> +validity between ODP threads.
>> +
>> +=== Lookup by name
>> +As mentioned, shared memory handles can be sent from ODP threads to ODP
>> +threads using any IPC mechanism, and then the block address retrieved.
>> +A simpler approach to get the shared memory block handle of an already
>> created
>> +block is to use the +odp_shm_lookup()+ API function call.
>> +This nevertheless requires the calling ODP thread to provide the name of
>> the
>> +shared memory 

[lng-odp] [QUESTION] test: validation:thread: some functions cannot be found

[Xu Zaibo]

Hi,
In my compiling test validation, some functions, such as 
'thread_test_odp_thrmask_and', ' thread_test_odp_thrmask_or' cannot be 
found and failed.
And I search these function in the home directory of ODP, but get nothing. So, 
is it the problem of 'validation/thread.c'?

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

Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

[Christophe Milard]

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

>
>
>
>
> *From:* EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
> *Sent:* Thursday, February 18, 2016 10:40 AM
> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
> *Cc:* mike.hol...@linaro.org; bill.fischo...@linaro.org;
> lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread
> more precisely
>
>
>
>
>
>
>
> On 18 February 2016 at 09:27, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Christophe Milard
> > Sent: Thursday, February 18, 2016 10:07 AM
> > To: mike.hol...@linaro.org; bill.fischo...@linaro.org
> > Cc: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more
> > precisely
> >
> > Signed-off-by: Christophe Milard 
> > Reviewed-and-tested-by: Bill Fischofer 
> > ---
> >  doc/glossary.adoc | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/glossary.adoc b/doc/glossary.adoc
> > index 8e514ee..becaf16 100644
> > --- a/doc/glossary.adoc
> > +++ b/doc/glossary.adoc
> > @@ -9,9 +9,17 @@ control thread::
> >  A control thread is a type of ODP thread. It will be isolated from
> > the host
> >  operating system house keeping tasks but will be scheduled by it and
> > may
> >  receive interrupts.
> > +ODP instantiation process::
> > +The first process which is started when an ODP application is
> > started.
> > +There is one single such process per ODP instantiation.
>
> This is the one that called odp_init_global(). There can be only one
> global init per instance.
>
>
> >  thread::
> > -An ODP thread is a flow of execution that in a Linux environment
> > could be
> > -a Linux process or thread.
> > +the word thread (without any further specification) refers to an ODP
> > +thread.
> > +ODP thread::
> > +An ODP thread is a flow of execution that belongs to ODP. In a Linux
> > +environment an ODP thread can be either a Linux process or a linux
> > thread.
> > +In both cases, a linux process (or thread) is said to be an ODP
> > thread if
> > +its PID is a descendant of the ODP instantiation process.
>
>
> An implementation could also support other than child processes joining an
> instance, so this definition is too narrow. We'll need to add an ODP
> instance ID param into local init, but other than that, its implementation
> specific how ODP threads join an ODP instance (not always parent -> child
> connection). Also, can the instantiation process exit ODP? On some
> implementation it could and the instance terminates when the last ODP
> thread exits it.
>
>
> So in general terms ODP thread in Linux: any pthread or process that is
> running as part of an ODP instance (have called odp_init_local()).
>
>
>
> Thanks for your comments, Petri:
>
> I understand your point, I was no really sure my definition was the best,
> but is was the best Gary and me could find.
>
> Now, you say : " So in general terms ODP thread in Linux: any pthread or
> process that is running as part of an ODP instance (have called
> odp_init_local())."
>
> Why do you limit that definition to linux?
>
>
>
> Can we simply write that the instantiation thread is the one calling
> ODP_init_global and ODP threads are those calling ODP_init_local. On any
> implementation? If not what is the definition of an ODP thread?
> (independentely of the ODP implemetation)
>
>
>
> Yes, that’s basically the definition. A call to init_global creates an
> instance and a call to init_local joins the calling thread into that
> instance.
>
>
>
> Linux is so common platform that it’s good to use that as an example and
> explicitly state that both pthreads and processes can be “ODP threads”.
>
>
>
> -Petri
>
>
>
>
>
>
>
> Christophe
>
>
>
> -Petri
>
>
>
 But can we ignore totally the notion of descendance in this definition?
you wrote: "An implementation could also support other than child processes
joining an instance, so this definition is too narrow.".
Now, if we have 2 (ore more) instances of ODP running in the same machine,
and a foreign process (also linked with ODP lib, I assume, but not child of
the instantiation process) calls odp_init_local()... What instance of ODP
does this process join?

Christophe.

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

Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more precisely

[Christophe Milard]

I am willing to put the following definitions:
ODP instantiation process::

The process calling +odp_init_global()+, which is probably the

first process which is started when an ODP application is started.

There is one single such process per ODP instantiation.

ODP thread::

An ODP thread is a flow of execution that belongs to ODP.

Any process or thread descendant of an ODP instantiation process and

calling +odp_init_local()+ becomes an ODP thread of that instance.

Note that, in a Linux environment an ODP thread can be either a Linux

process or a linux thread (i.e a linux process calling
+odp_init_local()+
will be refered as ODP thread, not ODP process).

If this is not correct... what should it be  :-)

Christophe.

On 18 February 2016 at 10:29, Christophe Milard <
christophe.mil...@linaro.org> wrote:

>
>
> On 18 February 2016 at 09:50, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>>
>>
>>
>>
>> *From:* EXT Christophe Milard [mailto:christophe.mil...@linaro.org]
>> *Sent:* Thursday, February 18, 2016 10:40 AM
>> *To:* Savolainen, Petri (Nokia - FI/Espoo) 
>> *Cc:* mike.hol...@linaro.org; bill.fischo...@linaro.org;
>> lng-odp@lists.linaro.org
>> *Subject:* Re: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP
>> thread more precisely
>>
>>
>>
>>
>>
>>
>>
>> On 18 February 2016 at 09:27, Savolainen, Petri (Nokia - FI/Espoo) <
>> petri.savolai...@nokia.com> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> EXT
>> > Christophe Milard
>> > Sent: Thursday, February 18, 2016 10:07 AM
>> > To: mike.hol...@linaro.org; bill.fischo...@linaro.org
>> > Cc: lng-odp@lists.linaro.org
>> > Subject: [lng-odp] [PATCHv2 1/4] doc: glossary: defining ODP thread more
>> > precisely
>> >
>> > Signed-off-by: Christophe Milard 
>> > Reviewed-and-tested-by: Bill Fischofer 
>> > ---
>> >  doc/glossary.adoc | 12 ++--
>> >  1 file changed, 10 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/doc/glossary.adoc b/doc/glossary.adoc
>> > index 8e514ee..becaf16 100644
>> > --- a/doc/glossary.adoc
>> > +++ b/doc/glossary.adoc
>> > @@ -9,9 +9,17 @@ control thread::
>> >  A control thread is a type of ODP thread. It will be isolated from
>> > the host
>> >  operating system house keeping tasks but will be scheduled by it
>> and
>> > may
>> >  receive interrupts.
>> > +ODP instantiation process::
>> > +The first process which is started when an ODP application is
>> > started.
>> > +There is one single such process per ODP instantiation.
>>
>> This is the one that called odp_init_global(). There can be only one
>> global init per instance.
>>
>>
>> >  thread::
>> > -An ODP thread is a flow of execution that in a Linux environment
>> > could be
>> > -a Linux process or thread.
>> > +the word thread (without any further specification) refers to an
>> ODP
>> > +thread.
>> > +ODP thread::
>> > +An ODP thread is a flow of execution that belongs to ODP. In a
>> Linux
>> > +environment an ODP thread can be either a Linux process or a linux
>> > thread.
>> > +In both cases, a linux process (or thread) is said to be an ODP
>> > thread if
>> > +its PID is a descendant of the ODP instantiation process.
>>
>>
>> An implementation could also support other than child processes joining
>> an instance, so this definition is too narrow. We'll need to add an ODP
>> instance ID param into local init, but other than that, its implementation
>> specific how ODP threads join an ODP instance (not always parent -> child
>> connection). Also, can the instantiation process exit ODP? On some
>> implementation it could and the instance terminates when the last ODP
>> thread exits it.
>>
>>
>> So in general terms ODP thread in Linux: any pthread or process that is
>> running as part of an ODP instance (have called odp_init_local()).
>>
>>
>>
>> Thanks for your comments, Petri:
>>
>> I understand your point, I was no really sure my definition was the best,
>> but is was the best Gary and me could find.
>>
>> Now, you say : " So in general terms ODP thread in Linux: any pthread or
>> process that is running as part of an ODP instance (have called
>> odp_init_local())."
>>
>> Why do you limit that definition to linux?
>>
>>
>>
>> Can we simply write that the instantiation thread is the one calling
>> ODP_init_global and ODP threads are those calling ODP_init_local. On any
>> implementation? If not what is the definition of an ODP thread?
>> (independentely of the ODP implemetation)
>>
>>
>>
>> Yes, that’s basically the definition. A call to init_global creates an
>> instance and a call to init_local joins the calling thread into that
>> instance.
>>
>>
>>
>> Linux is so common platform that it’s good to use that as an example and
>> explicitly state that both pthreads and processes can be “ODP threads”.
>>
>>
>>
>> -Petri
>>
>>
>>
>>
>>
>>
>>
>> Christophe
>>
>>

[lng-odp] [API-NEXT PATCHv4] linux-generic: pktio: add option to enable and disable ipc pktio

[Maxim Uvarov]

With more options to enable/disable features it's more easy to isolate
and debug problem if any. For now I have suspitious that in CI make check
runs in parallel with other make checks which share the same pool memory.
I.e. one process can corrupt memory for other process. Moving IPC to option
it will be easy to debug that.

Signed-off-by: Maxim Uvarov 
---
 v4: - fix Matias comments to do things more accurate in .m4

 configure.ac| 3 ++-
 platform/linux-generic/m4/configure.m4  | 1 +
 platform/linux-generic/m4/odp_ipc.m4| 9 +
 platform/linux-generic/odp_pool.c   | 4 
 platform/linux-generic/pktio/io_ops.c   | 2 ++
 platform/linux-generic/test/Makefile.am | 7 +--
 6 files changed, 23 insertions(+), 3 deletions(-)
 create mode 100644 platform/linux-generic/m4/odp_ipc.m4

diff --git a/configure.ac b/configure.ac
index 257f8c3..1aa44d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ AC_SUBST([platform_with_platform_test], 
["platform/${with_platform}/test"])
 # Prepare default values for platform specific optional features
 ##
 netmap_support=no
+pktio_ipc_support=no
 
 ##
 # Run platform specific checks and settings
@@ -102,7 +103,7 @@ fi
 ##
 AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
 AM_CONDITIONAL([HAVE_PCAP], [test $have_pcap = yes])
-
+AM_CONDITIONAL([PKTIO_IPC], [test x$pktio_ipc_support = xyes])
 
 AC_ARG_WITH([sdk-install-path],
 AC_HELP_STRING([--with-sdk-install-path=DIR path to external libs and headers],
diff --git a/platform/linux-generic/m4/configure.m4 
b/platform/linux-generic/m4/configure.m4
index 2ac4799..b8c1c52 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -21,6 +21,7 @@ m4_include([platform/linux-generic/m4/odp_openssl.m4])
 m4_include([platform/linux-generic/m4/odp_netmap.m4])
 m4_include([platform/linux-generic/m4/odp_dpdk.m4])
 m4_include([platform/linux-generic/m4/odp_pcap.m4])
+m4_include([platform/linux-generic/m4/odp_ipc.m4])
 
 AC_CONFIG_FILES([platform/linux-generic/Makefile
 platform/linux-generic/test/Makefile
diff --git a/platform/linux-generic/m4/odp_ipc.m4 
b/platform/linux-generic/m4/odp_ipc.m4
new file mode 100644
index 000..9475031
--- /dev/null
+++ b/platform/linux-generic/m4/odp_ipc.m4
@@ -0,0 +1,9 @@
+##
+# Enable IPC pktio support
+##
+AC_ARG_ENABLE([pktio_ipc_support],
+[  --enable-pktio_ipc-support  include ipc IO support],
+[if test x$enableval = xyes; then
+   pktio_ipc_support=yes
+   ODP_CFLAGS="$ODP_CFLAGS -DPKTIO_IPC"
+fi])
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index 78ccc0f..950fa90 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -421,7 +421,11 @@ odp_pool_t _pool_create(const char *name,
 odp_pool_t odp_pool_create(const char *name,
   odp_pool_param_t *params)
 {
+#ifdef PKTIO_IPC
return _pool_create(name, params, ODP_SHM_PROC);
+#else
+   return _pool_create(name, params, 0);
+#endif
 }
 
 odp_pool_t odp_pool_lookup(const char *name)
diff --git a/platform/linux-generic/pktio/io_ops.c 
b/platform/linux-generic/pktio/io_ops.c
index 15aa160..faa72d1 100644
--- a/platform/linux-generic/pktio/io_ops.c
+++ b/platform/linux-generic/pktio/io_ops.c
@@ -21,7 +21,9 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
 #ifdef HAVE_PCAP
&pcap_pktio_ops,
 #endif
+#ifdef PKTIO_IPC
&ipc_pktio_ops,
+#endif
&tap_pktio_ops,
&sock_mmap_pktio_ops,
&sock_mmsg_pktio_ops,
diff --git a/platform/linux-generic/test/Makefile.am 
b/platform/linux-generic/test/Makefile.am
index 1011437..4bf24cb 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -1,12 +1,11 @@
 include $(top_srcdir)/test/Makefile.inc
 TESTS_ENVIRONMENT += TEST_DIR=${top_builddir}/test/validation
 
-ODP_MODULES = pktio pktio_ipc ring
+ODP_MODULES = pktio ring
 
 if test_vald
 TESTS = pktio/pktio_run \
pktio/pktio_run_tap \
-   pktio_ipc/pktio_ipc_run \
ring/ringtest$(EXEEXT) \
${top_builddir}/test/validation/atomic/atomic_main$(EXEEXT) \
${top_builddir}/test/validation/barrier/barrier_main$(EXEEXT) \
@@ -38,6 +37,10 @@ SUBDIRS = $(ODP_MODULES)
 if HAVE_PCAP
 TESTS += pktio/pktio_run_pcap
 endif
+if PKTIO_IPC
+TESTS += pktio_ipc/pktio_ipc_run
+SUBDIRS += pktio_ipc
+endif
 endif
 
 dist_check_SCRIPTS = run-test tests-validation.env $(LOG_COMPILER)
-- 
2.7.1.250.gff4ea60

___
lng-odp mailing list
lng

Re: [lng-odp] crypto contexts

[Nikhil Agarwal]

Hi,

It seems none of your statement is true.  Comments inline.
It is platform implementation specific that how many crypto sessions it 
supports. If it does not support required number of sessions, then only way out 
as of today is to create n destroy session.

Bala,

If this is a generic use-case, shall a  light weight modify session API be 
considered to be added, as 100K session might be costly to maintain, provided 
they are used only once in a long run?

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Gábor 
Sándor Enyedi
Sent: Thursday, February 18, 2016 1:58 PM
To: Bala Manoharan 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] crypto contexts

OK, so back to the original question: I have up to ~100K users (but always 
higher than 32 by orders of magnitude) all with its own crypto key. In worst 
case, all of them are sending packets at the same time, so I need to decrypt a 
lot of packets from other users, before I face a packet from the same user 
again, so I cannot have 'n' different sessions. Since I cannot change the 
crypto key, the only way to do this is creating and destroying a session per 
packet. I looked into the x86 code, and it seemed that the code was 
intentionally written in a way that session create/destroy is relatively quick, 
since there is no malloc and free and crypto contexts are not destroyed at all.

I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that creating/destroying crypto 
session is fast, i.e. I can expect that this is a cheap operation on each 
platform.
[Nikhil] This is implementation specific, and cannot be guaranteed to be fast 
on each platform.(As this is supposed to be one time API per session)
2. This is just a bug in API, and should be fixed by adding some way to change 
the crypto key.
[Nikhil] You cannot change crypto key for a session.
3. There is already some solution, which I don't know... E.g. the 
cipher_key.data field in the session is just a pointer, one possibility is 
changing the memory content at the address where it points to. :)
[Nikhil] There is no way as of today that you can modify crypto keys of a 
session.


Please confirm that #1 is the correct answer.

Gabor

On 02/17/2016 05:56 PM, Bala Manoharan wrote:
Hi,

Crypto key in crypto session cannot be changed and in this case you need 'n' 
different crypto sessions only and it cannot be reused.

Regards,
Bala
On 17 February 2016 at 21:11, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
How can you change the crypto key? Each user has its own.

Gabor

On 02/17/2016 12:13 PM, Bala Manoharan wrote:
Hi,

There is no need to create a crypto session for each packet. The application 
needs to create a crypto session for a unique cipher/auth key (ie all the 
parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can create a crypto session and 
reuse it for packets which need similar processing.  The parameters of crypto 
session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text;   /**< Authenticate/cipher ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
odp_crypto_key_t cipher_key;   /**< Cipher key */
odp_crypto_iv_t  iv;   /**< Cipher Initialization Vector 
(IV) */
odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue;   /**< Async mode completion event 
queue */
odp_pool_t output_pool;/**< Output buffer pool */
} odp_crypto_session_params_t

If you see the odp_crypto_operation() function it reuses an existing crypto 
session and only provides parameters which are unique per packet (ie 
cipher/auth range, input packet, etc )

The limit of 32 crypto sessions is a limitation on the linux-generic 
implementation and this value might depend on individual platforms.

Regards,
Bala

On 16 February 2016 at 18:40, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
Hi,

I want to keep up IPSec connections with up to ~100K users simultaneously. 
After looking into the code, it seems that both linux-generic and odp-dpdk can 
allocate at most 32 crypto sessions (with odp_crypto_session_create). Please 
confirm, that this is not a bug, but crypto sessions are considered to be a 
very limited resource and an ODP application should create and destroy a crypto 
session for each packet, when all the users are sending traffic at the same 
time.
Thanks,

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




__

Re: [lng-odp] [QUESTION] test: validation:thread: some functions cannot be found

[Maxim Uvarov]

On 02/18/16 12:09, Xu Zaibo wrote:


Hi,

In my compiling test validation, some functions, such as 
‘thread_test_odp_thrmask_and’, ’ thread_test_odp_thrmask_or’…. cannot 
be found and failed.


And I search these function in the home directory of ODP, but get 
nothing. So, is it the problem of ‘validation/thread.c’?


Zaibo Xu



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

Hello Xu,

if it compiles than code is in. Take a look at:

./test/validation/common/mask_common.h

#define MASK_API_PREFIX(n) odp_thrmask_##n
#define MASK_TESTFUNC(n) void thread_test_odp_thrmask_##n(void)

Can you please provide log and conditions where it fails?

./test/validation/thread/thread_main.log:  Test: 
thread_test_odp_thrmask_and ...passed


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

Re: [lng-odp] crypto contexts

[Bala Manoharan]

On 18 February 2016 at 13:58, Gábor Sándor Enyedi <
gabor.sandor.eny...@ericsson.com> wrote:

> OK, so back to the original question: I have up to ~100K users (but always
> higher than 32 by orders of magnitude) all with its own crypto key. In
> worst case, all of them are sending packets at the same time, so I need to
> decrypt a lot of packets from other users, before I face a packet from the
> same user again, so I cannot have 'n' different sessions. Since I cannot
> change the crypto key, the only way to do this is creating and destroying a
> session per packet. I looked into the x86 code, and it seemed that the code
> was intentionally written in a way that session create/destroy is
> relatively quick, since there is no malloc and free and crypto contexts are
> not destroyed at all.
>
> I think, there are three possibilities at this point:
> 1. ODP was intentionally designed in the way that creating/destroying
> crypto session is fast, i.e. I can expect that this is a cheap operation on
> each platform.
>
2. This is just a bug in API, and should be fixed by adding some way to
> change the crypto key.
> 3. There is already some solution, which I don't know... E.g. the
> cipher_key.data field in the session is just a pointer, one possibility is
> changing the memory content at the address where it points to. :)
>
> Please confirm that #1 is the correct answer.
>
> Gabor
>


Unfortunately the method in which crypto session is created/destroyed is
implementation specific it might be faster but I personally wouldn't bet on
this. Since as discussed earlier the idea of crypto session is only to
reuse the parameters during odp_cryto_operation() function for better
performance so crypto session create/destroy might not be upto the mark
required in a fast path execution.

IMO there is two possible ways to address your use-case,
1. add override_cipher_key and override_auth_key parameters to
odp_crypto_op_params_t  struct which is an input to odp_cryto_operations()
function so that if these value is a not-null then the implementation will
override the values in crypto session but the drawback of this approach is
that then for general use-case where the cipher/auth key is same per
session the implementation will always have to check the
override_cipher_key/override_auth_key parameter which actually is just a
simple check but since this code runs in fast path and it is per packet
might impact the performance.

2. A more preferable approach in my point of view is to add a new API
odp_crypto_operation_key() where cipher key and auth key are given as input
parameter along with session so that the applications which need to pass
individual cipher/auth key per user can use this new API so that the
performance of  odp_crypto_operation() is not changed.

your suggestions/ comments are most welcome and I will send an RFC based on
option 2 for further discussion and you can provide your comments on the
same.

Regards,
Bala


>
>
> On 02/17/2016 05:56 PM, Bala Manoharan wrote:
>
> Hi,
>
> Crypto key in crypto session cannot be changed and in this case you need
> 'n' different crypto sessions only and it cannot be reused.
>
> Regards,
> Bala
>
> On 17 February 2016 at 21:11, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
>> How can you change the crypto key? Each user has its own.
>>
>> Gabor
>>
>>
>> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>>
>> Hi,
>>
>> There is no need to create a crypto session for each packet. The
>> application needs to create a crypto session for a unique cipher/auth key
>> (ie all the parameters in odp_crypto_session_params_t ).
>> A crypto session is created so that application can create a crypto
>> session and reuse it for packets which need similar processing.  The
>> parameters of crypto session are as follows
>>
>> typedef struct odp_crypto_session_params {
>> odp_crypto_op_t op;/**< Encode versus decode */
>> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
>> ordering */
>> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
>> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
>> odp_crypto_key_t cipher_key;   /**< Cipher key */
>> odp_crypto_iv_t  iv;   /**< Cipher Initialization
>> Vector (IV) */
>> odp_auth_alg_t auth_alg;   /**< Authentication algorithm
>> */
>> odp_crypto_key_t auth_key; /**< Authentication key */
>> odp_queue_t compl_queue;   /**< Async mode completion
>> event queue */
>> odp_pool_t output_pool;/**< Output buffer pool */
>> } odp_crypto_session_params_t
>>
>> If you see the odp_crypto_operation() function it reuses an existing
>> crypto session and only provides parameters which are unique per packet (ie
>> cipher/auth range, input packet, etc )
>>
>> The limit of 32 crypto sessions is a limitation on the linux-generic
>> implementation and this value might depen

Re: [lng-odp] crypto contexts

[Bala Manoharan]

Hi Nikhil,

On 18 February 2016 at 15:24, Nikhil Agarwal  wrote:

> Hi,
>
>
>
> It seems none of your statement is true.  Comments inline.
>
> It is platform implementation specific that how many crypto sessions it
> supports. If it does not support required number of sessions, then only way
> out as of today is to create n destroy session.
>
>
>
> Bala,
>
>
>
> If this is a generic use-case, shall a  light weight modify session API be
> considered to be added, as 100K session might be costly to maintain,
> provided they are used only once in a long run?
>

Agreed.100K session might be very costly to maintain and might defeat the
purpose of creating crypto session. The user in that case might very well
given all the session parameters to odp_crypto_operation() function.

IMO modify crypto session might not be a good idea since there might be
packets inflight which are using a particular session and changing the
session parameter creates ambiguity for packets under processing.

Regards,
Bala

>
>
> Regards
>
> Nikhil
>
>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *Gábor
> Sándor Enyedi
> *Sent:* Thursday, February 18, 2016 1:58 PM
> *To:* Bala Manoharan 
> *Cc:* lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] crypto contexts
>
>
>
> OK, so back to the original question: I have up to ~100K users (but always
> higher than 32 by orders of magnitude) all with its own crypto key. In
> worst case, all of them are sending packets at the same time, so I need to
> decrypt a lot of packets from other users, before I face a packet from the
> same user again, so I cannot have 'n' different sessions. Since I cannot
> change the crypto key, the only way to do this is creating and destroying a
> session per packet. I looked into the x86 code, and it seemed that the code
> was intentionally written in a way that session create/destroy is
> relatively quick, since there is no malloc and free and crypto contexts are
> not destroyed at all.
>
> I think, there are three possibilities at this point:
> 1. ODP was intentionally designed in the way that creating/destroying
> crypto session is fast, i.e. I can expect that this is a cheap operation on
> each platform.
>
> [Nikhil] This is implementation specific, and cannot be guaranteed to be
> fast on each platform.(As this is supposed to be one time API per session)
> 2. This is just a bug in API, and should be fixed by adding some way to
> change the crypto key.
>
> [Nikhil] You cannot change crypto key for a session.
> 3. There is already some solution, which I don't know... E.g. the
> cipher_key.data field in the session is just a pointer, one possibility is
> changing the memory content at the address where it points to. :)
>
> [Nikhil] There is no way as of today that you can modify crypto keys of a
> session.
>
>
>
> Please confirm that #1 is the correct answer.
>
> Gabor
>
> On 02/17/2016 05:56 PM, Bala Manoharan wrote:
>
> Hi,
>
>
>
> Crypto key in crypto session cannot be changed and in this case you need
> 'n' different crypto sessions only and it cannot be reused.
>
>
>
> Regards,
>
> Bala
>
> On 17 February 2016 at 21:11, Gábor Sándor Enyedi <
> gabor.sandor.eny...@ericsson.com> wrote:
>
> How can you change the crypto key? Each user has its own.
>
> Gabor
>
>
>
> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>
> Hi,
>
>
>
> There is no need to create a crypto session for each packet. The
> application needs to create a crypto session for a unique cipher/auth key
> (ie all the parameters in odp_crypto_session_params_t ).
>
> A crypto session is created so that application can create a crypto
> session and reuse it for packets which need similar processing.  The
> parameters of crypto session are as follows
>
>
>
> typedef struct odp_crypto_session_params {
>
> odp_crypto_op_t op;/**< Encode versus decode */
>
> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
> ordering */
>
> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
>
> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
>
> odp_crypto_key_t cipher_key;   /**< Cipher key */
>
> odp_crypto_iv_t  iv;   /**< Cipher Initialization
> Vector (IV) */
>
> odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
>
> odp_crypto_key_t auth_key; /**< Authentication key */
>
> odp_queue_t compl_queue;   /**< Async mode completion
> event queue */
>
> odp_pool_t output_pool;/**< Output buffer pool */
>
> } odp_crypto_session_params_t
>
>
>
> If you see the odp_crypto_operation() function it reuses an existing
> crypto session and only provides parameters which are unique per packet (ie
> cipher/auth range, input packet, etc )
>
>
>
> The limit of 32 crypto sessions is a limitation on the linux-generic
> implementation and this value might depend on individual platforms.
>
>
>
> Regards,
> Bala
>
>
>
> 

Re: [lng-odp] crypto contexts

[Nikhil Agarwal]

Othe option is instead of taking key and session as input, it is better to add 
an API odp_crypto_op_xxx which takes all input needed (Algos/Keys/buffer as 
input) and perform the single crypto operation without any session.

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Thursday, February 18, 2016 3:25 PM
To: Gábor Sándor Enyedi 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] crypto contexts


On 18 February 2016 at 13:58, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
OK, so back to the original question: I have up to ~100K users (but always 
higher than 32 by orders of magnitude) all with its own crypto key. In worst 
case, all of them are sending packets at the same time, so I need to decrypt a 
lot of packets from other users, before I face a packet from the same user 
again, so I cannot have 'n' different sessions. Since I cannot change the 
crypto key, the only way to do this is creating and destroying a session per 
packet. I looked into the x86 code, and it seemed that the code was 
intentionally written in a way that session create/destroy is relatively quick, 
since there is no malloc and free and crypto contexts are not destroyed at all.

I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that creating/destroying crypto 
session is fast, i.e. I can expect that this is a cheap operation on each 
platform.
2. This is just a bug in API, and should be fixed by adding some way to change 
the crypto key.
3. There is already some solution, which I don't know... E.g. the 
cipher_key.data field in the session is just a pointer, one possibility is 
changing the memory content at the address where it points to. :)

Please confirm that #1 is the correct answer.

Gabor


Unfortunately the method in which crypto session is created/destroyed is 
implementation specific it might be faster but I personally wouldn't bet on 
this. Since as discussed earlier the idea of crypto session is only to reuse 
the parameters during odp_cryto_operation() function for better performance so 
crypto session create/destroy might not be upto the mark required in a fast 
path execution.

IMO there is two possible ways to address your use-case,
1. add override_cipher_key and override_auth_key parameters to 
odp_crypto_op_params_t  struct which is an input to odp_cryto_operations() 
function so that if these value is a not-null then the implementation will 
override the values in crypto session but the drawback of this approach is that 
then for general use-case where the cipher/auth key is same per session the 
implementation will always have to check the 
override_cipher_key/override_auth_key parameter which actually is just a simple 
check but since this code runs in fast path and it is per packet might impact 
the performance.

2. A more preferable approach in my point of view is to add a new API 
odp_crypto_operation_key() where cipher key and auth key are given as input 
parameter along with session so that the applications which need to pass 
individual cipher/auth key per user can use this new API so that the 
performance of  odp_crypto_operation() is not changed.

your suggestions/ comments are most welcome and I will send an RFC based on 
option 2 for further discussion and you can provide your comments on the same.

Regards,
Bala



On 02/17/2016 05:56 PM, Bala Manoharan wrote:
Hi,

Crypto key in crypto session cannot be changed and in this case you need 'n' 
different crypto sessions only and it cannot be reused.

Regards,
Bala
On 17 February 2016 at 21:11, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
How can you change the crypto key? Each user has its own.

Gabor

On 02/17/2016 12:13 PM, Bala Manoharan wrote:
Hi,

There is no need to create a crypto session for each packet. The application 
needs to create a crypto session for a unique cipher/auth key (ie all the 
parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can create a crypto session and 
reuse it for packets which need similar processing.  The parameters of crypto 
session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text;   /**< Authenticate/cipher ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
odp_crypto_key_t cipher_key;   /**< Cipher key */
odp_crypto_iv_t  iv;   /**< Cipher Initialization Vector 
(IV) */
odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue;   /**< Async mode completion event 
queue */
odp_pool_t output_pool;/**< Output buffer po

Re: [lng-odp] [PATCH v3 API-NEXT 1/4] linux-generic: separate x86 ODP_CACHE_LINE_SIZE to its arch file

[Hongbo Zhang]

On 9 February 2016 at 18:41, Anders Roxell  wrote:
> On 2016-02-05 16:56, hongbo.zh...@linaro.org wrote:
>> From: Hongbo Zhang 
>>
>> Currently all ODP_CACHE_LINE_SIZE macros for different architectures are
>> held in one header file, they should be moved to their own arch file.
>> This patch moves ODP_CACHE_LINE_SIZE for x86.
>>
>> Signed-off-by: Hongbo Zhang 
>> ---
>>  doc/application-api-guide/doxygen.cfg  |  1 +
>>  include/odp/api/align.h|  5 -
>>  platform/linux-generic/arch/x86/odp/cpu_arch.h | 14 ++
>>  platform/linux-generic/include/odp/align.h |  9 ++---
>>  4 files changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/doc/application-api-guide/doxygen.cfg 
>> b/doc/application-api-guide/doxygen.cfg
>> index 7951e9e..c585108 100644
>> --- a/doc/application-api-guide/doxygen.cfg
>> +++ b/doc/application-api-guide/doxygen.cfg
>> @@ -14,6 +14,7 @@ INPUT = $(SRCDIR)/doc \
>>   $(SRCDIR)/doc/users-guide \
>>   $(SRCDIR)/include \
>>   $(SRCDIR)/platform/$(WITH_PLATFORM)/include/odp \
>> + $(SRCDIR)/platform/$(WITH_PLATFORM)/arch/ \
>>   $(SRCDIR)/helper/include
>>  FILE_PATTERNS = *.h odp*.c *.dox
>>  RECURSIVE = YES
>> diff --git a/include/odp/api/align.h b/include/odp/api/align.h
>> index 677ff12..f4b4be6 100644
>> --- a/include/odp/api/align.h
>> +++ b/include/odp/api/align.h
>> @@ -47,11 +47,6 @@ extern "C" {
>>   */
>>
>>  /**
>> - * @def ODP_CACHE_LINE_SIZE
>> - * Cache line size
>> - */
>> -
>> -/**
>
> I'm not convinced that we should move the documentation away from the
> "generic" header file.
>

Well, after tried, if I leave this documentation still in
include/odp/api/align.h, I cannot 'make doxygen-html' correctly, there
is either compiling or the macro missing in html files.

Anybody who is familiar with this doxygen grammar has any suggestions?

Thanks.

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

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

[Nikhil Agarwal]

Shall supported algos be add in crypto capabilities?

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Thursday, February 18, 2016 10:40 AM
To: Bill Fischofer 
Cc: LNG ODP Mailman List 
Subject: Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add 
odp_crypto_capability() api

For the series:
Reviewed-by: Balasubramanian Manoharan 
mailto:bala.manoha...@linaro.org>>

Regards,
Bala

On 18 February 2016 at 01:07, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
Signed-off-by: Bill Fischofer 
mailto:bill.fischo...@linaro.org>>
---
 include/odp/api/spec/crypto.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 41beedb..eaacff1 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
 } odp_crypto_op_result_t;

 /**
+ * Crypto capabilities
+ */
+typedef struct odp_crypto_capability_t {
+   /** Maximum number of sessions */
+   unsigned max_sessions;
+} odp_crypto_capability_t;
+
+/**
+ * Get crypto capabilities
+ *
+ * @param[out] capability Pointer to capability structrue for output
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_crypto_capability(odp_crypto_capability_t *capability);
+
+/**
  * Crypto session creation (synchronous)
  *
  * @param paramsSession parameters
--
2.5.0

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

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

Re: [lng-odp] crypto contexts

[Gábor Sándor Enyedi]

Hi,

I admit that our use-case is very special, and getting traffic from 100K 
users at the same time is the worst case scenario (however, this is not 
impossible, especially with IoT), but some 100s of users at the same 
time may easily happen. For x86 DPDK+libcrypto, we use one 
EVP_CIPHER_CTX per thread, and change the key for each packet (and get 
quite a good performance). I don't know if changing the key is as simple 
for other architectures as that is for x86, where we have no HW support...


Gabor

On 02/18/2016 11:02 AM, Bala Manoharan wrote:

Hi Nikhil,

On 18 February 2016 at 15:24, Nikhil Agarwal > wrote:


Hi,

It seems none of your statement is true.  Comments inline.

It is platform implementation specific that how many crypto
sessions it supports. If it does not support required number of
sessions, then only way out as of today is to create n destroy
session.

Bala,

If this is a generic use-case, shall a  light weight modify
session API be considered to be added, as 100K session might be
costly to maintain, provided they are used only once in a long run?


Agreed.100K session might be very costly to maintain and might defeat 
the purpose of creating crypto session. The user in that case might 
very well given all the session parameters to odp_crypto_operation() 
function.


IMO modify crypto session might not be a good idea since there might 
be packets inflight which are using a particular session and changing 
the session parameter creates ambiguity for packets under processing.


Regards,
Bala

Regards

Nikhil

*From:*lng-odp [mailto:lng-odp-boun...@lists.linaro.org
] *On Behalf Of *Gábor
Sándor Enyedi
*Sent:* Thursday, February 18, 2016 1:58 PM
*To:* Bala Manoharan mailto:bala.manoha...@linaro.org>>
*Cc:* lng-odp@lists.linaro.org 
*Subject:* Re: [lng-odp] crypto contexts

OK, so back to the original question: I have up to ~100K users
(but always higher than 32 by orders of magnitude) all with its
own crypto key. In worst case, all of them are sending packets at
the same time, so I need to decrypt a lot of packets from other
users, before I face a packet from the same user again, so I
cannot have 'n' different sessions. Since I cannot change the
crypto key, the only way to do this is creating and destroying a
session per packet. I looked into the x86 code, and it seemed that
the code was intentionally written in a way that session
create/destroy is relatively quick, since there is no malloc and
free and crypto contexts are not destroyed at all.

I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that
creating/destroying crypto session is fast, i.e. I can expect that
this is a cheap operation on each platform.

[Nikhil] This is implementation specific, and cannot be guaranteed
to be fast on each platform.(As this is supposed to be one time
API per session)
2. This is just a bug in API, and should be fixed by adding some
way to change the crypto key.

[Nikhil] You cannot change crypto key for a session.
3. There is already some solution, which I don't know... E.g. the
cipher_key.data field in the session is just a pointer, one
possibility is changing the memory content at the address where it
points to. :)

[Nikhil] There is no way as of today that you can modify crypto
keys of a session.



Please confirm that #1 is the correct answer.

Gabor

On 02/17/2016 05:56 PM, Bala Manoharan wrote:

Hi,

Crypto key in crypto session cannot be changed and in this
case you need 'n' different crypto sessions only and it cannot
be reused.

Regards,

Bala

On 17 February 2016 at 21:11, Gábor Sándor Enyedi
mailto:gabor.sandor.eny...@ericsson.com>> wrote:

How can you change the crypto key? Each user has its own.

Gabor

On 02/17/2016 12:13 PM, Bala Manoharan wrote:

Hi,

There is no need to create a crypto session for each
packet. The application needs to create a crypto
session for a unique cipher/auth key (ie all the
parameters in odp_crypto_session_params_t ).

A crypto session is created so that application can
create a crypto session and reuse it for packets which
need similar processing.  The parameters of crypto
session are as follows

typedef struct odp_crypto_session_params {

odp_crypto_op_t op;  /**< Encode versus decode */

odp_bool_t auth_cipher_text;   /**<
Authenticate/cipher ordering */

odp_crypto_op_mode_t pref_mode;

Re: [lng-odp] [API-NEXT PATCH 1/3] drv: adding byteorder.h

[Maxim Uvarov]

I really don't like what we are doing here. We should try to avoid any 
code duplication.
Add odpdrv_ prefix to all odp functions and move them to other place is 
not thing we should to do.


And also, in my understanding, we should not implement our own 
programming language for odp drivers.


So my point is:
1) odp driver and odp application should operate the same type of 
variables and structs.

No any drv_magic_atomic, drv_LITTLE_ENDIAN  and etc.

2) What is odp driver? Is it some linux kernel driver adopted to ODP or 
freebsd driver adopted to ODP?
If it's adopted driver than we need have as less changes related to odp 
there as we can.


3) Work flow here should be opposite. Driver should be implemented (or 
ported) first. Then you should
consider which parts needed to be implemented. Patch should be linked to 
implementation patch which
shows the actual reason for doing this. But now it looks like double 
defining everything what we have in

odp api and then we will think what to do with it.

Maxim.


On 02/17/16 17:36, Christophe Milard wrote:

Signed-off-by: Christophe Milard 
---
  include/odp/drv/spec/byteorder.h | 176 +++
  1 file changed, 176 insertions(+)
  create mode 100644 include/odp/drv/spec/byteorder.h

diff --git a/include/odp/drv/spec/byteorder.h b/include/odp/drv/spec/byteorder.h
new file mode 100644
index 000..2543016
--- /dev/null
+++ b/include/odp/drv/spec/byteorder.h
@@ -0,0 +1,176 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP byteorder
+ */
+
+#ifndef ODPDRV_BYTEORDER_H_
+#define ODPDRV_BYTEORDER_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @addtogroup odpdrv_compiler_optim ODPDRV COMPILER / OPTIMIZATION
+ *  Macros that check byte order and operations for byte order conversion.
+ *  @{
+ */
+
+/**
+ * @def ODPDRV_BIG_ENDIAN
+ * Big endian byte order
+ *
+ * @def ODPDRV_LITTLE_ENDIAN
+ * Little endian byte order
+ *
+ * @def ODPDRV_BIG_ENDIAN_BITFIELD
+ * Big endian bit field
+ *
+ * @def ODPDRV_LITTLE_ENDIAN_BITFIELD
+ * Little endian bit field
+ *
+ * @def ODPDRV_BYTE_ORDER
+ * Selected byte order
+ */
+
+/**
+ * @typedef odpdrv_u16le_t
+ * unsigned 16bit little endian
+ *
+ * @typedef odpdrv_u16be_t
+ * unsigned 16bit big endian
+ *
+ * @typedef odpdrv_u32le_t
+ * unsigned 32bit little endian
+ *
+ * @typedef odpdrv_u32be_t
+ * unsigned 32bit big endian
+ *
+ * @typedef odpdrv_u64le_t
+ * unsigned 64bit little endian
+ *
+ * @typedef odpdrv_u64be_t
+ * unsigned 64bit big endian
+ *
+ * @typedef odpdrv_u16sum_t
+ * unsigned 16bit bitwise
+ *
+ * @typedef odpdrv_u32sum_t
+ * unsigned 32bit bitwise
+ */
+
+/*
+ * Big Endian -> CPU byte order:
+ */
+
+/**
+ * Convert 16bit big endian to cpu native uint16_t
+ * @param be16  big endian 16bit
+ * @return  cpu native uint16_t
+ */
+uint16_t odpdrv_be_to_cpu_16(odpdrv_u16be_t be16);
+
+/**
+ * Convert 32bit big endian to cpu native uint32_t
+ * @param be32  big endian 32bit
+ * @return  cpu native uint32_t
+ */
+uint32_t odpdrv_be_to_cpu_32(odpdrv_u32be_t be32);
+
+/**
+ * Convert 64bit big endian to cpu native uint64_t
+ * @param be64  big endian 64bit
+ * @return  cpu native uint64_t
+ */
+uint64_t odpdrv_be_to_cpu_64(odpdrv_u64be_t be64);
+
+/*
+ * CPU byte order -> Big Endian:
+ */
+
+/**
+ * Convert cpu native uint16_t to 16bit big endian
+ * @param cpu16  uint16_t in cpu native format
+ * @return  big endian 16bit
+ */
+odpdrv_u16be_t odpdrv_cpu_to_be_16(uint16_t cpu16);
+
+/**
+ * Convert cpu native uint32_t to 32bit big endian
+ * @param cpu32  uint32_t in cpu native format
+ * @return  big endian 32bit
+ */
+odpdrv_u32be_t odpdrv_cpu_to_be_32(uint32_t cpu32);
+
+/**
+ * Convert cpu native uint64_t to 64bit big endian
+ * @param cpu64  uint64_t in cpu native format
+ * @return  big endian 64bit
+ */
+odpdrv_u64be_t odpdrv_cpu_to_be_64(uint64_t cpu64);
+
+/*
+ * Little Endian -> CPU byte order:
+ */
+
+/**
+ * Convert 16bit little endian to cpu native uint16_t
+ * @param le16  little endian 16bit
+ * @return  cpu native uint16_t
+ */
+uint16_t odpdrv_le_to_cpu_16(odpdrv_u16le_t le16);
+
+/**
+ * Convert 32bit little endian to cpu native uint32_t
+ * @param le32  little endian 32bit
+ * @return  cpu native uint32_t
+ */
+uint32_t odpdrv_le_to_cpu_32(odpdrv_u32le_t le32);
+
+/**
+ * Convert 64bit little endian to cpu native uint64_t
+ * @param le64  little endian 64bit
+ * @return  cpu native uint64_t
+ */
+uint64_t odpdrv_le_to_cpu_64(odpdrv_u64le_t le64);
+
+/*
+ * CPU byte order -> Little Endian:
+ */
+
+/**
+ * Convert cpu native uint16_t to 16bit little endian
+ * @param cpu16  uint16_t in cpu native format
+ * @return  little endian 16bit
+ */
+odpdrv_u16le_t odpdrv_cpu_to_le_16(uint16_t cpu16);
+
+/**
+ * Convert cpu native uint32_t to 32bit little endian
+ * @param cpu32  uint32_t in cpu native format
+ * @return  little endian 32bit
+ */
+odpdrv_u32le_t odpdrv_cpu_to_l

Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add option to enable and disable ipc pktio

[Maxim Uvarov]

On 02/18/16 12:06, Savolainen, Petri (Nokia - FI/Espoo) wrote:



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Maxim Uvarov
Sent: Thursday, February 18, 2016 10:45 AM
To: Elo, Matias (Nokia - FI/Espoo) ; lng-
o...@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/2] linux-generic: pktio: add
option to enable and disable ipc pktio

Hello Matias,

thanks for comments will send v4.

During update I thinge we can not use ODP_ prefix here:
+#ifdef ODP_PKTIO_IPC
  &ipc_pktio_ops,
+#endif

as well as in:

+#ifdef ODP_PKTIO_DPDK
  
+#endif

Because it might be confusing other people thinking that it's related to
some odp API.

Let's use simple PKTIO_IPC, PKTIO_DPDK, PKTIO_NETMAP and etc. Agree?


I think it's better to prefix. Could use _ODP_PKTIO_IPC, ... so that it's 
clearly internal to the implementation.

-Petri


I already sent v4. I can change it to _ODP_PKTIO_NAME on apply.

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

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pktio: add option to enable and disable ipc pktio

[Elo, Matias (Nokia - FI/Espoo)]

Looks good to me assuming you rename PKTIO_IPC to _ODP_PKTIO_IPC on apply.

Reviewed-by: Matias Elo 


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Maxim
> Uvarov
> Sent: Thursday, February 18, 2016 11:46 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCHv4] linux-generic: pktio: add option to 
> enable
> and disable ipc pktio
> 
> With more options to enable/disable features it's more easy to isolate
> and debug problem if any. For now I have suspitious that in CI make check
> runs in parallel with other make checks which share the same pool memory.
> I.e. one process can corrupt memory for other process. Moving IPC to option
> it will be easy to debug that.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  v4: - fix Matias comments to do things more accurate in .m4
> 
>  configure.ac| 3 ++-
>  platform/linux-generic/m4/configure.m4  | 1 +
>  platform/linux-generic/m4/odp_ipc.m4| 9 +
>  platform/linux-generic/odp_pool.c   | 4 
>  platform/linux-generic/pktio/io_ops.c   | 2 ++
>  platform/linux-generic/test/Makefile.am | 7 +--
>  6 files changed, 23 insertions(+), 3 deletions(-)
>  create mode 100644 platform/linux-generic/m4/odp_ipc.m4
> 
> diff --git a/configure.ac b/configure.ac
> index 257f8c3..1aa44d2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -85,6 +85,7 @@ AC_SUBST([platform_with_platform_test],
> ["platform/${with_platform}/test"])
>  # Prepare default values for platform specific optional features
> 
> ##
> 
>  netmap_support=no
> +pktio_ipc_support=no
> 
> 
> ##
> 
>  # Run platform specific checks and settings
> @@ -102,7 +103,7 @@ fi
> 
> ##
> 
>  AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
>  AM_CONDITIONAL([HAVE_PCAP], [test $have_pcap = yes])
> -
> +AM_CONDITIONAL([PKTIO_IPC], [test x$pktio_ipc_support = xyes])
> 
>  AC_ARG_WITH([sdk-install-path],
>  AC_HELP_STRING([--with-sdk-install-path=DIR path to external libs and
> headers],
> diff --git a/platform/linux-generic/m4/configure.m4 b/platform/linux-
> generic/m4/configure.m4
> index 2ac4799..b8c1c52 100644
> --- a/platform/linux-generic/m4/configure.m4
> +++ b/platform/linux-generic/m4/configure.m4
> @@ -21,6 +21,7 @@ m4_include([platform/linux-generic/m4/odp_openssl.m4])
>  m4_include([platform/linux-generic/m4/odp_netmap.m4])
>  m4_include([platform/linux-generic/m4/odp_dpdk.m4])
>  m4_include([platform/linux-generic/m4/odp_pcap.m4])
> +m4_include([platform/linux-generic/m4/odp_ipc.m4])
> 
>  AC_CONFIG_FILES([platform/linux-generic/Makefile
>platform/linux-generic/test/Makefile
> diff --git a/platform/linux-generic/m4/odp_ipc.m4 b/platform/linux-
> generic/m4/odp_ipc.m4
> new file mode 100644
> index 000..9475031
> --- /dev/null
> +++ b/platform/linux-generic/m4/odp_ipc.m4
> @@ -0,0 +1,9 @@
> +#
> #
> +# Enable IPC pktio support
> +#
> #
> +AC_ARG_ENABLE([pktio_ipc_support],
> +[  --enable-pktio_ipc-support  include ipc IO support],
> +[if test x$enableval = xyes; then
> + pktio_ipc_support=yes
> + ODP_CFLAGS="$ODP_CFLAGS -DPKTIO_IPC"
> +fi])
> diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
> generic/odp_pool.c
> index 78ccc0f..950fa90 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -421,7 +421,11 @@ odp_pool_t _pool_create(const char *name,
>  odp_pool_t odp_pool_create(const char *name,
>  odp_pool_param_t *params)
>  {
> +#ifdef PKTIO_IPC
>   return _pool_create(name, params, ODP_SHM_PROC);
> +#else
> + return _pool_create(name, params, 0);
> +#endif
>  }
> 
>  odp_pool_t odp_pool_lookup(const char *name)
> diff --git a/platform/linux-generic/pktio/io_ops.c b/platform/linux-
> generic/pktio/io_ops.c
> index 15aa160..faa72d1 100644
> --- a/platform/linux-generic/pktio/io_ops.c
> +++ b/platform/linux-generic/pktio/io_ops.c
> @@ -21,7 +21,9 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
>  #ifdef HAVE_PCAP
>   &pcap_pktio_ops,
>  #endif
> +#ifdef PKTIO_IPC
>   &ipc_pktio_ops,
> +#endif
>   &tap_pktio_ops,
>   &sock_mmap_pktio_ops,
>   &sock_mmsg_pktio_ops,
> diff --git a/platform/linux-generic/test/Makefile.am b/platform/linux-
> generic/test/Makefile.am
> index 1011437..4bf24cb 100644
> --- a/platform/linux-generic/test/Makefile.am
> +++ b/platform/linux-generic/test/Makefile.am
> @@ -1,12 +1,11 @@
>  include $(top_srcdir)/test/Makefile.inc
>  TESTS_ENVIRONMENT += TEST_DIR=${top_builddir}/test/validation
> 
> -ODP_MODULES = pktio pktio_ipc ring
> +ODP_MODULES = pktio r

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

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

Yes that’s the idea, but those can be added later on top of this initial 
definition.

We’d need to decide, if capability struct lists algos supported OR algos 
supported on HW (and demand that everything is always implemented either in SW 
or HW). Maybe it makes sense to allow low end or domain targeted 
implementations (which would not implement all algos) – and thus list algos 
supported.

-Petri


From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Nikhil 
Agarwal
Sent: Thursday, February 18, 2016 12:09 PM
To: Bala Manoharan ; Bill Fischofer 

Cc: LNG ODP Mailman List 
Subject: Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add 
odp_crypto_capability() api

Shall supported algos be add in crypto capabilities?

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Thursday, February 18, 2016 10:40 AM
To: Bill Fischofer mailto:bill.fischo...@linaro.org>>
Cc: LNG ODP Mailman List 
mailto:lng-odp@lists.linaro.org>>
Subject: Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add 
odp_crypto_capability() api

For the series:
Reviewed-by: Balasubramanian Manoharan 
mailto:bala.manoha...@linaro.org>>

Regards,
Bala

On 18 February 2016 at 01:07, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
Signed-off-by: Bill Fischofer 
mailto:bill.fischo...@linaro.org>>
---
 include/odp/api/spec/crypto.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 41beedb..eaacff1 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
 } odp_crypto_op_result_t;

 /**
+ * Crypto capabilities
+ */
+typedef struct odp_crypto_capability_t {
+   /** Maximum number of sessions */
+   unsigned max_sessions;
+} odp_crypto_capability_t;
+
+/**
+ * Get crypto capabilities
+ *
+ * @param[out] capability Pointer to capability structrue for output
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_crypto_capability(odp_crypto_capability_t *capability);
+
+/**
  * Crypto session creation (synchronous)
  *
  * @param paramsSession parameters
--
2.5.0

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

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

[lng-odp] why odp driver can not use odp api?

[Maxim Uvarov]

Hello,

Does someone have clear view why odp driver can not use odp api functions?
Can you please explain why code should be duplicated?

*) odp driver here means pktio interface to NIC implemented as driver.


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

[lng-odp] 答复: lng-odp Digest, Vol 23, Issue 207

[Xu Zaibo]

l use-case 
where the cipher/auth key is same per session the implementation will always 
have to check the override_cipher_key/override_auth_key parameter which 
actually is just a simple check but since this code runs in fast path and it is 
per packet might impact the performance.

2. A more preferable approach in my point of view is to add a new API
odp_crypto_operation_key() where cipher key and auth key are given as input 
parameter along with session so that the applications which need to pass 
individual cipher/auth key per user can use this new API so that the 
performance of  odp_crypto_operation() is not changed.

your suggestions/ comments are most welcome and I will send an RFC based on 
option 2 for further discussion and you can provide your comments on the same.

Regards,
Bala


>
>
> On 02/17/2016 05:56 PM, Bala Manoharan wrote:
>
> Hi,
>
> Crypto key in crypto session cannot be changed and in this case you 
> need 'n' different crypto sessions only and it cannot be reused.
>
> Regards,
> Bala
>
> On 17 February 2016 at 21:11, Gábor Sándor Enyedi < 
> gabor.sandor.eny...@ericsson.com> wrote:
>
>> How can you change the crypto key? Each user has its own.
>>
>> Gabor
>>
>>
>> On 02/17/2016 12:13 PM, Bala Manoharan wrote:
>>
>> Hi,
>>
>> There is no need to create a crypto session for each packet. The 
>> application needs to create a crypto session for a unique cipher/auth 
>> key (ie all the parameters in odp_crypto_session_params_t ).
>> A crypto session is created so that application can create a crypto 
>> session and reuse it for packets which need similar processing.  The 
>> parameters of crypto session are as follows
>>
>> typedef struct odp_crypto_session_params {
>> odp_crypto_op_t op;/**< Encode versus decode */
>> odp_bool_t auth_cipher_text;   /**< Authenticate/cipher
>> ordering */
>> odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
>> odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
>> odp_crypto_key_t cipher_key;   /**< Cipher key */
>> odp_crypto_iv_t  iv;   /**< Cipher Initialization
>> Vector (IV) */
>> odp_auth_alg_t auth_alg;   /**< Authentication algorithm
>> */
>> odp_crypto_key_t auth_key; /**< Authentication key */
>> odp_queue_t compl_queue;   /**< Async mode completion
>> event queue */
>> odp_pool_t output_pool;/**< Output buffer pool */
>> } odp_crypto_session_params_t
>>
>> If you see the odp_crypto_operation() function it reuses an existing 
>> crypto session and only provides parameters which are unique per 
>> packet (ie cipher/auth range, input packet, etc )
>>
>> The limit of 32 crypto sessions is a limitation on the linux-generic 
>> implementation and this value might depend on individual platforms.
>>
>> Regards,
>> Bala
>>
>> On 16 February 2016 at 18:40, Gábor Sándor Enyedi < 
>> gabor.sandor.eny...@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>> I want to keep up IPSec connections with up to ~100K users 
>>> simultaneously. After looking into the code, it seems that both 
>>> linux-generic and odp-dpdk can allocate at most 32 crypto sessions 
>>> (with odp_crypto_session_create). Please confirm, that this is not a 
>>> bug, but crypto sessions are considered to be a very limited 
>>> resource and an ODP application should create and destroy a crypto 
>>> session for each packet, when all the users are sending traffic at the same 
>>> time.
>>> Thanks,
>>>
>>> Gabor
>>> ___
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.linaro.org/pipermail/lng-odp/attachments/20160218/2ab52cb4/attachment-0001.html>

--

Message: 3
Date: Thu, 18 Feb 2016 15:32:41 +0530
From: Bala Manoharan 
To: Nikhil Agarwal 
Cc: Hemant Agrawal ,
"lng-odp@lists.linaro.org" 
Subject: Re: [lng-odp] crypto contexts
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi Nikhil,

On 18 February 2016 at 15:24, Nikhil Agarwal  wrote:

> Hi,
>
>
>
> It seems none of your statement is true.  Comments inline.
>
> It is platform implementation specific that how many cr

Re: [lng-odp] [API-NEXT PATCH 1/3] drv: adding byteorder.h

[Christophe Milard]

A complete -partly working- driver prototype was sent as in RFC:
https://lists.linaro.org/pipermail/lng-odp/2016-January/019162.html
This approach of the driver interface "extending" the application interface
was refused and we decided that the driver would have its own separate
definition... in its own directory.
so now the choice are:
1) Let the driver use both the north application interface and its own
south interface (do we really want that)?
2) let the driver interface have some common functions (to the application
interface), i.e. redefining these common functions in both interfaces, and
when possible having the common "body" in the com directory) - this patch

Christophe.



On 18 February 2016 at 11:44, Maxim Uvarov  wrote:

> I really don't like what we are doing here. We should try to avoid any
> code duplication.
> Add odpdrv_ prefix to all odp functions and move them to other place is
> not thing we should to do.
>
> And also, in my understanding, we should not implement our own programming
> language for odp drivers.
>
> So my point is:
> 1) odp driver and odp application should operate the same type of
> variables and structs.
> No any drv_magic_atomic, drv_LITTLE_ENDIAN  and etc.
>
> 2) What is odp driver? Is it some linux kernel driver adopted to ODP or
> freebsd driver adopted to ODP?
> If it's adopted driver than we need have as less changes related to odp
> there as we can.
>
> 3) Work flow here should be opposite. Driver should be implemented (or
> ported) first. Then you should
> consider which parts needed to be implemented. Patch should be linked to
> implementation patch which
> shows the actual reason for doing this. But now it looks like double
> defining everything what we have in
> odp api and then we will think what to do with it.
>
> Maxim.
>
>
>
> On 02/17/16 17:36, Christophe Milard wrote:
>
>> Signed-off-by: Christophe Milard 
>> ---
>>   include/odp/drv/spec/byteorder.h | 176
>> +++
>>   1 file changed, 176 insertions(+)
>>   create mode 100644 include/odp/drv/spec/byteorder.h
>>
>> diff --git a/include/odp/drv/spec/byteorder.h
>> b/include/odp/drv/spec/byteorder.h
>> new file mode 100644
>> index 000..2543016
>> --- /dev/null
>> +++ b/include/odp/drv/spec/byteorder.h
>> @@ -0,0 +1,176 @@
>> +/* Copyright (c) 2016, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +/**
>> + * @file
>> + *
>> + * ODP byteorder
>> + */
>> +
>> +#ifndef ODPDRV_BYTEORDER_H_
>> +#define ODPDRV_BYTEORDER_H_
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +/** @addtogroup odpdrv_compiler_optim ODPDRV COMPILER / OPTIMIZATION
>> + *  Macros that check byte order and operations for byte order
>> conversion.
>> + *  @{
>> + */
>> +
>> +/**
>> + * @def ODPDRV_BIG_ENDIAN
>> + * Big endian byte order
>> + *
>> + * @def ODPDRV_LITTLE_ENDIAN
>> + * Little endian byte order
>> + *
>> + * @def ODPDRV_BIG_ENDIAN_BITFIELD
>> + * Big endian bit field
>> + *
>> + * @def ODPDRV_LITTLE_ENDIAN_BITFIELD
>> + * Little endian bit field
>> + *
>> + * @def ODPDRV_BYTE_ORDER
>> + * Selected byte order
>> + */
>> +
>> +/**
>> + * @typedef odpdrv_u16le_t
>> + * unsigned 16bit little endian
>> + *
>> + * @typedef odpdrv_u16be_t
>> + * unsigned 16bit big endian
>> + *
>> + * @typedef odpdrv_u32le_t
>> + * unsigned 32bit little endian
>> + *
>> + * @typedef odpdrv_u32be_t
>> + * unsigned 32bit big endian
>> + *
>> + * @typedef odpdrv_u64le_t
>> + * unsigned 64bit little endian
>> + *
>> + * @typedef odpdrv_u64be_t
>> + * unsigned 64bit big endian
>> + *
>> + * @typedef odpdrv_u16sum_t
>> + * unsigned 16bit bitwise
>> + *
>> + * @typedef odpdrv_u32sum_t
>> + * unsigned 32bit bitwise
>> + */
>> +
>> +/*
>> + * Big Endian -> CPU byte order:
>> + */
>> +
>> +/**
>> + * Convert 16bit big endian to cpu native uint16_t
>> + * @param be16  big endian 16bit
>> + * @return  cpu native uint16_t
>> + */
>> +uint16_t odpdrv_be_to_cpu_16(odpdrv_u16be_t be16);
>> +
>> +/**
>> + * Convert 32bit big endian to cpu native uint32_t
>> + * @param be32  big endian 32bit
>> + * @return  cpu native uint32_t
>> + */
>> +uint32_t odpdrv_be_to_cpu_32(odpdrv_u32be_t be32);
>> +
>> +/**
>> + * Convert 64bit big endian to cpu native uint64_t
>> + * @param be64  big endian 64bit
>> + * @return  cpu native uint64_t
>> + */
>> +uint64_t odpdrv_be_to_cpu_64(odpdrv_u64be_t be64);
>> +
>> +/*
>> + * CPU byte order -> Big Endian:
>> + */
>> +
>> +/**
>> + * Convert cpu native uint16_t to 16bit big endian
>> + * @param cpu16  uint16_t in cpu native format
>> + * @return  big endian 16bit
>> + */
>> +odpdrv_u16be_t odpdrv_cpu_to_be_16(uint16_t cpu16);
>> +
>> +/**
>> + * Convert cpu native uint32_t to 32bit big endian
>> + * @param cpu32  uint32_t in cpu native format
>> + * @return  big endian 32bit
>> + */
>> +odpdrv_u32be_t odpdrv_cpu_to_be_32(uint32_t cpu32);
>> +
>> +/**
>> + * Convert cpu native uint64_t to 64bit big endian
>> + * @param

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pktio: add option to enable and disable ipc pktio

[Maxim Uvarov]

Merged with change.

Will see not what CI show.

Thanks,
Maxim.

On 02/18/16 14:21, Elo, Matias (Nokia - FI/Espoo) wrote:

Looks good to me assuming you rename PKTIO_IPC to _ODP_PKTIO_IPC on apply.

Reviewed-by: Matias Elo 



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT Maxim
Uvarov
Sent: Thursday, February 18, 2016 11:46 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCHv4] linux-generic: pktio: add option to enable
and disable ipc pktio

With more options to enable/disable features it's more easy to isolate
and debug problem if any. For now I have suspitious that in CI make check
runs in parallel with other make checks which share the same pool memory.
I.e. one process can corrupt memory for other process. Moving IPC to option
it will be easy to debug that.

Signed-off-by: Maxim Uvarov 
---
  v4: - fix Matias comments to do things more accurate in .m4

  configure.ac| 3 ++-
  platform/linux-generic/m4/configure.m4  | 1 +
  platform/linux-generic/m4/odp_ipc.m4| 9 +
  platform/linux-generic/odp_pool.c   | 4 
  platform/linux-generic/pktio/io_ops.c   | 2 ++
  platform/linux-generic/test/Makefile.am | 7 +--
  6 files changed, 23 insertions(+), 3 deletions(-)
  create mode 100644 platform/linux-generic/m4/odp_ipc.m4

diff --git a/configure.ac b/configure.ac
index 257f8c3..1aa44d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ AC_SUBST([platform_with_platform_test],
["platform/${with_platform}/test"])
  # Prepare default values for platform specific optional features

##

  netmap_support=no
+pktio_ipc_support=no


##

  # Run platform specific checks and settings
@@ -102,7 +103,7 @@ fi

##

  AM_CONDITIONAL([netmap_support], [test x$netmap_support = xyes ])
  AM_CONDITIONAL([HAVE_PCAP], [test $have_pcap = yes])
-
+AM_CONDITIONAL([PKTIO_IPC], [test x$pktio_ipc_support = xyes])

  AC_ARG_WITH([sdk-install-path],
  AC_HELP_STRING([--with-sdk-install-path=DIR path to external libs and
headers],
diff --git a/platform/linux-generic/m4/configure.m4 b/platform/linux-
generic/m4/configure.m4
index 2ac4799..b8c1c52 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -21,6 +21,7 @@ m4_include([platform/linux-generic/m4/odp_openssl.m4])
  m4_include([platform/linux-generic/m4/odp_netmap.m4])
  m4_include([platform/linux-generic/m4/odp_dpdk.m4])
  m4_include([platform/linux-generic/m4/odp_pcap.m4])
+m4_include([platform/linux-generic/m4/odp_ipc.m4])

  AC_CONFIG_FILES([platform/linux-generic/Makefile
 platform/linux-generic/test/Makefile
diff --git a/platform/linux-generic/m4/odp_ipc.m4 b/platform/linux-
generic/m4/odp_ipc.m4
new file mode 100644
index 000..9475031
--- /dev/null
+++ b/platform/linux-generic/m4/odp_ipc.m4
@@ -0,0 +1,9 @@
+#
#
+# Enable IPC pktio support
+#
#
+AC_ARG_ENABLE([pktio_ipc_support],
+[  --enable-pktio_ipc-support  include ipc IO support],
+[if test x$enableval = xyes; then
+   pktio_ipc_support=yes
+   ODP_CFLAGS="$ODP_CFLAGS -DPKTIO_IPC"
+fi])
diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
generic/odp_pool.c
index 78ccc0f..950fa90 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -421,7 +421,11 @@ odp_pool_t _pool_create(const char *name,
  odp_pool_t odp_pool_create(const char *name,
   odp_pool_param_t *params)
  {
+#ifdef PKTIO_IPC
return _pool_create(name, params, ODP_SHM_PROC);
+#else
+   return _pool_create(name, params, 0);
+#endif
  }

  odp_pool_t odp_pool_lookup(const char *name)
diff --git a/platform/linux-generic/pktio/io_ops.c b/platform/linux-
generic/pktio/io_ops.c
index 15aa160..faa72d1 100644
--- a/platform/linux-generic/pktio/io_ops.c
+++ b/platform/linux-generic/pktio/io_ops.c
@@ -21,7 +21,9 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
  #ifdef HAVE_PCAP
&pcap_pktio_ops,
  #endif
+#ifdef PKTIO_IPC
&ipc_pktio_ops,
+#endif
&tap_pktio_ops,
&sock_mmap_pktio_ops,
&sock_mmsg_pktio_ops,
diff --git a/platform/linux-generic/test/Makefile.am b/platform/linux-
generic/test/Makefile.am
index 1011437..4bf24cb 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -1,12 +1,11 @@
  include $(top_srcdir)/test/Makefile.inc
  TESTS_ENVIRONMENT += TEST_DIR=${top_builddir}/test/validation

-ODP_MODULES = pktio pktio_ipc ring
+ODP_MODULES = pktio ring

  if test_vald
  TESTS = pktio/pktio_run \
pktio/pktio_run_tap \
-   pk

Re: [lng-odp] why odp driver can not use odp api?

[Mike Holmes]

On 18 February 2016 at 06:33, Maxim Uvarov  wrote:

> Hello,
>
> Does someone have clear view why odp driver can not use odp api functions?
> Can you please explain why code should be duplicated?
>

I thought we defined these at least

Required change to an existing api just to solve a problem for a driver
will not impact the application api, they are different use cases, one is a
high level abstraction the other attaching to HW.

Isolation of changes, there will be tens of independent drivers that should
continue to link with a stable driver interface whilst the application
interface continues to evolve for application needs

Implementer sanity, a driver writer includes only the driver api and does
not have to deal with anything else in the full api.




>
> *) odp driver here means pktio interface to NIC implemented as driver.
>
>
> Thank you,
> Maxim.
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] why odp driver can not use odp api?

[Maxim Uvarov]

On 02/18/16 14:58, Mike Holmes wrote:



On 18 February 2016 at 06:33, Maxim Uvarov > wrote:


Hello,

Does someone have clear view why odp driver can not use odp api
functions?
Can you please explain why code should be duplicated?


I thought we defined these at least

Required change to an existing api just to solve a problem for a 
driver will not impact the application api, they are different use 
cases, one is a high level abstraction the other attaching to HW.




change to solve problem means that there is problem. It does not matter 
where it is but it has to be fixed.


Isolation of changes, there will be tens of independent drivers that 
should continue to link with a stable driver interface whilst the 
application interface continues to evolve for application needs


Implementer sanity, a driver writer includes only the driver api and 
does not have to deal with anything else in the full api.


Driver interface in current context is separate thing. In my 
understanding it's set of structs which link driver and odp library. But 
ODP driver must include ODP api and reference to types defined in API. 
There should be no any local byte swap or atomic functions and what is 
else implemented in api.


Maxim.





*) odp driver here means pktio interface to NIC implemented as driver.


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




--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"



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

Re: [lng-odp] [API-NEXT PATCH] api: time: fix typo for cmp function

[Maxim Uvarov]

Merged,
Maxim.

On 02/17/16 18:53, Zoltan Kiss wrote:

Signed-off-by: Zoltan Kiss 

On 17/02/16 15:34, Ivan Khoronzhuk wrote:

Signed-off-by: Ivan Khoronzhuk 
---
  include/odp/api/time.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/time.h b/include/odp/api/time.h
index efc5478..85692ec 100644
--- a/include/odp/api/time.h
+++ b/include/odp/api/time.h
@@ -119,7 +119,9 @@ odp_time_t odp_time_global_from_ns(uint64_t ns);
   * @param t2Second time
   * @param t1First time
   *
- * @retval <0 if t2 < t1, >0 if t1 = t2, 1 if t2 > t1
+ * @retval <0 when t2 < t1
+ * @retval  0 when t2 == t1
+ * @retval >0 when t2 > t1
   */
  int odp_time_cmp(odp_time_t t2, odp_time_t t1);



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


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

[lng-odp] [API-NEXT PATCHv2 1/4] api: crypto: add odp_crypto_capability() api

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 include/odp/api/spec/crypto.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 41beedb..81e4621 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
 } odp_crypto_op_result_t;
 
 /**
+ * Crypto capabilities
+ */
+typedef struct odp_crypto_capability_t {
+   /** Maximum number of sessions */
+   unsigned max_sessions;
+} odp_crypto_capability_t;
+
+/**
+ * Get crypto capabilities
+ *
+ * @param[out] capability Pointer to capability structure for output
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_crypto_capability(odp_crypto_capability_t *capability);
+
+/**
  * Crypto session creation (synchronous)
  *
  * @param paramsSession parameters
-- 
2.5.0

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

[lng-odp] [API-NEXT PATCHv2 2/4] linux-generic: crypto: implement odp_crypto_capability()

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/odp_crypto.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/platform/linux-generic/odp_crypto.c 
b/platform/linux-generic/odp_crypto.c
index 08b479d..bf743dc 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -597,6 +597,13 @@ int process_sha256_params(odp_crypto_generic_session_t 
*session,
return 0;
 }
 
+int odp_crypto_capability(odp_crypto_capability_t *capability)
+{
+   capability->max_sessions = MAX_SESSIONS;
+
+   return 0;
+}
+
 int
 odp_crypto_session_create(odp_crypto_session_params_t *params,
  odp_crypto_session_t *session_out,
-- 
2.5.0

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

[lng-odp] [API-NEXT PATCHv2 3/4] validation: crypto: use odp_pool_param_init() instead of memset()

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 test/validation/crypto/crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/validation/crypto/crypto.c b/test/validation/crypto/crypto.c
index a0411c6..b6d06b6 100644
--- a/test/validation/crypto/crypto.c
+++ b/test/validation/crypto/crypto.c
@@ -36,7 +36,7 @@ int crypto_init(void)
return -1;
}
 
-   memset(¶ms, 0, sizeof(params));
+   odp_pool_param_init(¶ms);
params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
-- 
2.5.0

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

[lng-odp] [API-NEXT PATCHv2 4/4] validation: crypto: add unit test for odp_crypto_capability()

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 test/validation/crypto/crypto.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/test/validation/crypto/crypto.c b/test/validation/crypto/crypto.c
index b6d06b6..8f4ce87 100644
--- a/test/validation/crypto/crypto.c
+++ b/test/validation/crypto/crypto.c
@@ -26,6 +26,8 @@ int crypto_init(void)
odp_pool_param_t params;
odp_pool_t pool;
odp_queue_t out_queue;
+   odp_crypto_capability_t capability;
+   int rc;
 
if (0 != odp_init_global(NULL, NULL)) {
fprintf(stderr, "error: odp_init_global() failed.\n");
@@ -36,6 +38,12 @@ int crypto_init(void)
return -1;
}
 
+   rc = odp_crypto_capability(&capability);
+   if (rc != 0) {
+   fprintf(stderr, "error: unable to get crypto capabilities.\n");
+   return -1;
+   }
+
odp_pool_param_init(¶ms);
params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
-- 
2.5.0

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

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

[Bill Fischofer]

Thanks, all.  v2 submitted to fix the typo Petri noted.

On Thu, Feb 18, 2016 at 5:23 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Yes that’s the idea, but those can be added later on top of this initial
> definition.
>
>
>
> We’d need to decide, if capability struct lists algos supported OR algos
> supported on HW (and demand that everything is always implemented either in
> SW or HW). Maybe it makes sense to allow low end or domain targeted
> implementations (which would not implement all algos) – and thus list algos
> supported.
>
>
>
> -Petri
>
>
>
>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *EXT
> Nikhil Agarwal
> *Sent:* Thursday, February 18, 2016 12:09 PM
> *To:* Bala Manoharan ; Bill Fischofer <
> bill.fischo...@linaro.org>
>
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add
> odp_crypto_capability() api
>
>
>
> Shall supported algos be add in crypto capabilities?
>
>
>
> Regards
>
> Nikhil
>
>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org
> ] *On Behalf Of *Bala Manoharan
> *Sent:* Thursday, February 18, 2016 10:40 AM
> *To:* Bill Fischofer 
> *Cc:* LNG ODP Mailman List 
> *Subject:* Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add
> odp_crypto_capability() api
>
>
>
> For the series:
>
> Reviewed-by: Balasubramanian Manoharan 
>
>
> Regards,
> Bala
>
>
>
> On 18 February 2016 at 01:07, Bill Fischofer 
> wrote:
>
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/spec/crypto.h | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index 41beedb..eaacff1 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
>  } odp_crypto_op_result_t;
>
>  /**
> + * Crypto capabilities
> + */
> +typedef struct odp_crypto_capability_t {
> +   /** Maximum number of sessions */
> +   unsigned max_sessions;
> +} odp_crypto_capability_t;
> +
> +/**
> + * Get crypto capabilities
> + *
> + * @param[out] capability Pointer to capability structrue for output
> + *
> + * @retval 0 on success
> + * @retval <0 on failure
> + */
> +int odp_crypto_capability(odp_crypto_capability_t *capability);
> +
> +/**
>   * Crypto session creation (synchronous)
>   *
>   * @param paramsSession parameters
> --
> 2.5.0
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv3 1/6] linux-generic:tm:Add missing name table initialization call.

[Maxim Uvarov]

On 02/18/16 05:03, Bill Fischofer wrote:

From: Barry Spinney 

This patch adds a call from odp_init.c to _odp_int_name_tbl_init().

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
  platform/linux-generic/include/odp_internal.h | 3 ++-
  platform/linux-generic/include/odp_timer_wheel_internal.h | 8 
  platform/linux-generic/odp_init.c | 1 +
  3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_internal.h 
b/platform/linux-generic/include/odp_internal.h
index d7b71ca..991f33f 100644
--- a/platform/linux-generic/include/odp_internal.h
+++ b/platform/linux-generic/include/odp_internal.h
@@ -4,7 +4,6 @@
   * SPDX-License-Identifier: BSD-3-Clause
   */
  
-

  /**
   * @file
   *
@@ -107,6 +106,8 @@ int odp_time_term_global(void);
  
  int odp_tm_init_global(void);
  
+void _odp_int_name_tbl_init(void);

+
  void _odp_flush_caches(void);
  
  int odp_cpuinfo_parser(FILE *file, odp_system_info_t *sysinfo);

diff --git a/platform/linux-generic/include/odp_timer_wheel_internal.h 
b/platform/linux-generic/include/odp_timer_wheel_internal.h
index 0e5828f..54abb77 100644
--- a/platform/linux-generic/include/odp_timer_wheel_internal.h
+++ b/platform/linux-generic/include/odp_timer_wheel_internal.h
@@ -16,15 +16,15 @@ extern "C" {
  #include 
  #include 
  
-/* Note that ALL times in this API are in units of processor/cpu clock

- * cycles!
- */
  typedef uint64_t _odp_timer_wheel_t;
  
  #define _ODP_INT_TIMER_WHEEL_INVALID  0
  
  _odp_timer_wheel_t _odp_timer_wheel_create(uint32_t max_concurrent_timers,

-  uint64_t current_time);
+  void*tm_system);
+
+void _odp_timer_wheel_start(_odp_timer_wheel_t timer_wheel,
+   uint64_t   current_time);
  
  /* _odp_int_timer_wheel_curr_time_update should be called before the first

   * call to _odp_int_timer_wheel_insert, _odp_int_timer_wheel_next, etc..
diff --git a/platform/linux-generic/odp_init.c 
b/platform/linux-generic/odp_init.c
index a8c91a5..fdc5981 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -96,6 +96,7 @@ int odp_init_global(const odp_init_t *params,
return -1;
}
  
+	_odp_int_name_tbl_init();

return 0;
  
  init_failed:

Does that apply now? We have stages and I do not see stage line here.

_odp_int_name_tbl_init() has to be odp_tm_init_global() and have 
corresponding in odp_init_global().

I.e. the same thing as all other apis do.

Maxim.





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

[lng-odp] [PATCH v1] validation: classification: add test case for odp_cos_drop() function

[Balasubramanian Manoharan]

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

Signed-off-by: Balasubramanian Manoharan 
---
 test/validation/classification/odp_classification_basic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/test/validation/classification/odp_classification_basic.c 
b/test/validation/classification/odp_classification_basic.c
index 81077b6..8fbad5f 100644
--- a/test/validation/classification/odp_classification_basic.c
+++ b/test/validation/classification/odp_classification_basic.c
@@ -215,8 +215,11 @@ void classification_test_cos_set_drop(void)
 
retval = odp_cos_drop_set(cos_drop, ODP_COS_DROP_POOL);
CU_ASSERT(retval == 0);
+   CU_ASSERT(ODP_COS_DROP_POOL == odp_cos_drop(cos_drop));
+
retval = odp_cos_drop_set(cos_drop, ODP_COS_DROP_NEVER);
CU_ASSERT(retval == 0);
+   CU_ASSERT(ODP_COS_DROP_NEVER == odp_cos_drop(cos_drop));
odp_cos_destroy(cos_drop);
odp_pool_destroy(pool);
odp_queue_destroy(queue);
-- 
1.9.1

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

Re: [lng-odp] [API-NEXT PATCHv3 1/6] linux-generic:tm:Add missing name table initialization call.

[Bill Fischofer]

This was just a rebase.  I agree we should add a stage.  I'll do that in a
separate patch if this one is acceptable.  Or would you prefer to see that
added directly here?

On Thu, Feb 18, 2016 at 6:41 AM, Maxim Uvarov 
wrote:

> On 02/18/16 05:03, Bill Fischofer wrote:
>
>> From: Barry Spinney 
>>
>> This patch adds a call from odp_init.c to _odp_int_name_tbl_init().
>>
>> Signed-off-by: Barry Spinney 
>> Signed-off-by: Bill Fischofer 
>> ---
>>   platform/linux-generic/include/odp_internal.h | 3 ++-
>>   platform/linux-generic/include/odp_timer_wheel_internal.h | 8 
>>   platform/linux-generic/odp_init.c | 1 +
>>   3 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_internal.h
>> b/platform/linux-generic/include/odp_internal.h
>> index d7b71ca..991f33f 100644
>> --- a/platform/linux-generic/include/odp_internal.h
>> +++ b/platform/linux-generic/include/odp_internal.h
>> @@ -4,7 +4,6 @@
>>* SPDX-License-Identifier: BSD-3-Clause
>>*/
>>   -
>>   /**
>>* @file
>>*
>> @@ -107,6 +106,8 @@ int odp_time_term_global(void);
>> int odp_tm_init_global(void);
>>   +void _odp_int_name_tbl_init(void);
>> +
>>   void _odp_flush_caches(void);
>> int odp_cpuinfo_parser(FILE *file, odp_system_info_t *sysinfo);
>> diff --git a/platform/linux-generic/include/odp_timer_wheel_internal.h
>> b/platform/linux-generic/include/odp_timer_wheel_internal.h
>> index 0e5828f..54abb77 100644
>> --- a/platform/linux-generic/include/odp_timer_wheel_internal.h
>> +++ b/platform/linux-generic/include/odp_timer_wheel_internal.h
>> @@ -16,15 +16,15 @@ extern "C" {
>>   #include 
>>   #include 
>>   -/* Note that ALL times in this API are in units of processor/cpu clock
>> - * cycles!
>> - */
>>   typedef uint64_t _odp_timer_wheel_t;
>> #define _ODP_INT_TIMER_WHEEL_INVALID  0
>> _odp_timer_wheel_t _odp_timer_wheel_create(uint32_t
>> max_concurrent_timers,
>> -  uint64_t current_time);
>> +  void*tm_system);
>> +
>> +void _odp_timer_wheel_start(_odp_timer_wheel_t timer_wheel,
>> +   uint64_t   current_time);
>> /* _odp_int_timer_wheel_curr_time_update should be called before the
>> first
>>* call to _odp_int_timer_wheel_insert, _odp_int_timer_wheel_next, etc..
>> diff --git a/platform/linux-generic/odp_init.c
>> b/platform/linux-generic/odp_init.c
>> index a8c91a5..fdc5981 100644
>> --- a/platform/linux-generic/odp_init.c
>> +++ b/platform/linux-generic/odp_init.c
>> @@ -96,6 +96,7 @@ int odp_init_global(const odp_init_t *params,
>> return -1;
>> }
>>   + _odp_int_name_tbl_init();
>> return 0;
>> init_failed:
>>
> Does that apply now? We have stages and I do not see stage line here.
>
> _odp_int_name_tbl_init() has to be odp_tm_init_global() and have
> corresponding in odp_init_global().
> I.e. the same thing as all other apis do.
>
> Maxim.
>
>
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv3 4/6] test/validation/traffic_mngr: Add the new traffic_mngr tests.

[Maxim Uvarov]

On 02/18/16 05:03, Bill Fischofer wrote:

+static void busy_wait(uint64_t nanoseconds)
+{
+   odp_time_t start_time, end_time;
+   uint32_t   cnt;
+
+   start_time = odp_time_local();
+   end_time   = odp_time_sum(start_time,
+ odp_time_local_from_ns(nanoseconds));
+
+   while (odp_time_cmp(odp_time_local(), end_time) < 0)
+   for (cnt = 1; cnt <= 10; cnt++)
+   busy_wait_counter++;
+}

incrementing cnt looks like hack. I think odp_cpu_pause() can be used here.

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

[lng-odp] [Bug 2016] validation: add test case for odp_cos_drop()

[bugzilla-daemon]

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

--- Comment #1 from Bala Manoharan  ---
v1 submitted: https://patches.linaro.org/patch/62171/

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv3 4/6] test/validation/traffic_mngr: Add the new traffic_mngr tests.

[Maxim Uvarov]

On 02/18/16 05:03, Bill Fischofer wrote:

+
+static odp_bool_t approx_eq32(uint32_t val, uint32_t correct)
+{
+   uint64_t low_bound, val_times_100, high_bound;
+
+   if (val == correct)
+   return true;
+
+   low_bound = 98  * (uint64_t)correct;
+   val_times_100 = 100 * (uint64_t)val;
+   high_bound= 102 * (uint64_t)correct;
+
+   if ((low_bound <= val_times_100) && (val_times_100 <= high_bound))
+   return true;
+   else
+   return false;
+}


usually checkpatch.pl warns that else  word is not needed here.

I just realized that in some places in code we use TRUE and FALSE, in 
other places it's true and false,
and current odp_bool_t is int and api does not say which exactly values 
it wants to see.


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

Re: [lng-odp] [API-NEXT PATCHv3 4/6] test/validation/traffic_mngr: Add the new traffic_mngr tests.

[Maxim Uvarov]

On 02/18/16 05:03, Bill Fischofer wrote:

+   odp_pool_param_init(&pool_param);
+   odp_pktio_param_init(&pktio_param);
+
+   pktio_param.in_mode = ODP_PKTIN_MODE_DIRECT;
+   pool_param.pkt.num  = 10 * MAX_PKTS;
+   pool_param.type = ODP_POOL_PACKET;


Just my preference to have init code as match as possible to setting code.


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

Re: [lng-odp] [API-NEXT PATCHv3 4/6] test/validation/traffic_mngr: Add the new traffic_mngr tests.

[Bill Fischofer]

Agreed.  Again, this was just a rebase of Barry's earlier patch that
predated that routine.  I can post a follow-on patch to address this.

On Thu, Feb 18, 2016 at 6:52 AM, Maxim Uvarov 
wrote:

> On 02/18/16 05:03, Bill Fischofer wrote:
>
>> +static void busy_wait(uint64_t nanoseconds)
>> +{
>> +   odp_time_t start_time, end_time;
>> +   uint32_t   cnt;
>> +
>> +   start_time = odp_time_local();
>> +   end_time   = odp_time_sum(start_time,
>> + odp_time_local_from_ns(nanoseconds));
>> +
>> +   while (odp_time_cmp(odp_time_local(), end_time) < 0)
>> +   for (cnt = 1; cnt <= 10; cnt++)
>> +   busy_wait_counter++;
>> +}
>>
> incrementing cnt looks like hack. I think odp_cpu_pause() can be used here.
>
> Maxim.
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv3 4/6] test/validation/traffic_mngr: Add the new traffic_mngr tests.

[Maxim Uvarov]

On 02/18/16 05:03, Bill Fischofer wrote:

+static void flush_leftover_pkts(odp_tm_t odp_tm, odp_pktio_t pktio)
+{
+   odp_packet_t rcv_pkt;
+   odp_time_t   start_time, current_time, duration;
+   uint64_t min_timeout_ns, max_timeout_ns, duration_ns;
+   int  rc;
+
+   /* Set the timeout to be at least 10 milliseconds and at most 100
+* milliseconds */
+   min_timeout_ns = 1000ULL;

10 * ODP_TIME_MSEC_IN_NS

+   max_timeout_ns = 1ULL;

100 * ODP_TIME_MSEC_IN_NS

+   start_time = odp_time_local();


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

Re: [lng-odp] [API-NEXT PATCHv3 1/6] linux-generic:tm:Add missing name table initialization call.

[Maxim Uvarov]

On 02/18/16 15:51, Bill Fischofer wrote:
This was just a rebase.  I agree we should add a stage.  I'll do that 
in a separate patch if this one is acceptable.  Or would you prefer to 
see that added directly here?


If possible that changes should be in that serries to not postpone clean 
up things.

I think better is directly in that patch.

Maxim.



On Thu, Feb 18, 2016 at 6:41 AM, Maxim Uvarov > wrote:


On 02/18/16 05:03, Bill Fischofer wrote:

From: Barry Spinney mailto:spin...@ezchip.com>>

This patch adds a call from odp_init.c to
_odp_int_name_tbl_init().

Signed-off-by: Barry Spinney mailto:spin...@ezchip.com>>
Signed-off-by: Bill Fischofer mailto:bill.fischo...@linaro.org>>
---
  platform/linux-generic/include/odp_internal.h  | 3 ++-
platform/linux-generic/include/odp_timer_wheel_internal.h | 8

  platform/linux-generic/odp_init.c  | 1 +
  3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_internal.h
b/platform/linux-generic/include/odp_internal.h
index d7b71ca..991f33f 100644
--- a/platform/linux-generic/include/odp_internal.h
+++ b/platform/linux-generic/include/odp_internal.h
@@ -4,7 +4,6 @@
   * SPDX-License-Identifier: BSD-3-Clause
   */
  -
  /**
   * @file
   *
@@ -107,6 +106,8 @@ int odp_time_term_global(void);
int odp_tm_init_global(void);
  +void _odp_int_name_tbl_init(void);
+
  void _odp_flush_caches(void);
int odp_cpuinfo_parser(FILE *file, odp_system_info_t
*sysinfo);
diff --git
a/platform/linux-generic/include/odp_timer_wheel_internal.h
b/platform/linux-generic/include/odp_timer_wheel_internal.h
index 0e5828f..54abb77 100644
--- a/platform/linux-generic/include/odp_timer_wheel_internal.h
+++ b/platform/linux-generic/include/odp_timer_wheel_internal.h
@@ -16,15 +16,15 @@ extern "C" {
  #include 
  #include 
  -/* Note that ALL times in this API are in units of
processor/cpu clock
- * cycles!
- */
  typedef uint64_t _odp_timer_wheel_t;
#define _ODP_INT_TIMER_WHEEL_INVALID  0
_odp_timer_wheel_t _odp_timer_wheel_create(uint32_t
max_concurrent_timers,
-  uint64_t current_time);
+  void *tm_system);
+
+void _odp_timer_wheel_start(_odp_timer_wheel_t timer_wheel,
+   uint64_t  current_time);
/* _odp_int_timer_wheel_curr_time_update should be called
before the first
   * call to _odp_int_timer_wheel_insert,
_odp_int_timer_wheel_next, etc..
diff --git a/platform/linux-generic/odp_init.c
b/platform/linux-generic/odp_init.c
index a8c91a5..fdc5981 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -96,6 +96,7 @@ int odp_init_global(const odp_init_t *params,
return -1;
}
  + _odp_int_name_tbl_init();
return 0;
init_failed:

Does that apply now? We have stages and I do not see stage line here.

_odp_int_name_tbl_init() has to be odp_tm_init_global() and have
corresponding in odp_init_global().
I.e. the same thing as all other apis do.

Maxim.





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




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

Re: [lng-odp] [API-NEXT PATCHv3 1/6] linux-generic:tm:Add missing name table initialization call.

[Bill Fischofer]

Ok, I'll do a v4 based on all of your review comments.  Please advise when
they're complete.

On Thu, Feb 18, 2016 at 7:14 AM, Maxim Uvarov 
wrote:

> On 02/18/16 15:51, Bill Fischofer wrote:
>
>> This was just a rebase.  I agree we should add a stage.  I'll do that in
>> a separate patch if this one is acceptable.  Or would you prefer to see
>> that added directly here?
>>
>
> If possible that changes should be in that serries to not postpone clean
> up things.
> I think better is directly in that patch.
>
> Maxim.
>
>
>> On Thu, Feb 18, 2016 at 6:41 AM, Maxim Uvarov > > wrote:
>>
>> On 02/18/16 05:03, Bill Fischofer wrote:
>>
>> From: Barry Spinney > >
>>
>> This patch adds a call from odp_init.c to
>> _odp_int_name_tbl_init().
>>
>> Signed-off-by: Barry Spinney > >
>> Signed-off-by: Bill Fischofer > >
>>
>> ---
>>   platform/linux-generic/include/odp_internal.h  | 3 ++-
>> platform/linux-generic/include/odp_timer_wheel_internal.h | 8
>> 
>>   platform/linux-generic/odp_init.c  | 1 +
>>   3 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_internal.h
>> b/platform/linux-generic/include/odp_internal.h
>> index d7b71ca..991f33f 100644
>> --- a/platform/linux-generic/include/odp_internal.h
>> +++ b/platform/linux-generic/include/odp_internal.h
>> @@ -4,7 +4,6 @@
>>* SPDX-License-Identifier: BSD-3-Clause
>>*/
>>   -
>>   /**
>>* @file
>>*
>> @@ -107,6 +106,8 @@ int odp_time_term_global(void);
>> int odp_tm_init_global(void);
>>   +void _odp_int_name_tbl_init(void);
>> +
>>   void _odp_flush_caches(void);
>> int odp_cpuinfo_parser(FILE *file, odp_system_info_t
>> *sysinfo);
>> diff --git
>> a/platform/linux-generic/include/odp_timer_wheel_internal.h
>> b/platform/linux-generic/include/odp_timer_wheel_internal.h
>> index 0e5828f..54abb77 100644
>> --- a/platform/linux-generic/include/odp_timer_wheel_internal.h
>> +++ b/platform/linux-generic/include/odp_timer_wheel_internal.h
>> @@ -16,15 +16,15 @@ extern "C" {
>>   #include 
>>   #include 
>>   -/* Note that ALL times in this API are in units of
>> processor/cpu clock
>> - * cycles!
>> - */
>>   typedef uint64_t _odp_timer_wheel_t;
>> #define _ODP_INT_TIMER_WHEEL_INVALID  0
>> _odp_timer_wheel_t _odp_timer_wheel_create(uint32_t
>> max_concurrent_timers,
>> -  uint64_t current_time);
>> +  void *tm_system);
>> +
>> +void _odp_timer_wheel_start(_odp_timer_wheel_t timer_wheel,
>> +   uint64_t  current_time);
>> /* _odp_int_timer_wheel_curr_time_update should be called
>> before the first
>>* call to _odp_int_timer_wheel_insert,
>> _odp_int_timer_wheel_next, etc..
>> diff --git a/platform/linux-generic/odp_init.c
>> b/platform/linux-generic/odp_init.c
>> index a8c91a5..fdc5981 100644
>> --- a/platform/linux-generic/odp_init.c
>> +++ b/platform/linux-generic/odp_init.c
>> @@ -96,6 +96,7 @@ int odp_init_global(const odp_init_t *params,
>> return -1;
>> }
>>   + _odp_int_name_tbl_init();
>> return 0;
>> init_failed:
>>
>> Does that apply now? We have stages and I do not see stage line here.
>>
>> _odp_int_name_tbl_init() has to be odp_tm_init_global() and have
>> corresponding in odp_init_global().
>> I.e. the same thing as all other apis do.
>>
>> Maxim.
>>
>>
>>
>>
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org 
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 2031] CID 157958: Integer handling issues: timer.c

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

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

--- Comment #2 from Maxim Uvarov  ---
CU_ASSERT is probably missing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH V2 0/2] linux-generic: fix BUG 2027 - ODP cpumask creation issues

[Maxim Uvarov]

ping. Please review.

Maxim.

On 02/16/16 17:54, Gary S. Robertson wrote:

This patch revision identifies linux-generic as the component being modified,
per Maxim U.'s suggested correction.
Skipped repeat of the problem description and chosen path to solution in
this revision - see the cover email for the initial submission for those
details as needed.

Gary S. Robertson (2):
   linux-generic: Correct worker count calculation in tests
   linux-generic: Make cpu detection work with NO_HZ_FULL

  platform/linux-generic/include/odp_internal.h |  31 ++--
  platform/linux-generic/odp_cpumask_task.c |  45 +++--
  platform/linux-generic/odp_init.c | 230 +-
  platform/linux-generic/odp_system_info.c  |  14 +-
  test/api_test/odp_common.c|   4 +-
  test/api_test/odp_ring_test.c |   4 +-
  test/performance/odp_atomic.c |   9 +-
  test/validation/cpumask/cpumask.c |   2 +-
  test/validation/shmem/shmem.c |   5 +-
  test/validation/timer/timer.c |  16 +-
  10 files changed, 298 insertions(+), 62 deletions(-)



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

[lng-odp] [Bug 2025] odp/test/api_tests dir is not used and the code is stale

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

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

--- Comment #2 from Maxim Uvarov  ---
commit e7da5814397e15f67e4b6381dfe4d09120a1a041
Author: Maxim Uvarov 
Date:   Wed Feb 17 13:16:51 2016 +0300

helper: remove ring code

Remove ring and dead api-next code. In api-next pktio ipc patches
moved ring code to linux-generic and updated that test case to
the latest odp api. If we ipc pktio will be accepted to master
than current api-next ring test will be used.

Signed-off-by: Maxim Uvarov 
Reviewed-by Mike Holmes 

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 2023] linux-generic: validation: fix dependency for tests-validation.env

[bugzilla-daemon]

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

Bill Fischofer  changed:

   What|Removed |Added

 CC||bill.fischo...@linaro.org
   Assignee|lng-odp@lists.linaro.org|anders.rox...@linaro.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1940] linux-generic: timer: race for odp_timer_pool

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Maxim Uvarov  ---
f73b184 linux-generic: timer use SIGEV_THREAD_ID

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1615] odp_timer fails in CI with Segmentation fault

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

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

--- Comment #21 from Maxim Uvarov  ---
f73b184 linux-generic: timer use SIGEV_THREAD_ID

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1549] Untested API parse_tcp

[bugzilla-daemon]

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

Bill Fischofer  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |NON REPRODUCIBLE

--- Comment #4 from Bill Fischofer  ---
Fixed by other classifier updates that Bala has made over the past month.  No
longer relevant.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1548] Untested API parse_ipv6

[bugzilla-daemon]

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

Bill Fischofer  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |NON REPRODUCIBLE

--- Comment #4 from Bill Fischofer  ---
Fixed by other classifier updates made by Bala over the past month.  No longer
relevant.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1449] odp_timer_test core dump

[bugzilla-daemon]

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

Maxim Uvarov  changed:

   What|Removed |Added

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

--- Comment #14 from Maxim Uvarov  ---
f73b184 linux-generic: timer use SIGEV_THREAD_ID

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv3 6/6] odp build system: Changed configure.ac and test/validation/Makefile.am so that traffic_mngr tests are built.

[Maxim Uvarov]

that patch is better to merge to corresponding patches. They strange see 
only Makefile changes in separate file.


Maxim.

On 02/18/16 05:03, Bill Fischofer wrote:

From: Barry Spinney 

These two changes now cause the traffic_mngr validation tests to be
automatically built as part of the full ODP build.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
  configure.ac| 1 +
  test/validation/Makefile.am | 1 +
  2 files changed, 2 insertions(+)

diff --git a/configure.ac b/configure.ac
index 257f8c3..161c57e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -361,6 +361,7 @@ AC_CONFIG_FILES([Makefile
 test/validation/thread/Makefile
 test/validation/time/Makefile
 test/validation/timer/Makefile
+test/validation/traffic_mngr/Makefile
 test/validation/shmem/Makefile
 test/validation/system/Makefile
 test/miscellaneous/Makefile
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index cdd5a84..074da26 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -19,6 +19,7 @@ ODP_MODULES = atomic \
  thread \
  time \
  timer \
+ traffic_mngr \
  shmem \
  system
  


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

Re: [lng-odp] [API-NEXT PATCHv3 5/6] test/validation/traffic_mngr: Add the .gitignore and Makefile.am files.

[Maxim Uvarov]

this patch also should be merged with patch 6 and merged with 
corresponding code.


Maxim.

On 02/18/16 05:03, Bill Fischofer wrote:

From: Barry Spinney 

This patch now adds the Makefile for the traffic_mngr tests.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
  test/validation/traffic_mngr/.gitignore  |  1 +
  test/validation/traffic_mngr/Makefile.am | 10 ++
  2 files changed, 11 insertions(+)
  create mode 100644 test/validation/traffic_mngr/.gitignore
  create mode 100644 test/validation/traffic_mngr/Makefile.am

diff --git a/test/validation/traffic_mngr/.gitignore 
b/test/validation/traffic_mngr/.gitignore
new file mode 100644
index 000..efd07a2
--- /dev/null
+++ b/test/validation/traffic_mngr/.gitignore
@@ -0,0 +1 @@
+traffic_mngr_main
diff --git a/test/validation/traffic_mngr/Makefile.am 
b/test/validation/traffic_mngr/Makefile.am
new file mode 100644
index 000..35e689a
--- /dev/null
+++ b/test/validation/traffic_mngr/Makefile.am
@@ -0,0 +1,10 @@
+include ../Makefile.inc
+
+noinst_LTLIBRARIES = libtesttraffic_mngr.la
+libtesttraffic_mngr_la_SOURCES = traffic_mngr.c
+
+test_PROGRAMS = traffic_mngr_main$(EXEEXT)
+dist_traffic_mngr_main_SOURCES = traffic_mngr_main.c
+traffic_mngr_main_LDADD = libtesttraffic_mngr.la -lm $(LIBCUNIT_COMMON) 
$(LIBODP)
+
+EXTRA_DIST = traffic_mngr.h


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

Re: [lng-odp] [PATCH] validation: scheduler: correct pause/resume sequence

[Ivan Khoronzhuk]

ping

On 16.02.16 16:02, Ivan Khoronzhuk wrote:

When test for single thread is finished the following test for
many threads can be started, and for some implementations can
happen that future one event can arrive to main thread, as it was
requested in previous test. As result one event can be lost for rest
threads. So, it's better to pause scheduling for main thread when
it doesn't participate in the multi-threaded test. Also move
pause/resume test closer to beginning, because it's used in tests
before.

Signed-off-by: Ivan Khoronzhuk 
---
  test/validation/scheduler/scheduler.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/test/validation/scheduler/scheduler.c 
b/test/validation/scheduler/scheduler.c
index dcf01c0..c1b61c5 100644
--- a/test/validation/scheduler/scheduler.c
+++ b/test/validation/scheduler/scheduler.c
@@ -1000,6 +1000,8 @@ static void schedule_common(odp_schedule_sync_t sync, int 
num_queues,
args.enable_schd_multi = enable_schd_multi;
args.enable_excl_atomic = 0;/* Not needed with a single CPU */

+   /* resume scheduling in case it was paused */
+   odp_schedule_resume();
fill_queues(&args);

schedule_common_(&args);
@@ -1037,6 +1039,9 @@ static void parallel_execute(odp_schedule_sync_t sync, 
int num_queues,
args->enable_schd_multi = enable_schd_multi;
args->enable_excl_atomic = enable_excl_atomic;

+   /* disable receive events for main thread */
+   exit_schedule_loop();
+
fill_queues(args);

/* Create and launch worker threads */
@@ -1249,6 +1254,9 @@ void scheduler_test_pause_resume(void)
int i;
int local_bufs = 0;

+   /* resume scheduling in case it was paused */
+   odp_schedule_resume();
+
queue = odp_queue_lookup("sched_0_0_n");
CU_ASSERT(queue != ODP_QUEUE_INVALID);

@@ -1296,6 +1304,8 @@ void scheduler_test_pause_resume(void)
}

CU_ASSERT(exit_schedule_loop() == 0);
+
+   odp_schedule_resume();
  }

  static int create_queues(void)
@@ -1556,6 +1566,7 @@ odp_testinfo_t scheduler_suite[] = {
ODP_TEST_INFO(scheduler_test_num_prio),
ODP_TEST_INFO(scheduler_test_queue_destroy),
ODP_TEST_INFO(scheduler_test_groups),
+   ODP_TEST_INFO(scheduler_test_pause_resume),
ODP_TEST_INFO(scheduler_test_parallel),
ODP_TEST_INFO(scheduler_test_atomic),
ODP_TEST_INFO(scheduler_test_ordered),
@@ -1586,7 +1597,6 @@ odp_testinfo_t scheduler_suite[] = {
ODP_TEST_INFO(scheduler_test_multi_mq_mt_prio_a),
ODP_TEST_INFO(scheduler_test_multi_mq_mt_prio_o),
ODP_TEST_INFO(scheduler_test_multi_1q_mt_a_excl),
-   ODP_TEST_INFO(scheduler_test_pause_resume),
ODP_TEST_INFO_NULL,
  };




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

Re: [lng-odp] scheduler_test_wait_time() tolerance

[Zoltan Kiss]

On 17/02/16 16:59, Mike Holmes wrote:



On 17 February 2016 at 11:53, Ivan Khoronzhuk
mailto:ivan.khoronz...@linaro.org>> wrote:



On 17.02.16 18:44, Mike Holmes wrote:

Does this tuning need to be documented in the implementer's guide ?

I thinks, no.


Really, per platform tuning is required but we dont mention it ?


It is not really a platform dependent stuff, this test is inherently 
unreliable, but we don't have a better idea, and adjusting the tolerance 
is just good enough.






On 17 February 2016 at 10:51, Zoltan Kiss
mailto:zoltan.k...@linaro.org>
>>
wrote:



 On 17/02/16 15:24, Ivan Khoronzhuk wrote:

 Hi, Zoltan

 On 17.02.16 17:12, Zoltan Kiss wrote:

 Hi Ivan,

 I haven an another issue related to time API, which
is related to your
 recent patches, particularly this code:

 wait_time = odp_schedule_wait_time(ODP_TIME_SEC_IN_NS);
 ...
 /* check time correctness */
 start_time = odp_time_local();
 for (i = 1; i < 6; i++) {
   odp_schedule(&queue, wait_time);
   printf("%d..", i);
 }
 end_time = odp_time_local();

 diff = odp_time_diff(end_time, start_time);
 ...
 upper_limit = odp_time_local_from_ns(5 *
ODP_TIME_SEC_IN_NS +
 ODP_WAIT_TOLERANCE);

 ...
 CU_ASSERT(odp_time_cmp(diff, upper_limit) <= 0);

 This assert fails every now and then on ODP-DPDK,
because although
 wait_time is 1 sec, and you call odp_schedule() 5
times, you can't
 really have any guarantees how long the delay lasts
between the
 subsequent calls, or how long the printf lasts (or
the function call
 overhead). I think we should come up with something
more accurate
 which doesn't produce false positives like this.

 Regards,

 Zoltan


 That's why I'm used WAIT_TOLERANCE in 20ms. That is
about 2 context
 switches.
 I've tested it on Keystone and on linux-generic. It was
enough.
 If you are testing it on system with more load it's
probably not enough.
 Time spent on printf and schedule calls is not
comparable with such time
 tolerance.
 Did you try to figure out the real delay it takes with
DPDK?


 Nope, it happens quite rarely in CI, and we don't have too
much information about the reasons. I assume it is a momentary
higher load on the system.

 Maybe we should increase it to be 3 or even 4 context
switches.
 Say 40ms, in order to be not so sensitive for some systems.
 #define ODP_WAIT_TOLERANCE(40 * ODP_TIME_MSEC_IN_NS)


 Yes, that might help.



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




--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software
for ARM SoCs
"Work should be fun and collborative, the rest follows"

__



--
Regards,
Ivan Khoronzhuk




--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"

__



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

Re: [lng-odp] scheduler_test_wait_time() tolerance

[Mike Holmes]

On 18 February 2016 at 12:52, Zoltan Kiss  wrote:

>
>
> On 17/02/16 16:59, Mike Holmes wrote:
>
>>
>>
>> On 17 February 2016 at 11:53, Ivan Khoronzhuk
>> mailto:ivan.khoronz...@linaro.org>> wrote:
>>
>>
>>
>> On 17.02.16 18:44, Mike Holmes wrote:
>>
>> Does this tuning need to be documented in the implementer's guide
>> ?
>>
>> I thinks, no.
>>
>>
>> Really, per platform tuning is required but we dont mention it ?
>>
>
> It is not really a platform dependent stuff, this test is inherently
> unreliable, but we don't have a better idea, and adjusting the tolerance is
> just good enough.
>

Thanks


>
>
>>
>>
>> On 17 February 2016 at 10:51, Zoltan Kiss
>> mailto:zoltan.k...@linaro.org>
>> >>
>>
>> wrote:
>>
>>
>>
>>  On 17/02/16 15:24, Ivan Khoronzhuk wrote:
>>
>>  Hi, Zoltan
>>
>>  On 17.02.16 17:12, Zoltan Kiss wrote:
>>
>>  Hi Ivan,
>>
>>  I haven an another issue related to time API, which
>> is related to your
>>  recent patches, particularly this code:
>>
>>  wait_time =
>> odp_schedule_wait_time(ODP_TIME_SEC_IN_NS);
>>  ...
>>  /* check time correctness */
>>  start_time = odp_time_local();
>>  for (i = 1; i < 6; i++) {
>>odp_schedule(&queue, wait_time);
>>printf("%d..", i);
>>  }
>>  end_time = odp_time_local();
>>
>>  diff = odp_time_diff(end_time, start_time);
>>  ...
>>  upper_limit = odp_time_local_from_ns(5 *
>> ODP_TIME_SEC_IN_NS +
>>  ODP_WAIT_TOLERANCE);
>>
>>  ...
>>  CU_ASSERT(odp_time_cmp(diff, upper_limit) <= 0);
>>
>>  This assert fails every now and then on ODP-DPDK,
>> because although
>>  wait_time is 1 sec, and you call odp_schedule() 5
>> times, you can't
>>  really have any guarantees how long the delay lasts
>> between the
>>  subsequent calls, or how long the printf lasts (or
>> the function call
>>  overhead). I think we should come up with something
>> more accurate
>>  which doesn't produce false positives like this.
>>
>>  Regards,
>>
>>  Zoltan
>>
>>
>>  That's why I'm used WAIT_TOLERANCE in 20ms. That is
>> about 2 context
>>  switches.
>>  I've tested it on Keystone and on linux-generic. It was
>> enough.
>>  If you are testing it on system with more load it's
>> probably not enough.
>>  Time spent on printf and schedule calls is not
>> comparable with such time
>>  tolerance.
>>  Did you try to figure out the real delay it takes with
>> DPDK?
>>
>>
>>  Nope, it happens quite rarely in CI, and we don't have too
>> much information about the reasons. I assume it is a momentary
>> higher load on the system.
>>
>>  Maybe we should increase it to be 3 or even 4 context
>> switches.
>>  Say 40ms, in order to be not so sensitive for some
>> systems.
>>  #define ODP_WAIT_TOLERANCE(40 * ODP_TIME_MSEC_IN_NS)
>>
>>
>>  Yes, that might help.
>>
>>
>>
>>  ___
>>  lng-odp mailing list
>> lng-odp@lists.linaro.org 
>> > >>
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org ***│ *Open source software
>> for ARM SoCs
>> "Work should be fun and collborative, the rest follows"
>>
>> __
>>
>>
>>
>> --
>> Regards,
>> Ivan Khoronzhuk
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org ***│ *Open source software for ARM
>> SoCs
>> "Work should be fun and collborative, the rest follows"
>>
>> __
>>
>>
>>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] why odp driver can not use odp api?

[Mike Holmes]

On 18 February 2016 at 07:15, Maxim Uvarov  wrote:

> On 02/18/16 14:58, Mike Holmes wrote:
>
>>
>>
>> On 18 February 2016 at 06:33, Maxim Uvarov > > wrote:
>>
>> Hello,
>>
>> Does someone have clear view why odp driver can not use odp api
>> functions?
>> Can you please explain why code should be duplicated?
>>
>>
>> I thought we defined these at least
>>
>> Required change to an existing api just to solve a problem for a driver
>> will not impact the application api, they are different use cases, one is a
>> high level abstraction the other attaching to HW.
>>
>>
> change to solve problem means that there is problem. It does not matter
> where it is but it has to be fixed.


You need to be solving the problem for the right use case, they are
different, so you fix it for the right audience and do not affect others.


>
>
> Isolation of changes, there will be tens of independent drivers that
>> should continue to link with a stable driver interface whilst the
>> application interface continues to evolve for application needs
>>
>> Implementer sanity, a driver writer includes only the driver api and does
>> not have to deal with anything else in the full api.
>>
>> Driver interface in current context is separate thing. In my
> understanding it's set of structs which link driver and odp library. But
> ODP driver must include ODP api and reference to types defined in API.


No, the application api is full of useless stuff for this use case, no need
to drag TM etc in since a NIC io driver will not use this.


> There should be no any local byte swap or atomic functions and what is
> else implemented in api.


> Maxim.
>
>
>>
>>
>> *) odp driver here means pktio interface to NIC implemented as driver.
>>
>>
>> Thank you,
>> Maxim.
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org 
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>> --
>> Mike Holmes
>> Technical Manager - Linaro Networking Group
>> Linaro.org ***│ *Open source software for ARM
>> SoCs
>> "Work should be fun and collborative, the rest follows"
>>
>>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
"Work should be fun and collborative, the rest follows"
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] pktio stats counters

[Zoltan Kiss]

Hi,

On ODP-DPDK this assert fails every now and then:

https://git.linaro.org/lng/odp.git/blob/refs/heads/api-next:/test/validation/pktio/pktio.c#l1193

The reason is that when you set the interfaces up, there are other 
system services which can hook into the interface creation, and start 
doing stuff. And it often means that they send out packets behind the 
back of pktio[0], which is received by pktio[1], and that changes the 
amount of received bytes there (but not on the sending side). E.g. on my 
system there is mDNS, DHCP, NetBIOS so far which can ruin this test.
ODP-DPDK uses PCAP, which seems not to be able to catch all the outgoing 
packets. I guess on linux-generic we use the kernel stats in the unit 
tests which can do that.

Any idea how to solve this problem?

Regards,

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

[lng-odp] [API-NEXT PATCHv4 1/5] example: tm: remove reference to internal name table init api

[Bill Fischofer]

From: Barry Spinney 

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 example/traffic_mgmt/odp_traffic_mgmt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/example/traffic_mgmt/odp_traffic_mgmt.c 
b/example/traffic_mgmt/odp_traffic_mgmt.c
index d9769d3..216875b 100644
--- a/example/traffic_mgmt/odp_traffic_mgmt.c
+++ b/example/traffic_mgmt/odp_traffic_mgmt.c
@@ -248,9 +248,6 @@ static uint8_t  g_print_tm_stats   = TRUE;
 
 static void tester_egress_fcn(odp_packet_t odp_pkt);
 
-/** @TODO can't call hidden apis in the implementation */
-void _odp_int_name_tbl_init(void);
-
 /* Returns the number of errors encountered. */
 
 static uint32_t create_profile_set(profile_params_set_t *profile_params_set,
@@ -757,7 +754,6 @@ int main(int argc, char *argv[])
 
odp_init_global(&ODP_INIT_PARAMS, &PLATFORM_PARAMS);
odp_init_local(ODP_THREAD_CONTROL);
-   _odp_int_name_tbl_init();
 
if (process_cmd_line_options(argc, argv) < 0)
return -1;
-- 
2.5.0

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

[lng-odp] [API-NEXT PATCHv4 2/5] linux-generic: tm: Add missing name table initialization call.

[Bill Fischofer]

From: Barry Spinney 

This patch adds a call from odp_init.c to _odp_int_name_tbl_init().

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp_internal.h  |  9 +++--
 .../include/odp_name_table_internal.h  |  3 ++-
 .../include/odp_timer_wheel_internal.h |  8 
 platform/linux-generic/odp_init.c  | 23 --
 platform/linux-generic/odp_name_table.c|  9 -
 5 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/platform/linux-generic/include/odp_internal.h 
b/platform/linux-generic/include/odp_internal.h
index d7b71ca..98d6f25 100644
--- a/platform/linux-generic/include/odp_internal.h
+++ b/platform/linux-generic/include/odp_internal.h
@@ -4,7 +4,6 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-
 /**
  * @file
  *
@@ -55,7 +54,9 @@ enum init_stage {
TIMER_INIT = 9,
CRYPTO_INIT = 10,
CLASSIFICATION_INIT = 11,
-   ALL_INIT = 12   /* All init stages completed */
+   TRAFFIC_MNGR_INIT = 12,
+   NAME_TABLE_INIT = 13,
+   ALL_INIT  /* All init stages completed */
 };
 
 extern struct odp_global_data_s odp_global_data;
@@ -106,6 +107,10 @@ int odp_time_init_global(void);
 int odp_time_term_global(void);
 
 int odp_tm_init_global(void);
+int odp_tm_term_global(void);
+
+int _odp_int_name_tbl_init_global(void);
+int _odp_int_name_tbl_term_global(void);
 
 void _odp_flush_caches(void);
 
diff --git a/platform/linux-generic/include/odp_name_table_internal.h 
b/platform/linux-generic/include/odp_name_table_internal.h
index e9a85da..21ae42d 100644
--- a/platform/linux-generic/include/odp_name_table_internal.h
+++ b/platform/linux-generic/include/odp_name_table_internal.h
@@ -52,7 +52,8 @@ uint64_t _odp_int_name_tbl_user_data(_odp_int_name_t 
odp_name);
 
 void _odp_int_name_tbl_stats_print(void);
 
-void _odp_int_name_tbl_init(void);
+int _odp_int_name_tbl_init_global(void);
+int _odp_int_name_tbl_term_global(void);
 
 #ifdef __cplusplus
 }
diff --git a/platform/linux-generic/include/odp_timer_wheel_internal.h 
b/platform/linux-generic/include/odp_timer_wheel_internal.h
index 0e5828f..54abb77 100644
--- a/platform/linux-generic/include/odp_timer_wheel_internal.h
+++ b/platform/linux-generic/include/odp_timer_wheel_internal.h
@@ -16,15 +16,15 @@ extern "C" {
 #include 
 #include 
 
-/* Note that ALL times in this API are in units of processor/cpu clock
- * cycles!
- */
 typedef uint64_t _odp_timer_wheel_t;
 
 #define _ODP_INT_TIMER_WHEEL_INVALID  0
 
 _odp_timer_wheel_t _odp_timer_wheel_create(uint32_t max_concurrent_timers,
-  uint64_t current_time);
+  void*tm_system);
+
+void _odp_timer_wheel_start(_odp_timer_wheel_t timer_wheel,
+   uint64_t   current_time);
 
 /* _odp_int_timer_wheel_curr_time_update should be called before the first
  * call to _odp_int_timer_wheel_insert, _odp_int_timer_wheel_next, etc..
diff --git a/platform/linux-generic/odp_init.c 
b/platform/linux-generic/odp_init.c
index a8c91a5..22edce3 100644
--- a/platform/linux-generic/odp_init.c
+++ b/platform/linux-generic/odp_init.c
@@ -93,7 +93,13 @@ int odp_init_global(const odp_init_t *params,
 
if (odp_tm_init_global()) {
ODP_ERR("ODP traffic manager init failed\n");
-   return -1;
+   goto init_failed;
+   }
+   stage = TRAFFIC_MNGR_INIT;
+
+   if (_odp_int_name_tbl_init_global()) {
+   ODP_ERR("ODP name table init failed\n");
+   goto init_failed;
}
 
return 0;
@@ -114,10 +120,23 @@ int _odp_term_global(enum init_stage stage)
 
switch (stage) {
case ALL_INIT:
+   case NAME_TABLE_INIT:
+   if (_odp_int_name_tbl_term_global()) {
+   ODP_ERR("Name table term failed.\n");
+   rc = -1;
+   }
+   /* Fall through */
+
+   case TRAFFIC_MNGR_INIT:
+   if (odp_tm_term_global()) {
+   ODP_ERR("TM term failed.\n");
+   rc = -1;
+   }
+   /* Fall through */
 
case CLASSIFICATION_INIT:
if (odp_classification_term_global()) {
-   ODP_ERR("ODP classificatio term failed.\n");
+   ODP_ERR("ODP classification term failed.\n");
rc = -1;
}
/* Fall through */
diff --git a/platform/linux-generic/odp_name_table.c 
b/platform/linux-generic/odp_name_table.c
index 610f034..1e43a2c 100644
--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -1181,7 +1181,7 @@ void _odp_int_name_tbl_stats_print(void)
 #endif
 }
 
-void _odp_int_name_tbl_init(void)
+int _odp_int_name_tbl_init_global(void)
 {
name_tbl_t *new_name_tbl;
 
@@ -11

[lng-odp] [API-NEXT PATCHv4 3/5] linux-generic: tm: correct some old comments and stop using cpu cycles

[Bill Fischofer]

From: Barry Spinney 

This patch fixes some incorrect comments regarding the format of the
fixed point integer types used to represent the shaper's token bucket
count values.  Also since the TM and the TM tests were changed to use
odp_time_local() instead of the cpu cycles API's, changed field names
like current_cycles to current_time. Finally this patch does some
minor cosmetic style improvement.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 .../include/odp_traffic_mngr_internal.h| 90 +++---
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/platform/linux-generic/include/odp_traffic_mngr_internal.h 
b/platform/linux-generic/include/odp_traffic_mngr_internal.h
index e09c60a..786d51f 100644
--- a/platform/linux-generic/include/odp_traffic_mngr_internal.h
+++ b/platform/linux-generic/include/odp_traffic_mngr_internal.h
@@ -43,9 +43,6 @@ typedef struct stat  file_stat_t;
 #define TM_QUEUE_MAGIC_NUM   0xBABEBABE
 #define TM_NODE_MAGIC_NUM0xBEEFBEEF
 
-/**> @todo Fill this in with what it's supposed to be */
-#define ODP_CYCLES_PER_SEC 10
-
 /* Macros to convert handles to internal pointers and vice versa. */
 
 #define MAKE_ODP_TM_HANDLE(tm_system)  ((odp_tm_t)(uintptr_t)tm_system)
@@ -150,10 +147,10 @@ typedef struct {
 } tm_prop_t;
 
 typedef struct {
-   uint64_t commit_rate;
-   uint64_t peak_rate;
-   int64_t max_commit; /* Byte cnt as a fp integer with 26 bits. */
-   int64_t max_peak;
+   uint64_t commit_rate; /* Bytes per clk cycle as a 26 bit fp integer */
+   uint64_t peak_rate;   /* Same as commit_rate */
+   int64_t max_commit;   /* Byte cnt as a fp integer with 26 bits. */
+   int64_t max_peak; /* Same as max_commit */
uint64_t max_commit_time_delta;
uint64_t max_peak_time_delta;
uint32_t min_time_delta;
@@ -171,15 +168,17 @@ typedef struct {
tm_shaper_params_t *shaper_params;
tm_sched_params_t *sched_params;
 
-   uint64_t last_update_time; /* In clock cycles. */
+   uint64_t last_update_time;
uint64_t callback_time;
 
/* The shaper token bucket counters are represented as a number of
* bytes in a 64-bit fixed point format where the decimal point is at
-   * bit 24.  (aka int64_24).  In other words, the number of bytes that
-   * commit_cnt represents is "commit_cnt / 2**24".  Hence the
-   * commit_rate and peak_rate are in units of bytes per cycle = "8 *
-   * bits per sec / cycles per sec"
+   * bit 26.  (aka int64_26).  In other words, the number of bytes that
+   * commit_cnt represents is "commit_cnt / 2**26".  The commit_rate and
+   * peak_rate are in units of bytes per nanoseccond, again using a 26-bit
+   * fixed point integer.  Alternatively, ignoring the fixed point,
+   * the number of bytes that x nanosecconds represents is equal to
+   * "(rate * nanosecconds) / 2**26".
*/
int64_t commit_cnt; /* Note token counters can go slightly negative */
int64_t peak_cnt; /* Note token counters can go slightly negative */
@@ -246,63 +245,64 @@ struct tm_queue_obj_s {
 };
 
 struct tm_node_obj_s {
-   uint32_t magic_num;
-   tm_wred_node_t *tm_wred_node;
-   tm_shaper_obj_t shaper_obj;
+   uint32_t magic_num;
+   tm_wred_node_t  *tm_wred_node;
+   tm_shaper_obj_t  shaper_obj;
tm_schedulers_obj_t *schedulers_obj;
-   _odp_int_name_t name_tbl_id;
-   uint32_t max_fanin;
-   uint8_t level; /* Primarily for debugging */
-   uint8_t tm_idx;
-   uint8_t marked;
+   _odp_int_name_t  name_tbl_id;
+   uint32_t max_fanin;
+   uint8_t  level; /* Primarily for debugging */
+   uint8_t  tm_idx;
+   uint8_t  marked;
 };
 
 typedef struct {
tm_queue_obj_t *tm_queue_obj;
-   odp_packet_t pkt;
+   odp_packet_tpkt;
 } input_work_item_t;
 
 typedef struct {
-   uint64_t total_enqueues;
-   uint64_t enqueue_fail_cnt;
-   uint64_t total_dequeues;
-   odp_atomic_u32_t queue_cnt;
-   uint32_t peak_cnt;
-   uint32_t head_idx;
-   uint32_t tail_idx;
-   odp_ticketlock_t lock;
+   uint64_t  total_enqueues;
+   uint64_t  enqueue_fail_cnt;
+   uint64_t  total_dequeues;
+   odp_atomic_u32_t  queue_cnt;
+   uint32_t  peak_cnt;
+   uint32_t  head_idx;
+   uint32_t  tail_idx;
+   odp_ticketlock_t  lock;
input_work_item_t work_ring[INPUT_WORK_RING_SIZE];
 } input_work_queue_t;
 
 typedef struct {
uint32_t next_random_byte;
-   uint8_t buf[256];
+   uint8_t  buf[256];
 } tm_random_data_t;
 
 typedef struct {
tm_queue_thresholds_t *threshold_params;
-   tm_queue_cnts_t queue_cnts;
+   tm_queue_cnts_tqueue_cnts;
 } tm_queue_info_t;
 
 typedef struct {
odp_ticke

[lng-odp] [API-NEXT PATCHv4 4/5] linux-generic: tm: fix numerous bugs in timer wheel and main tm implementation

[Bill Fischofer]

From: Barry Spinney 

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/odp_timer_wheel.c  |  230 ---
 platform/linux-generic/odp_traffic_mngr.c | 1024 +++--
 2 files changed, 833 insertions(+), 421 deletions(-)

diff --git a/platform/linux-generic/odp_timer_wheel.c 
b/platform/linux-generic/odp_timer_wheel.c
index 288ea49..70d403e 100644
--- a/platform/linux-generic/odp_timer_wheel.c
+++ b/platform/linux-generic/odp_timer_wheel.c
@@ -12,18 +12,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
-#define MAX(a, b) (((a) > (b)) ? (a) : (b))
-#define MIN(a, b) (((a) < (b)) ? (a) : (b))
-
 /* The following constants can be changed either at compile time or run time
  * as long as the following constraints are met (by the way REV stands for
  * REVOLUTION, i.e. one complete sweep through a specific timer wheel):
  */
-#define CYCLES_TO_TICKS_SHIFT  8
-#define CYCLES_PER_TICKBIT(CYCLES_TO_TICKS_SHIFT)
-#define CURRENT_TIMER_SLOTS8192
+#define TIME_TO_TICKS_SHIFT10
+#define TIME_PER_TICK  BIT(TIME_TO_TICKS_SHIFT)
+#define CURRENT_TIMER_SLOTS1024
 #define LEVEL1_TIMER_SLOTS 2048
 #define LEVEL2_TIMER_SLOTS 1024
 #define LEVEL3_TIMER_SLOTS 1024
@@ -33,7 +31,7 @@
  * 1, since that defines what a tick is - namely the time period of a single
  * current timer wheel slot.  Then for all levels (including current), the
  * ticks per revolution is clearly equal to the ticks per slot times the
- * number of slots.  Finally the ticks per slot for levels 1 thru 3, must be
+ * number of slots.  Finally the ticks per slot for levels 1 through 3, must be
  * the ticks per revolution of the previous level divided by a small power of
  * 2 - e.g. 2, 4, 8, 16 - (but not 1).  The idea being that when an upper
  * level slot is processed, its entries will be spread across this fraction of
@@ -53,7 +51,7 @@
 #define TICKS_PER_LEVEL3_SLOT  (TICKS_PER_LEVEL2_REV / LEVEL2_GEAR_RATIO)
 #define TICKS_PER_LEVEL3_REV   (LEVEL3_TIMER_SLOTS * TICKS_PER_LEVEL3_SLOT)
 
-#define EXPIRED_RING_ENTRIES  64
+#define EXPIRED_RING_ENTRIES  256
 
 typedef struct timer_blk_s timer_blk_t;
 
@@ -149,6 +147,7 @@ typedef struct {
uint32_t  free_list_size;
uint32_t  min_free_list_size;
uint32_t  peak_free_list_size;
+   uint32_t  current_cnt;
timer_blk_t  *free_list_head;
uint64_t  total_timer_inserts;
uint64_t  insert_fail_cnt;
@@ -160,6 +159,7 @@ typedef struct {
current_wheel_t  *current_wheel;
general_wheel_t  *general_wheels[3];
expired_ring_t   *expired_timers_ring;
+   tm_system_t  *tm_system;
 } timer_wheels_t;
 
 static uint32_t _odp_internal_ilog2(uint64_t value)
@@ -193,55 +193,76 @@ static current_wheel_t 
*current_wheel_alloc(timer_wheels_t *timer_wheels,
 {
current_wheel_t *current_wheel;
wheel_desc_t*wheel_desc;
-   uint64_t ticks_per_slot, current_ticks, adjusted_ticks;
-   uint64_t ticks_per_rev;
uint32_t num_slots, malloc_len;
 
-   wheel_desc = &timer_wheels->wheel_descs[desc_idx];
-   num_slots  = wheel_desc->num_slots;
-   ticks_per_slot = 1;
-   malloc_len = num_slots * sizeof(current_timer_slot_t);
-   current_wheel  = malloc(malloc_len);
+   wheel_desc= &timer_wheels->wheel_descs[desc_idx];
+   num_slots = wheel_desc->num_slots;
+   malloc_len= num_slots * sizeof(current_timer_slot_t);
+   current_wheel = malloc(malloc_len);
memset(current_wheel, 0, malloc_len);
 
-   current_ticks  = timer_wheels->current_ticks;
-   adjusted_ticks = current_ticks & (ticks_per_slot - 1);
-   ticks_per_rev  = num_slots;
-
-   wheel_desc->ticks_per_rev = ticks_per_rev;
+   wheel_desc->slot_idx  = 0;
+   wheel_desc->ticks_per_rev = num_slots;
wheel_desc->ticks_shift   = 0;
-   wheel_desc->max_ticks = adjusted_ticks + ticks_per_rev;
+   wheel_desc->max_ticks = 0;
wheel_desc->gear_mask = (num_slots / wheel_desc->gear_ratio) - 1;
return current_wheel;
 }
 
+static void current_wheel_start(timer_wheels_t *timer_wheels,
+   uint32_tdesc_idx,
+   uint64_tcurrent_ticks)
+{
+   wheel_desc_t *wheel_desc;
+   uint32_t  wheel_idx;
+
+   wheel_desc = &timer_wheels->wheel_descs[desc_idx];
+   wheel_idx  = current_ticks & (wheel_desc->num_slots - 1);
+
+   wheel_desc->slot_idx  = wheel_idx;
+   wheel_desc->max_ticks = wheel_idx + wheel_desc->ticks_per_rev;
+}
+
 static general_wheel_t *general_wheel_alloc(timer_wheels_t *timer_wheels,
uint32_tdesc_idx)
 {
general_wheel_t *general_wheel;
wheel_desc_t*wheel_desc;
-   uint64_t ticks_per_slot, c

[lng-odp] [API-NEXT PATCHv4 5/5] validation: tm: add cunit test for traffic mngr

[Bill Fischofer]

From: Barry Spinney 

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 configure.ac |1 +
 test/validation/Makefile.am  |1 +
 test/validation/traffic_mngr/.gitignore  |1 +
 test/validation/traffic_mngr/Makefile.am |   10 +
 test/validation/traffic_mngr/traffic_mngr.c  | 2405 ++
 test/validation/traffic_mngr/traffic_mngr.h  |   38 +
 test/validation/traffic_mngr/traffic_mngr_main.c |   12 +
 7 files changed, 2468 insertions(+)
 create mode 100644 test/validation/traffic_mngr/.gitignore
 create mode 100644 test/validation/traffic_mngr/Makefile.am
 create mode 100644 test/validation/traffic_mngr/traffic_mngr.c
 create mode 100644 test/validation/traffic_mngr/traffic_mngr.h
 create mode 100644 test/validation/traffic_mngr/traffic_mngr_main.c

diff --git a/configure.ac b/configure.ac
index 1aa44d2..099a2d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -362,6 +362,7 @@ AC_CONFIG_FILES([Makefile
 test/validation/thread/Makefile
 test/validation/time/Makefile
 test/validation/timer/Makefile
+test/validation/traffic_mngr/Makefile
 test/validation/shmem/Makefile
 test/validation/system/Makefile
 test/miscellaneous/Makefile
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index cdd5a84..074da26 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -19,6 +19,7 @@ ODP_MODULES = atomic \
  thread \
  time \
  timer \
+ traffic_mngr \
  shmem \
  system
 
diff --git a/test/validation/traffic_mngr/.gitignore 
b/test/validation/traffic_mngr/.gitignore
new file mode 100644
index 000..efd07a2
--- /dev/null
+++ b/test/validation/traffic_mngr/.gitignore
@@ -0,0 +1 @@
+traffic_mngr_main
diff --git a/test/validation/traffic_mngr/Makefile.am 
b/test/validation/traffic_mngr/Makefile.am
new file mode 100644
index 000..35e689a
--- /dev/null
+++ b/test/validation/traffic_mngr/Makefile.am
@@ -0,0 +1,10 @@
+include ../Makefile.inc
+
+noinst_LTLIBRARIES = libtesttraffic_mngr.la
+libtesttraffic_mngr_la_SOURCES = traffic_mngr.c
+
+test_PROGRAMS = traffic_mngr_main$(EXEEXT)
+dist_traffic_mngr_main_SOURCES = traffic_mngr_main.c
+traffic_mngr_main_LDADD = libtesttraffic_mngr.la -lm $(LIBCUNIT_COMMON) 
$(LIBODP)
+
+EXTRA_DIST = traffic_mngr.h
diff --git a/test/validation/traffic_mngr/traffic_mngr.c 
b/test/validation/traffic_mngr/traffic_mngr.c
new file mode 100644
index 000..902a344
--- /dev/null
+++ b/test/validation/traffic_mngr/traffic_mngr.c
@@ -0,0 +1,2405 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "odp_cunit_common.h"
+#include "traffic_mngr.h"
+
+#define MAX_NUM_IFACES   2
+#define MAX_TM_SYSTEMS   3
+#define NUM_LEVELS   3
+#define NUM_PRIORITIES   4
+#define NUM_QUEUES_PER_NODE  NUM_PRIORITIES
+#define FANIN_RATIO  8
+#define NUM_LEVEL0_TM_NODES  1
+#define NUM_LEVEL1_TM_NODES  FANIN_RATIO
+#define NUM_LEVEL2_TM_NODES  (FANIN_RATIO * FANIN_RATIO)
+#define NUM_TM_QUEUES(NUM_LEVEL2_TM_NODES * NUM_QUEUES_PER_NODE)
+#define NUM_SHAPER_PROFILES  FANIN_RATIO
+#define NUM_SCHED_PROFILES   FANIN_RATIO
+#define NUM_THRESHOLD_PROFILES   NUM_QUEUES_PER_NODE
+#define NUM_WRED_PROFILESNUM_QUEUES_PER_NODE
+
+#define ODP_NUM_PKT_COLORS   ODP_NUM_PACKET_COLORS
+#define PKT_GREENODP_PACKET_GREEN
+#define PKT_YELLOW   ODP_PACKET_YELLOW
+#define PKT_RED  ODP_PACKET_RED
+
+#define MIN_COMMIT_BW(64 * 1024)
+#define MIN_COMMIT_BURST 8000
+#define MIN_PEAK_BW  200
+#define MIN_PEAK_BURST   16000
+
+#define MIN_PKT_THRESHOLD10
+#define MIN_BYTE_THRESHOLD   2048
+
+#define MIN_WRED_THRESH  5
+#define MED_WRED_THRESH  10
+#define MED_DROP_PROB4
+#define MAX_DROP_PROB8
+
+#define MAX_PKTS 1000
+#define PKT_BUF_SIZE 1460
+#define MAX_PAYLOAD  1400
+#define SHAPER_LEN_ADJ   20
+#define CRC_LEN  4
+#define TM_NAME_LEN  32
+#define BILLION  10ULL
+#define MS   100  /* Millisecond in units of NS */
+#define MBPS 100
+#define GBPS 10
+
+#define MIN(a, b)  (((a) <= (b)) ? (a) : (b))
+#define MAX(a, b)  (((a) <= (b)) ? (b) : (a))
+
+#define TM_PERCENT(percent) ((uint32_t)(100 * percent))
+
+typedef enum {
+   SHAPER_PROFILE, SCHED_PROFILE, THRESHOLD_PROFILE, WRED_PROFILE
+} profile_kind