Re: [lng-odp] [MONARCH PATCH 1/2] validation: pktio: use PRIu32 to print uint32_t values

[Nicolas Morey-Chaisemartin]

I didn't submit there for master because I cannot build odp-mppa with master 
yet (trying to merge monarch first).
And I'm pretty sure there'll be new patches like this to apply on master anyway.

Nicolas

Le 12/05/2016 à 08:21 PM, Mike Holmes a écrit :
> This series also applies to master with 3 way, it should go there first I
> think
>
> On 5 December 2016 at 11:33, Nicolas Morey-Chaisemartin 
> wrote:
>
>> Signed-off-by: Nicolas Morey-Chaisemartin 
>>
> Reviewed-by: Mike Holmes 
>
>
>> ---
>>  test/validation/pktio/pktio.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
>> index d53a419..4e93e9b 100644
>> --- a/test/validation/pktio/pktio.c
>> +++ b/test/validation/pktio/pktio.c
>> @@ -207,7 +207,8 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
>> }
>>
>> if (head.magic != TEST_SEQ_MAGIC) {
>> -   fprintf(stderr, "error: header magic invalid %u\n",
>> head.magic);
>> +   fprintf(stderr, "error: header magic invalid %" PRIu32
>> "\n",
>> +   head.magic);
>> return TEST_SEQ_INVALID;
>> }
>>
>> @@ -223,11 +224,14 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
>> seq = head.seq;
>> CU_ASSERT(seq != TEST_SEQ_INVALID);
>> } else {
>> -   fprintf(stderr, "error: tail magic invalid %u\n",
>> +   fprintf(stderr,
>> +   "error: tail magic invalid %" PRIu32 "\n",
>> tail.magic);
>> }
>> } else {
>> -   fprintf(stderr, "error: packet length invalid: %u (%u)\n",
>> +   fprintf(stderr,
>> +   "error: packet length invalid: "
>> +   "%" PRIu32 "(%" PRIu32 ")\n",
>> odp_packet_len(pkt), packet_len);
>> }
>>
>> --
>> 2.10.1.4.g0ffc436
>>
>>
>>
>

Re: [lng-odp] [MONARCH PATCH 0/5] Make lidodp/libodp helper name platform specific

[Nicolas Morey-Chaisemartin]

Le 12/05/2016 à 09:02 PM, Mike Holmes a écrit :
> I like this patch in principle, but it has to go into master first.
>
> I think that if you dont set ODP_LIB_NAME and you get something that is 
> expected to ab ABI compatible is good, if I add a platform name I would 
> expect it to be less portable.
> I like that odp-dpdk can reuse more of Linux generic infrastructure making it 
> even cheaper to support odp-dpdk and also possibly newer flavors such as 
> odp-cloud or other derivatives that make a spin on odp-linux for a particular 
> use case.
>
> Mike
>

Good. that's the goal of a lot of my patches ;)
The only things I'm not relly happy with in this patch is the name 
"ODP_LIB_NAME".
Wouldn't ODP_LIB_FLAVOR makes a little more sense ?

Do you think I should remost this series on master and merge it with the  
"[lng-odp] [PATCH 0/4] Make configure.ac generic" series?
Although it changes different things, the goal is one and the same: make it 
easier to add/build platform reusing all the build/test infrastructure of 
linux-generic.

Nicolas

> On 2 December 2016 at 09:09, Nicolas Morey-Chaisemartin  > wrote:
>
>
>
> Le 12/02/2016 à 02:52 PM, Mike Holmes a écrit :
>>
>>
>> On 2 December 2016 at 08:50, Nicolas Morey-Chaisemartin 
>> > wrote:
>>
>>
>>
>> Le 12/02/2016 à 02:45 PM, Maxim Uvarov a écrit :
>> > On 12/02/16 16:34, Nicolas Morey-Chaisemartin wrote:
>> >>
>> >> Le 12/02/2016 à 02:30 PM, Maxim Uvarov a écrit :
>> >>> That needs to go to master first, than if needed back-ported to 
>> Monarch.
>> >> Ok.
>> >>
>> >>> Nicolas, if you name library differently how will application 
>> know how
>> >>> to link with it?
>> >> 1) We provide a template makefile for all ODP apps.
>> >> 2) We don't have ABI compat with multiple libs as we build for 
>> our architecture, running our own OS with no dynamic library support
>> >>
>> >> We could use the same name as you do, but as we don't have any 
>> Linux running underneath, it doesn't make much sense to me.
>> >>
>> >> BTW, why did you rename those libraries?
>> >
>> > word 'generic' was confusing for some people.
>> >
>> > Maxim.
>>
>> Renaming the platform name is one thing. But why did libodp had to 
>> change to libodp-linux ?
>>
>>
>> It is not ABI compatible was the rational, we are workign on that.
>>
>> We need libodp to be ABI compatible and then libodpKalray etc to be non 
>> abi 
>>
>> Mike
>>  
>>
>
> So if I understood well:
> libodp => libodp-linux because of the static inlines/struct in the 
> linux-generic potentially break ABI compatibility with another implementation.
> libodp is reserved for someone without any platform specific 
> inlines/structs exported.
>
> I still think my series makes sense here. The only change i'd make is to 
> move the "-" before the suffix to ODP_LIB_NAME too.
> This ways a full ABI compatible platform sets ODP_LIB_NAME="" => it has 
> libodp.(so|a)
> Other platform add their suffix depending on who they are compatible with 
> (-linux, -mppa, etc.)
>
>
>
>
> -- 
> Mike Holmes
> Program Manager - Linaro Networking Group
> Linaro.org * **│ *Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"
>

Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

[Bill Fischofer]

Ping. v3 of this patch is still awaiting review.

On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer
 wrote:
> Add the odp_dev_id() API used for NUMA support
>
> Signed-off-by: Bill Fischofer 
> ---
> Changes for v3:
> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT
>
> Changes for v2:
> - Incorporate changes suggested by Petri
>
>  include/odp/api/spec/dev.h | 89 
> ++
>  1 file changed, 89 insertions(+)
>  create mode 100644 include/odp/api/spec/dev.h
>
> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h
> new file mode 100644
> index 000..76d861a
> --- /dev/null
> +++ b/include/odp/api/spec/dev.h
> @@ -0,0 +1,89 @@
> +/* Copyright (c) 2016, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * ODP device
> + */
> +
> +#ifndef ODP_API_DEV_H_
> +#define ODP_API_DEV_H_
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +
> +/** @defgroup odp_dev ODP DEVICE
> + *  Operations on devices
> + *  @{
> + */
> +
> +/**
> + * @typedef odp_dev_t
> + * ODP Device
> + */
> +
> +/**
> + * @def ODP_DEV_NAME_LEN
> + * Maximum device name length in chars
> + */
> +
> +/**
> + * @def ODP_DEV_DEFAULT
> + * Default device
> + */
> +
> +/**
> + * @def ODP_DEV_INVALID
> + * Invalid device
> + */
> +
> +/**
> + * Get Device ID by Name
> + *
> + * Get an implementation-defined device identifier from a device name. Device
> + * names are supplied as parameter info (command line, file, etc.) to the
> + * application. This routine translates this symbolic name into an internal
> + * identifier that can be used to define a device connection hierarchy for
> + * NUMA or other purposes.
> + *
> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder
> + * wherever a device id is required.
> + *
> + * @param name Name of the device
> + *
> + * @return Device ID
> + * @retval ODP_DEV_INVALID Device is unknown
> + */
> +odp_dev_t odp_dev_id(const char *name);
> +
> +/**
> + * Get printable value for an odp_dev_t
> + *
> + * @param hdl  odp_dev_t handle to be printed
> + * @return uint64_t value that can be used to print/display this
> + * handle
> + *
> + * @note This routine is intended to be used for diagnostic purposes
> + * to enable applications to generate a printable value that represents
> + * an odp_dev_t handle.
> + */
> +uint64_t odp_dev_to_u64(odp_dev_t hdl);
> +
> +/**
> + * @}
> + */
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#include 
> +#endif
> --
> 2.7.4
>

Re: [lng-odp] [API-NEXT PATCH v2 4/7] api: crypto: added session params init

[Bill Fischofer]

On Mon, Dec 5, 2016 at 2:39 AM, Petri Savolainen
 wrote:
> Added session parameters init function which should be
> used to initialize the structure before calling
> odp_crypto_session_create().
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/crypto.h   | 16 +++-
>  platform/linux-generic/odp_crypto.c |  5 +
>  2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index b136a80..22fd735 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -472,7 +472,11 @@ int odp_crypto_auth_capa(odp_auth_alg_t auth,
>  odp_crypto_auth_capa_t capa[], int num);
>
>  /**
> - * Crypto session creation (synchronous)
> + * Crypto session creation
> + *
> + * Create a crypto session according to the session parameters. Use
> + * odp_crypto_session_params_init() to initialize parameters into their
> + * default values.
>   *
>   * @param paramsSession parameters
>   * @param session   Created session else ODP_CRYPTO_SESSION_INVALID
> @@ -582,6 +586,16 @@ uint64_t odp_crypto_session_to_u64(odp_crypto_session_t 
> hdl);
>  uint64_t odp_crypto_compl_to_u64(odp_crypto_compl_t hdl);
>
>  /**
> + * Initialize crypto session parameters
> + *
> + * Initialize an odp_crypto_session_params_t to its default values for
> + * all fields.
> + *
> + * @param params   Pointer to odp_crypto_session_params_t to be initialized
> + */
> +void odp_crypto_session_params_init(odp_crypto_session_params_t *params);

Since we're cleaning up and adding this for completeness, the
underlying struct should be changed to odp_crypto_session_param_t and
this API should be odp_crypto_session_param_init() for consistency
with all other odp_xxx_param_t and odp_xxx_param_init() functions. The
inconsistent use of params instead of param in the crypto API was an
oversight in Monarch.

> +
> +/**
>   * @}
>   */
>
> diff --git a/platform/linux-generic/odp_crypto.c 
> b/platform/linux-generic/odp_crypto.c
> index a64b5a2..bdb06a9 100644
> --- a/platform/linux-generic/odp_crypto.c
> +++ b/platform/linux-generic/odp_crypto.c
> @@ -1041,3 +1041,8 @@ odp_crypto_compl_free(odp_crypto_compl_t 
> completion_event)
> odp_buffer_from_event((odp_event_t)completion_event),
> ODP_EVENT_PACKET);
>  }
> +
> +void odp_crypto_session_params_init(odp_crypto_session_params_t *params)
> +{
> +   memset(params, 0, sizeof(odp_crypto_session_params_t));
> +}
> --
> 2.8.1
>

Re: [lng-odp] [API-NEXT PATCH v2 1/7] api: crypto: decouple key length from algorithm enumeration

[Bill Fischofer]

On Mon, Dec 5, 2016 at 2:39 AM, Petri Savolainen
 wrote:
> Enumerations for cipher and authentication algorithms grow
> fast if key and digest lengths are included into the enum.
> Decoupled lengths from algorithm names, only exception is
> SHA-2 family of authentication algorithms which has established
> naming convention with digest lengths (SHA-224, SHA-256, ...).
> Old enumerations are still functional but deprecated.
>
> Algotrithm level capability functions provide a flexible way to
> handle all possible key/digest/iv length combinations.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/crypto.h | 167 
> --
>  1 file changed, 146 insertions(+), 21 deletions(-)
>
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index 0cb8814..b136a80 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -65,14 +65,28 @@ typedef enum {
>  typedef enum {
> /** No cipher algorithm specified */
> ODP_CIPHER_ALG_NULL,
> +
> /** DES */
> ODP_CIPHER_ALG_DES,
> +
> /** Triple DES with cipher block chaining */
> ODP_CIPHER_ALG_3DES_CBC,
> -   /** AES128 with cipher block chaining */
> +
> +   /** AES with cipher block chaining */
> +   ODP_CIPHER_ALG_AES_CBC,
> +
> +   /** AES in Galois/Counter Mode
> +*
> +*  @note Must be paired with cipher ODP_AUTH_ALG_AES_GCM
> +*/
> +   ODP_CIPHER_ALG_AES_GCM,
> +
> +   /** @deprecated  Use ODP_CIPHER_ALG_AES_CBC instead */
> ODP_CIPHER_ALG_AES128_CBC,
> -   /** AES128 in Galois/Counter Mode */
> -   ODP_CIPHER_ALG_AES128_GCM,
> +
> +   /** @deprecated  Use ODP_CIPHER_ALG_AES_GCM instead */
> +   ODP_CIPHER_ALG_AES128_GCM
> +
>  } odp_cipher_alg_t;
>
>  /**
> @@ -81,12 +95,33 @@ typedef enum {
>  typedef enum {
>  /** No authentication algorithm specified */
> ODP_AUTH_ALG_NULL,
> -   /** HMAC-MD5 with 96 bit key */
> +
> +   /** HMAC-MD5
> +*
> +* MD5 algorithm in HMAC mode
> +*/
> +   ODP_AUTH_ALG_MD5_HMAC,
> +
> +   /** HMAC-SHA-256
> +*
> +*  SHA-256 algorithm in HMAC mode
> +*/
> +   ODP_AUTH_ALG_SHA256_HMAC,
> +
> +   /** AES in Galois/Counter Mode
> +*
> +*  @note Must be paired with cipher ODP_CIPHER_ALG_AES_GCM
> +*/
> +   ODP_AUTH_ALG_AES_GCM,
> +
> +   /** @deprecated  Use ODP_AUTH_ALG_MD5_HMAC instead */
> ODP_AUTH_ALG_MD5_96,
> -   /** SHA256 with 128 bit key */
> +
> +   /** @deprecated  Use ODP_AUTH_ALG_SHA256_HMAC instead */
> ODP_AUTH_ALG_SHA256_128,
> -   /** AES128 in Galois/Counter Mode */
> -   ODP_AUTH_ALG_AES128_GCM,
> +
> +   /** @deprecated  Use ODP_AUTH_ALG_AES_GCM instead */
> +   ODP_AUTH_ALG_AES128_GCM
>  } odp_auth_alg_t;
>
>  /**
> @@ -96,19 +131,25 @@ typedef union odp_crypto_cipher_algos_t {
> /** Cipher algorithms */
> struct {
> /** ODP_CIPHER_ALG_NULL */
> -   uint32_t null   : 1;
> +   uint32_t null: 1;
>
> /** ODP_CIPHER_ALG_DES */
> -   uint32_t des: 1;
> +   uint32_t des : 1;
>
> /** ODP_CIPHER_ALG_3DES_CBC */
> -   uint32_t trides_cbc : 1;
> +   uint32_t trides_cbc  : 1;
> +
> +   /** ODP_CIPHER_ALG_AES_CBC */
> +   uint32_t aes_cbc : 1;
>
> -   /** ODP_CIPHER_ALG_AES128_CBC */
> -   uint32_t aes128_cbc : 1;
> +   /** ODP_CIPHER_ALG_AES_GCM */
> +   uint32_t aes_gcm : 1;
>
> -   /** ODP_CIPHER_ALG_AES128_GCM */
> -   uint32_t aes128_gcm : 1;
> +   /** @deprecated  Use aes_cbc instead */
> +   uint32_t aes128_cbc  : 1;
> +
> +   /** @deprecated  Use aes_gcm instead */
> +   uint32_t aes128_gcm  : 1;
> } bit;
>
> /** All bits of the bit field structure
> @@ -125,16 +166,25 @@ typedef union odp_crypto_auth_algos_t {
> /** Authentication algorithms */
> struct {
> /** ODP_AUTH_ALG_NULL */
> -   uint32_t null   : 1;
> +   uint32_t null: 1;
> +
> +   /** ODP_AUTH_ALG_MD5_HMAC */
> +   uint32_t md5_hmac: 1;
> +
> +   /** ODP_AUTH_ALG_SHA256_HMAC */
> +   uint32_t sha256_hmac : 1;
>
> -   /** ODP_AUTH_ALG_MD5_96 */
> -   uint32_t md5_96 : 1;
> +   /** ODP_AUTH_ALG_AES_GCM */
> +   uint32_t aes_gcm : 1;
>
> -   /** ODP_AUTH_ALG_SHA256_128 */
> -   uint32_t sha256_128 : 1;
> +   /** @deprecated  Use md5_hmac instead */
> +   uint32_t md5_96  : 1;
>
> -

Re: [lng-odp] [APO-NEXT PATCHv6 1/3] api: random: add explicit controls over random data

[Bill Fischofer]

Sorry about the typo in the patch subject. Obviously should be
API-NEXT. I'll correct in v7 if that's needed.

On Mon, Dec 5, 2016 at 3:28 PM, Bill Fischofer
 wrote:
> Rework the odp_random_data() API to replace the use_entropy with an
> explicit odp_random_kind parameter that controls the type of random
> desired. Two new APIs are also introduced:
>
> - odp_random_max_kind() returns the maximum kind of random data available
>
> - odp_random_repeatable_data() permits applications to generate repeatable
>   random sequences for testing purposes
>
> Because the type signature of odp_random_data() is changed, the
> implementation and validation tests are included here for bisectability.
>
> Signed-off-by: Bill Fischofer 
> ---
> Changes in v6:
> - Add odp_random_max_kind() API instead of adding this to the
>   odp_crypto_capability() API.
> - Rename odp_random_seeded_data() to odp_random_repeatable_data()
> - Merge API defs, implementation, and validation to preserve bisectability
>
> Changes in v5:
> - Change return type from int to int32_t for random APIs
>
> Changes in v4:
> - Normalize random API signatures with other ODP APIs
> - Add new odp_random_seeded_data() API for repeatable random data generation
> - Add additional tests for new odp_random_seeded_data() API
> - Break out crypto section of User Guide to its own sub-document
> - Add User Guide docuemntation for ODP random data API.
>
> Changes in v3:
> - Address commments by Petri
> - Rename ODP_RAND_NORMAL to ODP_RANDOM_BASIC to avoid confusion with the
> mathematical term "normal"
>
>  include/odp/api/spec/random.h   | 58 
> +++--
>  platform/linux-generic/odp_crypto.c | 50 ++---
>  test/common_plat/validation/api/random/random.c | 54 ++-
>  test/common_plat/validation/api/random/random.h |  2 +
>  4 files changed, 154 insertions(+), 10 deletions(-)
>
> diff --git a/include/odp/api/spec/random.h b/include/odp/api/spec/random.h
> index 00fa15b..bc130f5 100644
> --- a/include/odp/api/spec/random.h
> +++ b/include/odp/api/spec/random.h
> @@ -24,18 +24,68 @@ extern "C" {
>   */
>
>  /**
> + * Random kind selector
> + */
> +typedef enum {
> +   /** Basic random, presumably pseudo-random generated by SW */
> +   ODP_RANDOM_BASIC,
> +   /** Cryptographic quality random */
> +   ODP_RANDOM_CRYPTO,
> +   /** True random, generated from a HW entropy source */
> +   ODP_RANDOM_TRUE,
> +} odp_random_kind_t;
> +
> +/**
> + * Query random max kind
> + *
> + * @return kind The maximum odp_random_kind_t supported by this 
> implementation
> + */
> +odp_random_kind_t odp_random_max_kind(void);
> +
> +/**
>   * Generate random byte data
>   *
> + * The intent in supporting different kinds of random data is to allow
> + * tradeoffs between performance and the quality of random data needed. The
> + * assumption is that basic random is cheap while true random is relatively
> + * expensive in terms of time to generate, with cryptographic random being
> + * something in between. Implementations that support highly efficient true
> + * random are free to use this for all requested kinds. So it is always
> + * permissible to "upgrade" a random data request, but never to "downgrade"
> + * such requests.
> + *
>   * @param[out]buf   Output buffer
> - * @param size  Size of output buffer
> - * @param use_entropy   Use entropy
> + * @param len   Length of output buffer in bytes
> + * @param kind  Specifies the type of random data required. Request
> + *  is expected to fail if the implementation is unable 
> to
> + *  provide the requested type.
> + *
> + * @return Number of bytes written
> + * @retval <0 on failure
> + */
> +int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t kind);
> +
> +/**
> + * Generate repeatable random byte data
> + *
> + * For testing purposes it is often useful to generate "random" sequences
> + * that are repeatable. This is accomplished by supplying a seed value that
> + * is used for pseudo-random data generation. The caller provides
>   *
> - * @todo Define the implication of the use_entropy parameter
> + * @param[out]buf  Output buffer
> + * @param len  Length of output buffer in bytes
> + * @param kind Specifies the type of random data required. Request
> + * will fail if the implementation is unable to provide
> + * repeatable random of the requested type. This is
> + * always true for true random and may be true for
> + * cryptographic random.
> + * @param[in,out] seed Seed value to use
>   *
>   * @return Number of bytes written
>   * @retval <0 on failure
>   */
> -int32_t odp_random_data(uint8_t *buf, int32_t size, odp_bool_t use_entropy);
> +int32_t odp_random_repeatable_data(uint8_t *buf, 

[lng-odp] [PATCH] travis.yml: Only run coverity when pushing to its branch

[Mike Holmes]

Normally travis will drop back to the main script when the add on has
run. Disable that behaviour.

Signed-off-by: Mike Holmes 
---
 .travis.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index adf3307..81dc072 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -47,7 +47,7 @@ before_install:
 - popd
 
 script:
-
+- if [ "${COVERITY_SCAN_BRANCH}" != 1 ]; then
 - ./bootstrap
 - ./configure --enable-test-cpp --enable-test-vald 
--enable-test-helper --enable-test-perf --enable-user-guides 
--enable-test-perf-proc --enable-test-example 
--with-dpdk-path=`pwd`/dpdk/${TARGET}
 - make check
@@ -56,6 +56,7 @@ script:
 - ./configure
 - make doxygen-doc
 - make distcheck
+- fi
 
 addons:
 coverity_scan:
-- 
2.9.3

[lng-odp] [APO-NEXT PATCHv6 3/3] doc: userguide: expand crypto documentation to cover random apis

[Bill Fischofer]

Clean up the crypto section of the User Guide and expand on the
ODP random data APIs.

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/users-guide-crypto.adoc | 92 +
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/doc/users-guide/users-guide-crypto.adoc 
b/doc/users-guide/users-guide-crypto.adoc
index 04b3e87..fd117e9 100644
--- a/doc/users-guide/users-guide-crypto.adoc
+++ b/doc/users-guide/users-guide-crypto.adoc
@@ -1,7 +1,8 @@
 == Cryptographic services
 
 ODP provides APIs to perform cryptographic operations required by various
-communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+communication protocols (_e.g.,_ IPsec). ODP cryptographic APIs are session
+based.
 
 ODP provides APIs for following cryptographic services:
 
@@ -19,24 +20,26 @@ ODP supports synchronous and asynchronous crypto sessions. 
For asynchronous
 sessions, the output of crypto operation is posted in a queue defined as
 the completion queue in its session parameters.
 
-ODP crypto APIs support chained operation sessions in which hashing and 
ciphering
-both can be achieved using a single session and operation call. The order of
-cipher and hashing can be controlled by the `auth_cipher_text` session 
parameter.
+ODP crypto APIs support chained operation sessions in which hashing and
+ciphering both can be achieved using a single session and operation call. The
+order of cipher and hashing can be controlled by the `auth_cipher_text`
+session parameter.
 
 Other Session parameters include algorithms, keys, initialization vector
-(optional), encode or decode, output queue for async mode and output packet 
pool
-for allocation of an output packet if required.
+(optional), encode or decode, output queue for async mode and output packet
+pool for allocation of an output packet if required.
 
 === Crypto operations
 
 After session creation, a cryptographic operation can be applied to a packet
 using the `odp_crypto_operation()` API. Applications may indicate a preference
-for synchronous or asynchronous processing in the session's `pref_mode` 
parameter.
-However crypto operations may complete synchronously even if an asynchronous
-preference is indicated, and applications must examine the `posted` output
-parameter from `odp_crypto_operation()` to determine whether the operation has
-completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the 
case
-of an async operation, the `posted` output parameter will be set to true.
+for synchronous or asynchronous processing in the session's `pref_mode`
+parameter.  However crypto operations may complete synchronously even if an
+asynchronous preference is indicated, and applications must examine the
+`posted` output parameter from `odp_crypto_operation()` to determine whether
+the operation has completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is
+expected. In the case of an async operation, the `posted` output parameter
+will be set to true.
 
 
 The operation arguments specify for each packet the areas that are to be
@@ -49,9 +52,9 @@ In case of out-of-place mode output packet is different from 
input packet as
 specified by the application, while in new buffer mode implementation allocates
 a new output buffer from the session’s output pool.
 
-The application can also specify a context associated with a given operation 
that
-will be retained during async operation and can be retrieved via the completion
-event.
+The application can also specify a context associated with a given operation
+that will be retained during async operation and can be retrieved via the
+completion event.
 
 Results of an asynchronous session will be posted as completion events to the
 session’s completion queue, which can be accessed directly or via the ODP
@@ -60,12 +63,59 @@ result. The application has the responsibility to free the 
completion event.
 
 === Random number Generation
 
-ODP provides an API `odp_random_data()` to generate random data bytes. It has
-an argument to specify whether to use system entropy source for random number
-generation or not.
+ODP provides two APIs to generate various kinds of random data bytes. Random
+data is characterized by _kind_, which specifies the "quality" of the
+randomness required. ODP support three kinds of random data:
+
+ODP_RANDOM_BASIC:: No specific requirement other than the data appear to be
+uniformly distributed. Suitable for load-balancing or other non-cryptographic
+use.
+
+ODP_RANDOM_CRYPTO:: Data suitable for cryptographic use. This is a more
+stringent requirement that the data pass tests for statistical randomness.
+
+ODP_RANDOM_TRUE:: Data generated from a hardware entropy source rather than
+any software generated pseudo-random data. May not be available on all
+platforms.
+
+The main API for accessing random data is:
+
+[source,c]
+-
+int32_t odp_random_data(uint8_t buf, uint32_t len, odp_random_kind_t kind);

[lng-odp] [APO-NEXT PATCHv6 2/3] doc: userguide: move crypto documentation to its own sub-document

[Bill Fischofer]

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/Makefile.am |  1 +
 doc/users-guide/users-guide-crypto.adoc | 71 
 doc/users-guide/users-guide.adoc| 72 +
 3 files changed, 73 insertions(+), 71 deletions(-)
 create mode 100644 doc/users-guide/users-guide-crypto.adoc

diff --git a/doc/users-guide/Makefile.am b/doc/users-guide/Makefile.am
index a01c717..01b4df3 100644
--- a/doc/users-guide/Makefile.am
+++ b/doc/users-guide/Makefile.am
@@ -2,6 +2,7 @@ include ../Makefile.inc
 
 SRC= $(top_srcdir)/doc/users-guide/users-guide.adoc \
 $(top_srcdir)/doc/users-guide/users-guide-cls.adoc \
+$(top_srcdir)/doc/users-guide/users-guide-crypto.adoc \
 $(top_srcdir)/doc/users-guide/users-guide-packet.adoc \
 $(top_srcdir)/doc/users-guide/users-guide-pktio.adoc \
 $(top_srcdir)/doc/users-guide/users-guide-timer.adoc \
diff --git a/doc/users-guide/users-guide-crypto.adoc 
b/doc/users-guide/users-guide-crypto.adoc
new file mode 100644
index 000..04b3e87
--- /dev/null
+++ b/doc/users-guide/users-guide-crypto.adoc
@@ -0,0 +1,71 @@
+== Cryptographic services
+
+ODP provides APIs to perform cryptographic operations required by various
+communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing (HMAC)
+* Random number generation
+* Crypto capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and asynchronous crypto sessions. For asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+the completion queue in its session parameters.
+
+ODP crypto APIs support chained operation sessions in which hashing and 
ciphering
+both can be achieved using a single session and operation call. The order of
+cipher and hashing can be controlled by the `auth_cipher_text` session 
parameter.
+
+Other Session parameters include algorithms, keys, initialization vector
+(optional), encode or decode, output queue for async mode and output packet 
pool
+for allocation of an output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using the `odp_crypto_operation()` API. Applications may indicate a preference
+for synchronous or asynchronous processing in the session's `pref_mode` 
parameter.
+However crypto operations may complete synchronously even if an asynchronous
+preference is indicated, and applications must examine the `posted` output
+parameter from `odp_crypto_operation()` to determine whether the operation has
+completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the 
case
+of an async operation, the `posted` output parameter will be set to true.
+
+
+The operation arguments specify for each packet the areas that are to be
+encrypted or decrypted and authenticated. Also, there is an option of 
overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or new buffer mode.
+In in-place mode output packet is same as the input packet.
+In case of out-of-place mode output packet is different from input packet as
+specified by the application, while in new buffer mode implementation allocates
+a new output buffer from the session’s output pool.
+
+The application can also specify a context associated with a given operation 
that
+will be retained during async operation and can be retrieved via the completion
+event.
+
+Results of an asynchronous session will be posted as completion events to the
+session’s completion queue, which can be accessed directly or via the ODP
+scheduler. The completion event contains the status of the operation and the
+result. The application has the responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API `odp_random_data()` to generate random data bytes. It has
+an argument to specify whether to use system entropy source for random number
+generation or not.
+
+=== Capability inquiries
+
+ODP provides an API interface `odp_crypto_capability()` to inquire 
implementation’s
+crypto capabilities. This interface returns a bitmask for supported algorithms
+and hardware backed algorithms.
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 9a427fa..41c57d1 100755
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -1018,77 +1018,7 @@ include::users-guide-pktio.adoc[]
 
 include::users-guide-timer.adoc[]
 
-== Cryptographic services
-
-ODP provides APIs to perform cryptographic operations required by various
-communication protocols (e.g. IPSec). 

[lng-odp] [APO-NEXT PATCHv6 1/3] api: random: add explicit controls over random data

[Bill Fischofer]

Rework the odp_random_data() API to replace the use_entropy with an
explicit odp_random_kind parameter that controls the type of random
desired. Two new APIs are also introduced:

- odp_random_max_kind() returns the maximum kind of random data available

- odp_random_repeatable_data() permits applications to generate repeatable
  random sequences for testing purposes

Because the type signature of odp_random_data() is changed, the
implementation and validation tests are included here for bisectability.

Signed-off-by: Bill Fischofer 
---
Changes in v6:
- Add odp_random_max_kind() API instead of adding this to the
  odp_crypto_capability() API.
- Rename odp_random_seeded_data() to odp_random_repeatable_data()
- Merge API defs, implementation, and validation to preserve bisectability

Changes in v5:
- Change return type from int to int32_t for random APIs

Changes in v4:
- Normalize random API signatures with other ODP APIs
- Add new odp_random_seeded_data() API for repeatable random data generation
- Add additional tests for new odp_random_seeded_data() API
- Break out crypto section of User Guide to its own sub-document
- Add User Guide docuemntation for ODP random data API.

Changes in v3:
- Address commments by Petri
- Rename ODP_RAND_NORMAL to ODP_RANDOM_BASIC to avoid confusion with the
mathematical term "normal"

 include/odp/api/spec/random.h   | 58 +++--
 platform/linux-generic/odp_crypto.c | 50 ++---
 test/common_plat/validation/api/random/random.c | 54 ++-
 test/common_plat/validation/api/random/random.h |  2 +
 4 files changed, 154 insertions(+), 10 deletions(-)

diff --git a/include/odp/api/spec/random.h b/include/odp/api/spec/random.h
index 00fa15b..bc130f5 100644
--- a/include/odp/api/spec/random.h
+++ b/include/odp/api/spec/random.h
@@ -24,18 +24,68 @@ extern "C" {
  */
 
 /**
+ * Random kind selector
+ */
+typedef enum {
+   /** Basic random, presumably pseudo-random generated by SW */
+   ODP_RANDOM_BASIC,
+   /** Cryptographic quality random */
+   ODP_RANDOM_CRYPTO,
+   /** True random, generated from a HW entropy source */
+   ODP_RANDOM_TRUE,
+} odp_random_kind_t;
+
+/**
+ * Query random max kind
+ *
+ * @return kind The maximum odp_random_kind_t supported by this implementation
+ */
+odp_random_kind_t odp_random_max_kind(void);
+
+/**
  * Generate random byte data
  *
+ * The intent in supporting different kinds of random data is to allow
+ * tradeoffs between performance and the quality of random data needed. The
+ * assumption is that basic random is cheap while true random is relatively
+ * expensive in terms of time to generate, with cryptographic random being
+ * something in between. Implementations that support highly efficient true
+ * random are free to use this for all requested kinds. So it is always
+ * permissible to "upgrade" a random data request, but never to "downgrade"
+ * such requests.
+ *
  * @param[out]buf   Output buffer
- * @param size  Size of output buffer
- * @param use_entropy   Use entropy
+ * @param len   Length of output buffer in bytes
+ * @param kind  Specifies the type of random data required. Request
+ *  is expected to fail if the implementation is unable to
+ *  provide the requested type.
+ *
+ * @return Number of bytes written
+ * @retval <0 on failure
+ */
+int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t kind);
+
+/**
+ * Generate repeatable random byte data
+ *
+ * For testing purposes it is often useful to generate "random" sequences
+ * that are repeatable. This is accomplished by supplying a seed value that
+ * is used for pseudo-random data generation. The caller provides
  *
- * @todo Define the implication of the use_entropy parameter
+ * @param[out]buf  Output buffer
+ * @param len  Length of output buffer in bytes
+ * @param kind Specifies the type of random data required. Request
+ * will fail if the implementation is unable to provide
+ * repeatable random of the requested type. This is
+ * always true for true random and may be true for
+ * cryptographic random.
+ * @param[in,out] seed Seed value to use
  *
  * @return Number of bytes written
  * @retval <0 on failure
  */
-int32_t odp_random_data(uint8_t *buf, int32_t size, odp_bool_t use_entropy);
+int32_t odp_random_repeatable_data(uint8_t *buf, uint32_t len,
+  odp_random_kind_t kind, uint32_t *seed);
 
 /**
  * @}
diff --git a/platform/linux-generic/odp_crypto.c 
b/platform/linux-generic/odp_crypto.c
index 7e686ff..a731528 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -4,6 +4,7 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
+#include 
 #include 
 #include 
 #include 
@@ 

Re: [lng-odp] [MONARCH PATCH 0/5] Make lidodp/libodp helper name platform specific

[Mike Holmes]

I like this patch in principle, but it has to go into master first.

I think that if you dont set ODP_LIB_NAME and you get something that is
expected to ab ABI compatible is good, if I add a platform name I would
expect it to be less portable.
I like that odp-dpdk can reuse more of Linux generic infrastructure making
it even cheaper to support odp-dpdk and also possibly newer flavors such as
odp-cloud or other derivatives that make a spin on odp-linux for a
particular use case.

Mike

On 2 December 2016 at 09:09, Nicolas Morey-Chaisemartin 
wrote:

>
>
> Le 12/02/2016 à 02:52 PM, Mike Holmes a écrit :
>
>
>
> On 2 December 2016 at 08:50, Nicolas Morey-Chaisemartin 
> wrote:
>
>>
>>
>> Le 12/02/2016 à 02:45 PM, Maxim Uvarov a écrit :
>> > On 12/02/16 16:34, Nicolas Morey-Chaisemartin wrote:
>> >>
>> >> Le 12/02/2016 à 02:30 PM, Maxim Uvarov a écrit :
>> >>> That needs to go to master first, than if needed back-ported to
>> Monarch.
>> >> Ok.
>> >>
>> >>> Nicolas, if you name library differently how will application know how
>> >>> to link with it?
>> >> 1) We provide a template makefile for all ODP apps.
>> >> 2) We don't have ABI compat with multiple libs as we build for our
>> architecture, running our own OS with no dynamic library support
>> >>
>> >> We could use the same name as you do, but as we don't have any Linux
>> running underneath, it doesn't make much sense to me.
>> >>
>> >> BTW, why did you rename those libraries?
>> >
>> > word 'generic' was confusing for some people.
>> >
>> > Maxim.
>>
>> Renaming the platform name is one thing. But why did libodp had to change
>> to libodp-linux ?
>>
>
> It is not ABI compatible was the rational, we are workign on that.
>
> We need libodp to be ABI compatible and then libodpKalray etc to be non
> abi
>
> Mike
>
>
>
> So if I understood well:
> libodp => libodp-linux because of the static inlines/struct in the
> linux-generic potentially break ABI compatibility with another
> implementation.
> libodp is reserved for someone without any platform specific
> inlines/structs exported.
>
> I still think my series makes sense here. The only change i'd make is to
> move the "-" before the suffix to ODP_LIB_NAME too.
> This ways a full ABI compatible platform sets ODP_LIB_NAME="" => it has
> libodp.(so|a)
> Other platform add their suffix depending on who they are compatible with
> (-linux, -mppa, etc.)
>
>


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

Re: [lng-odp] [MONARCH PATCH 1/2] validation: pktio: use PRIu32 to print uint32_t values

[Mike Holmes]

This series also applies to master with 3 way, it should go there first I
think

On 5 December 2016 at 11:33, Nicolas Morey-Chaisemartin 
wrote:

> Signed-off-by: Nicolas Morey-Chaisemartin 
>

Reviewed-by: Mike Holmes 


> ---
>  test/validation/pktio/pktio.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
> index d53a419..4e93e9b 100644
> --- a/test/validation/pktio/pktio.c
> +++ b/test/validation/pktio/pktio.c
> @@ -207,7 +207,8 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
> }
>
> if (head.magic != TEST_SEQ_MAGIC) {
> -   fprintf(stderr, "error: header magic invalid %u\n",
> head.magic);
> +   fprintf(stderr, "error: header magic invalid %" PRIu32
> "\n",
> +   head.magic);
> return TEST_SEQ_INVALID;
> }
>
> @@ -223,11 +224,14 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
> seq = head.seq;
> CU_ASSERT(seq != TEST_SEQ_INVALID);
> } else {
> -   fprintf(stderr, "error: tail magic invalid %u\n",
> +   fprintf(stderr,
> +   "error: tail magic invalid %" PRIu32 "\n",
> tail.magic);
> }
> } else {
> -   fprintf(stderr, "error: packet length invalid: %u (%u)\n",
> +   fprintf(stderr,
> +   "error: packet length invalid: "
> +   "%" PRIu32 "(%" PRIu32 ")\n",
> odp_packet_len(pkt), packet_len);
> }
>
> --
> 2.10.1.4.g0ffc436
>
>
>


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

Re: [lng-odp] [PATCH] configure.ac: fix builds from raw git tar

[Mike Holmes]

Ping, trivial fix for Monarch to actually work from the download page

On 1 December 2016 at 14:28, Mike Holmes  wrote:

> I missed the prefix for MONARCH - re sending
>
> On 1 December 2016 at 14:21, Mike Holmes  wrote:
>
>> Signed-off-by: Mike Holmes 
>> ---
>>  configure.ac | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 48fe0be..5c7ddd0 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1,5 +1,5 @@
>>  AC_PREREQ([2.5])
>> -AC_INIT([OpenDataPlane], m4_esyscmd(./scripts/git_hash.sh .), [
>> lng-odp@lists.linaro.org])
>> +AC_INIT([OpenDataPlane], m4_esyscmd_s(./scripts/git_hash.sh .), [
>> lng-odp@lists.linaro.org])
>>  AM_INIT_AUTOMAKE([1.9 tar-pax subdir-objects])
>>  AC_CONFIG_SRCDIR([helper/config.h.in])
>>  AM_CONFIG_HEADER([helper/config.h])
>> --
>> 2.9.3
>>
>>
>
>
> --
> Mike Holmes
> Program Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"
>
>
>


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

[lng-odp] [API-NEXT PATCH] linux-gen: shared_memory: remove flag forcing mlock()

[Christophe Milard]

The _ishm flag _ODP_ISHM_LOCK is no longer set when doing shm_reserve(),
hence enabling non-root user to exceed the 64MB mlock memory limit
(ulimit).

Signed-off-by: Christophe Milard 
---
 platform/linux-generic/odp_shared_memory.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/platform/linux-generic/odp_shared_memory.c 
b/platform/linux-generic/odp_shared_memory.c
index d2bb74c..ba32dee 100644
--- a/platform/linux-generic/odp_shared_memory.c
+++ b/platform/linux-generic/odp_shared_memory.c
@@ -58,9 +58,6 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t size, 
uint64_t align,
 
flgs = get_ishm_flags(flags);
 
-   /* all mem reserved through this interface is requested to be locked: */
-   flgs |= (flags & _ODP_ISHM_LOCK);
-
block_index = _odp_ishm_reserve(name, size, -1, align, flgs, flags);
if (block_index >= 0)
return to_handle(block_index);
-- 
2.7.4

[lng-odp] [MONARCH PATCH 2/2] validation: traffic_mngr: use PRI macro to print uint*

[Nicolas Morey-Chaisemartin]

Signed-off-by: Nicolas Morey-Chaisemartin 
---
 test/validation/traffic_mngr/traffic_mngr.c | 116 +++-
 1 file changed, 64 insertions(+), 52 deletions(-)

diff --git a/test/validation/traffic_mngr/traffic_mngr.c 
b/test/validation/traffic_mngr/traffic_mngr.c
index b857800..b41404e 100644
--- a/test/validation/traffic_mngr/traffic_mngr.c
+++ b/test/validation/traffic_mngr/traffic_mngr.c
@@ -956,8 +956,9 @@ static void dump_rcvd_pkts(uint32_t first_rcv_idx, uint32_t 
last_rcv_idx)
if (rcv_pkt_desc->matched)
xmt_idx = rcv_pkt_desc->xmt_pkt_desc->xmt_idx;
 
-   printf("rcv_idx=%u odp_pkt=0x%" PRIX64 " xmt_idx=%d "
-  "pkt_class=%u is_ipv4=%u unique_id=0x%X (rc=%d)\n",
+   printf("rcv_idx=%" PRIu32 " odp_pkt=0x%" PRIX64 " "
+  "xmt_idx=%" PRId32 " pkt_class=%u is_ipv4=%u "
+  "unique_id=0x%X (rc=%d)\n",
   rcv_idx, odp_packet_to_u64(rcv_pkt), xmt_idx,
   rcv_pkt_desc->pkt_class, is_ipv4, unique_id, rc);
}
@@ -1376,15 +1377,15 @@ static tm_node_desc_t *create_tm_node(odp_tm_t
odp_tm,
node_params.max_fanin = FANIN_RATIO;
node_params.level = level;
if (parent_node_desc == NULL)
-   snprintf(node_name, sizeof(node_name), "node_%u",
+   snprintf(node_name, sizeof(node_name), "node_%" PRIu32,
 node_idx + 1);
else
-   snprintf(node_name, sizeof(node_name), "%s_%u",
+   snprintf(node_name, sizeof(node_name), "%s_%" PRIu32,
 parent_node_desc->node_name, node_idx + 1);
 
tm_node = odp_tm_node_create(odp_tm, node_name, _params);
if (tm_node == ODP_TM_INVALID) {
-   LOG_ERR("odp_tm_node_create() failed @ level=%u\n",
+   LOG_ERR("odp_tm_node_create() failed @ level=%" PRIu32 "\n",
level);
return NULL;
}
@@ -1397,7 +1398,7 @@ static tm_node_desc_t *create_tm_node(odp_tm_t
odp_tm,
 
rc = odp_tm_node_connect(tm_node, parent_node);
if (rc != 0) {
-   LOG_ERR("odp_tm_node_connect() failed @ level=%u\n",
+   LOG_ERR("odp_tm_node_connect() failed @ level=%" PRIu32 "\n",
level);
odp_tm_node_destroy(tm_node);
return NULL;
@@ -1431,8 +1432,8 @@ static tm_node_desc_t *create_tm_node(odp_tm_t
odp_tm,
rc = create_tm_queue(odp_tm, tm_node, node_idx, queue_desc,
 priority);
if (rc != 0) {
-   LOG_ERR("create_tm_queue() failed @ level=%u\n",
-   level);
+   LOG_ERR("create_tm_queue() failed @ "
+   "level=%" PRIu32 "\n", level);
while (priority > 0)
(void)destroy_tm_queue
(queue_desc->tm_queues[--priority]);
@@ -1457,7 +1458,7 @@ static tm_node_desc_t *create_tm_subtree(odp_tm_t
odp_tm,
node_desc = create_tm_node(odp_tm, level, num_levels,
   node_idx, parent_node);
if (node_desc == NULL) {
-   LOG_ERR("create_tm_node() failed @ level=%u\n", level);
+   LOG_ERR("create_tm_node() failed @ level=%" PRIu32 "\n", level);
return NULL;
}
 
@@ -1467,8 +1468,8 @@ static tm_node_desc_t *create_tm_subtree(odp_tm_t
odp_tm,
   num_levels, child_idx,
   node_desc);
if (child_desc == NULL) {
-   LOG_ERR("create_tm_subtree failed level=%u\n",
-   level);
+   LOG_ERR("create_tm_subtree failed "
+   "level=%" PRIu32 "\n", level);
 
return NULL;
}
@@ -1629,7 +1630,8 @@ static int create_tm_system(void)
egress.egress_kind = ODP_TM_EGRESS_PKT_IO;
egress.pktio  = xmt_pktio;
 
-   snprintf(tm_name, sizeof(tm_name), "TM_system_%u", num_odp_tm_systems);
+   snprintf(tm_name, sizeof(tm_name), "TM_system_%" PRIu32,
+num_odp_tm_systems);
odp_tm = odp_tm_create(tm_name, , );
if (odp_tm == ODP_TM_INVALID) {
LOG_ERR("odp_tm_create() failed\n");
@@ -1682,9 +1684,10 @@ static void dump_tm_subtree(tm_node_desc_t *node_desc)
if (node_desc->queue_desc != NULL)
num_queues = node_desc->queue_desc->num_queues;
 
-   printf("node_desc=%p name='%s' tm_node=0x%" PRIX64 " idx=%u level=%u "
-  "parent=0x%" PRIX64 " children=%u queues=%u queue_fanin=%u "
-  

[lng-odp] [MONARCH PATCH 1/2] validation: pktio: use PRIu32 to print uint32_t values

[Nicolas Morey-Chaisemartin]

Signed-off-by: Nicolas Morey-Chaisemartin 
---
 test/validation/pktio/pktio.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
index d53a419..4e93e9b 100644
--- a/test/validation/pktio/pktio.c
+++ b/test/validation/pktio/pktio.c
@@ -207,7 +207,8 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
}
 
if (head.magic != TEST_SEQ_MAGIC) {
-   fprintf(stderr, "error: header magic invalid %u\n", head.magic);
+   fprintf(stderr, "error: header magic invalid %" PRIu32 "\n",
+   head.magic);
return TEST_SEQ_INVALID;
}
 
@@ -223,11 +224,14 @@ static uint32_t pktio_pkt_seq(odp_packet_t pkt)
seq = head.seq;
CU_ASSERT(seq != TEST_SEQ_INVALID);
} else {
-   fprintf(stderr, "error: tail magic invalid %u\n",
+   fprintf(stderr,
+   "error: tail magic invalid %" PRIu32 "\n",
tail.magic);
}
} else {
-   fprintf(stderr, "error: packet length invalid: %u (%u)\n",
+   fprintf(stderr,
+   "error: packet length invalid: "
+   "%" PRIu32 "(%" PRIu32 ")\n",
odp_packet_len(pkt), packet_len);
}
 
-- 
2.10.1.4.g0ffc436

[lng-odp] [PATCH 2/2] doc: release-guide: detail abi & api tools

[Mike Holmes]

Signed-off-by: Mike Holmes 
---
 doc/process-guide/release-guide.adoc | 176 +++
 1 file changed, 176 insertions(+)

diff --git a/doc/process-guide/release-guide.adoc 
b/doc/process-guide/release-guide.adoc
index 8ea147a..1f77ab2 100644
--- a/doc/process-guide/release-guide.adoc
+++ b/doc/process-guide/release-guide.adoc
@@ -350,3 +350,179 @@ typedef struct foo_init_t {
int num_control;
int other_items;
 
+== API & ABI difference tools
+=== API difference tool
+The API doxygen documentation can be  compared with a previous
+release to get the basic summary of changes, as shown below between 1.10.1.0 
and
+1.11.0.0
+[source,bash]
+
+GIT_BRANCH=master COMPARE_BRANCH=v1.10.1.0 ./diff-api.sh
+...
+...
+diff --suppress-common-lines --recursive -t -s -d --unified 
odp_diff-git___git_linaro_org_lng_odp_git_master-v1.12.0.0module/a_summary.txt 
odp_diff_2-git___git_linaro_org_lng_odp_git_v1_10_1_0-v1.10.1.0module/a_summary.txt
+--- 
odp_diff-git___git_linaro_org_lng_odp_git_master-v1.12.0.0module/a_summary.txt  
   2016-12-05 10:10:51.126723616 -0500
 
odp_diff_2-git___git_linaro_org_lng_odp_git_v1_10_1_0-v1.10.1.0module/a_summary.txt
2016-12-05 10:10:51.318727901 -0500
+@@ -1,34 +1,36 @@
+
+-Generated from /home/mike/git/check-odp/build/odp_diff a details directory 
called odp_diff-git___git_linaro_org_lng_odp_git_master-v1.12.0.0module
++Generated from /home/mike/git/check-odp/build/odp_diff_2 a details directory 
called odp_diff_2-git___git_linaro_org_lng_odp_git_v1_10_1_0-v1.10.1.0module
+
+ MODULE  FUNCTION   TYPEDEFDEFINE
+-odp_atomic45 1 0
+-   odp_barrier 5 0 0
+-odp_buffer12 0 0
+-odp_classification17 1 0
+-odp_compiler_optim12 013
++odp_atomic44 1 0
++   odp_barrier 4 1 0
++odp_buffer13 1 1
++odp_classification17 1 3
++odp_compiler_optim11 118
+odp_cpu13 0 0
+-   odp_cpumask19 0 0
+-odp_crypto10 1 0
++   odp_cpumask19 1 2
++odp_crypto10 1 1
+  odp_errno 4 0 0
+- odp_event 3 0 0
++ odp_event 3 1 1
+   odp_hash 3 1 0
+ odp_initialization 6 1 0
+- odp_locks29 0 0
+-odp_packet   124 0 0
+- odp_packet_io40 1 0
+-  odp_pool 8 1 4
+- odp_queue18 1 0
++ odp_locks29 1 0
++odp_packet   124 1 4
++ odp_packet_io40 1 4
++  odp_pool 8 1 5
++ odp_queue18 1 3
+ odp_random 1 0 0
+- odp_scheduler18 1 0
+- odp_shared_memory 8 1 3
++ odp_scheduler18 114
++ odp_shared_memory 8 1 5
+   odp_std_clib 3 0 0
+-odp_system 3 0 0
+-odp_thread22 1 0
+-  odp_time13 0 3
+- odp_timer23 0 1
+-  odp_traffic_mngr69 1 3
++odp_system 3 1 0
++odp_thread22 1 2
++  odp_time13 1 4
++ odp_timer23 1 4
++  odp_traffic_mngr70 118
+odp_version 3 0 3
+- TOTAL   5311230
+
+diff --suppress-common-lines --recursive -t -s -d --unified 
odp_diff-git___git_linaro_org_lng_odp_git_master-v1.12.0.0module/odp_atomic.txt 
odp_diff_2-git___git_linaro_org_lng_odp_git_v1_10_1_0-v1.10.1.0module/odp_atomic.txt
+--- 

Re: [lng-odp] [API-NEXT PATCHv5 3/7] api: crypto: add random kind info to odp_crypto_capabilities() api

[Bill Fischofer]

On Mon, Dec 5, 2016 at 9:04 AM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
>> index 0cb8814..10373a3 100644
>> --- a/include/odp/api/spec/crypto.h
>> +++ b/include/odp/api/spec/crypto.h
>> @@ -19,6 +19,8 @@
>>  extern "C" {
>>  #endif
>>
>> +#include 
>> +
>>  /** @defgroup odp_crypto ODP CRYPTO
>>   *  Macros, enums, types and operations to utilise crypto.
>>   *  @{
>> @@ -332,6 +334,8 @@ typedef struct odp_crypto_capability_t {
>>   /** Authentication algorithms implemented with HW offload */
>>   odp_crypto_auth_algos_t   hw_auths;
>>
>> + /** Highest kind of random data available */
>> + odp_random_kind_t max_random_kind;
>>  } odp_crypto_capability_t;
>>
>
> This should be in random.h. Maybe simple ...
>
> odp_random_kind_t odp_random_max_kind(void);
>
> ... would do it.

We've consolidated this sort of information under the general
odp_xxx_capability() framework so it would be consistent to stick with
this. While today kind is the only capability we're exposing that
doesn't mean we wouldn't want to expose additional capabilities in the
future. But I agree this would be a reasonable exception if you'd
prefer that.

>
>
> -Petri

Re: [lng-odp] [API-NEXT PATCHv5 2/7] api: random: add ability to generate repeatable random data

[Bill Fischofer]

On Mon, Dec 5, 2016 at 9:02 AM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>> diff --git a/include/odp/api/spec/random.h b/include/odp/api/spec/random.h
>> index e732c3a..83ef84c 100644
>> --- a/include/odp/api/spec/random.h
>> +++ b/include/odp/api/spec/random.h
>> @@ -59,6 +59,28 @@ typedef enum {
>>  int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t
>> kind);
>>
>>  /**
>> + * Generate repeatable random byte data
>> + *
>> + * For testing purposes it is often useful to generate "random" sequences
>> + * that are repeatable. This is accomplished by supplying a seed value
>> that
>> + * is used for pseudo-random data generation. The caller provides
>> + *
>> + * @param[out]buf  Output buffer
>> + * @param len  Length of output buffer in bytes
>> + * @param kind Specifies the type of random data required.
>> Request
>> + * will fail if the implementation is unable to
>> provide
>> + * repeatable random of the requested type. This is
>> + * always true for true random and may be true for
>> + * cryptographic random.
>> + * @param[in,out] seed Seed value to use
>> + *
>> + * @return Number of bytes written
>> + * @retval <0 on failure
>> + */
>> +int32_t odp_random_seeded_data(uint8_t *buf, uint32_t len,
>> +odp_random_kind_t kind, uint32_t *seed);
>> +
>
> I think it's better to name this explicitly pseudo random (or deterministic 
> random), so that people do not by mistake use it instead of the "true" random 
> API call. Also "kind" is not needed here. Seed could be larger or even 
> implementation defined size. There are larger than 32 bit pseudo random 
> functions available  https://linux.die.net/man/3/drand48_r.

All non-true random is deterministic since it is the result of
computation, so that's not the best distinction. The issue here is
controlled repeatability, which is what having an explicit seed
parameter is trying to communicate. Perhaps
odp_random_repeatable_data() might be clearer?

Kind is still needed here because there is still a statistical
distinction between basic and cryptographic-quality random data. It's
also consistent. The only kind which cannot be supplied in a
repeatable manner is true random, which by definition is not
repeatable.

>
>
> /* Uses some bits of init value to initialize the seed */
> void odp_random_seed(odp_random_seed_t *seed, uint64_t init_value);
>
> /* Uses a seed to produce a deterministic, pseudo random sequence of data */
> int32_t odp_random_pseudo(uint8_t *buf, uint32_t len, odp_random_seed_t 
> *seed);
>
>
> -Petri
>
>

Re: [lng-odp] [API-NEXT PATCHv5 3/7] api: crypto: add random kind info to odp_crypto_capabilities() api

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

> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index 0cb8814..10373a3 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -19,6 +19,8 @@
>  extern "C" {
>  #endif
> 
> +#include 
> +
>  /** @defgroup odp_crypto ODP CRYPTO
>   *  Macros, enums, types and operations to utilise crypto.
>   *  @{
> @@ -332,6 +334,8 @@ typedef struct odp_crypto_capability_t {
>   /** Authentication algorithms implemented with HW offload */
>   odp_crypto_auth_algos_t   hw_auths;
> 
> + /** Highest kind of random data available */
> + odp_random_kind_t max_random_kind;
>  } odp_crypto_capability_t;
> 

This should be in random.h. Maybe simple ...

odp_random_kind_t odp_random_max_kind(void);

... would do it.


-Petri

Re: [lng-odp] [API-NEXT PATCHv5 2/7] api: random: add ability to generate repeatable random data

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

> diff --git a/include/odp/api/spec/random.h b/include/odp/api/spec/random.h
> index e732c3a..83ef84c 100644
> --- a/include/odp/api/spec/random.h
> +++ b/include/odp/api/spec/random.h
> @@ -59,6 +59,28 @@ typedef enum {
>  int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t
> kind);
> 
>  /**
> + * Generate repeatable random byte data
> + *
> + * For testing purposes it is often useful to generate "random" sequences
> + * that are repeatable. This is accomplished by supplying a seed value
> that
> + * is used for pseudo-random data generation. The caller provides
> + *
> + * @param[out]buf  Output buffer
> + * @param len  Length of output buffer in bytes
> + * @param kind Specifies the type of random data required.
> Request
> + * will fail if the implementation is unable to
> provide
> + * repeatable random of the requested type. This is
> + * always true for true random and may be true for
> + * cryptographic random.
> + * @param[in,out] seed Seed value to use
> + *
> + * @return Number of bytes written
> + * @retval <0 on failure
> + */
> +int32_t odp_random_seeded_data(uint8_t *buf, uint32_t len,
> +odp_random_kind_t kind, uint32_t *seed);
> +

I think it's better to name this explicitly pseudo random (or deterministic 
random), so that people do not by mistake use it instead of the "true" random 
API call. Also "kind" is not needed here. Seed could be larger or even 
implementation defined size. There are larger than 32 bit pseudo random 
functions available  https://linux.die.net/man/3/drand48_r.


/* Uses some bits of init value to initialize the seed */
void odp_random_seed(odp_random_seed_t *seed, uint64_t init_value);

/* Uses a seed to produce a deterministic, pseudo random sequence of data */
int32_t odp_random_pseudo(uint8_t *buf, uint32_t len, odp_random_seed_t *seed);
 

-Petri

Re: [lng-odp] [API-NEXT PATCHv5 1/7] api: random: replace use_entropy with odp_rand_kind parameter

[Bill Fischofer]

On Mon, Dec 5, 2016 at 8:34 AM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>> -int32_t odp_random_data(uint8_t *buf, int32_t size, odp_bool_t
>> use_entropy);
>> +int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t
>> kind);
>
> I think this an acceptable compromise, although int32_t on both (len and 
> return) would help user to pick the type which can be compared directly with 
> return value. I'm OK if this compiles:
>
> uint8_t buf[32];
> int32_t len = sizeof(buf);
>
> if (odp_random_data(buf, len, ODP_RANDOM_TRUE) < len)
> printf("not enough data");

This is what the random.c validation test is doing, so this should be
OK. Are you still looking to split out the capability into a separate
odp_random_capability() API?

>
>
> -Petri

Re: [lng-odp] [API-NEXT PATCHv5 1/7] api: random: replace use_entropy with odp_rand_kind parameter

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

> -int32_t odp_random_data(uint8_t *buf, int32_t size, odp_bool_t
> use_entropy);
> +int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t
> kind);

I think this an acceptable compromise, although int32_t on both (len and 
return) would help user to pick the type which can be compared directly with 
return value. I'm OK if this compiles:

uint8_t buf[32];
int32_t len = sizeof(buf);

if (odp_random_data(buf, len, ODP_RANDOM_TRUE) < len)
printf("not enough data");


-Petri

Re: [lng-odp] [API-NEXT PATCH v4 0/5] new ordered queue implementation

[Maxim Uvarov]

hm, by removing code you break git bisect. (schedule tests hang after
patch 2).

But hope patchset is ok. Will you be ok if all patches will be merged
together?

Maxim.


On 12/02/16 18:38, Bill Fischofer wrote:
> For this series:
> 
> Reviewed-and-tested-by: Bill Fischofer 
> 
> On Fri, Dec 2, 2016 at 4:56 AM, Matias Elo  wrote:
>> V4:
>> - Rebased
>> - Added more static asserts to ordered lock functions (Bill)
>>
>> V3:
>> - Removed old SCHEDULE_ORDERED_LOCKS_PER_QUEUE define (Bill)
>> - Replaced error checks with asserts in ordered lock/unlock (Bill)
>>
>> V2:
>> - Support for multiple ordered locks (Bill)
>> - New ordered lock implementation
>>
>> Add new implementation for ordered queues. Compared to the old
>> implementation this is much simpler and improves performance ~1-4x
>> depending on the test case. Some performance numbers are provided below.
>>
>> The implementation is based on an atomic ordered context, which only a
>> single thread may possess at a time. Only the thread owning the atomic
>> context may do enqueue(s) from the ordered queue. All other threads put
>> their enqueued events to a thread local enqueue stash (ordered_stash_t).
>> All stashed enqueue operations will be performed in the original order when
>> the thread acquires the ordered context. If the ordered stash becomes full,
>> the enqueue blocks. At the latest a thread blocks when the ev_stash is
>> empty and the thread tries to release the order context.
>>
>>
>> The patch set also resolves the following bug:
>> https://bugs.linaro.org/show_bug.cgi?id=2644
>>
>>
>> Performance benchmarks:
>>
>> odp_l2fwd (64B packets)
>>
>> Throughput (Gbps)
>> Cores   Old New Gain (%)
>> 
>> 1:  3.0 7.0 136
>> 2:  3.2 11.1244
>> 4:  5.0 17.6252
>> 6:  5.9 23.0286
>> 8:  7.0 28.6307
>> 10: 8.0 33.6321
>> 12: 8.7 38.2340
>>
>>
>> odp_pktio_ordered (64B packets)
>>
>> Throughput (Gbps)
>> Cores   Old New Gain (%)
>> 
>> 1:  1.2 1.6 33
>> 2:  1.1 1.8 64
>> 4:  1.4 2.6 78
>> 6:  1.3 2.9 125
>> 8:  1.4 3.3 141
>> 10: 1.3 3.5 175
>> 12: 1.2 3.8 213
>>
>> Matias Elo (5):
>>   linux-gen: sched: add internal APIs for locking/unlocking ordered
>> processing
>>   linux-gen: sched: remove old ordered queue implementation
>>   linux-gen: sched: add internal API for max number of ordered locks per
>> queue
>>   linux-gen: sched: new ordered queue implementation
>>   linux-gen: sched: new ordered lock implementation
>>
>>  platform/linux-generic/Makefile.am |   3 -
>>  .../linux-generic/include/odp_buffer_internal.h|   7 -
>>  .../linux-generic/include/odp_config_internal.h|   5 +
>>  .../linux-generic/include/odp_packet_io_queue.h|   5 +-
>>  .../linux-generic/include/odp_queue_internal.h |  33 +-
>>  platform/linux-generic/include/odp_schedule_if.h   |  15 +-
>>  .../linux-generic/include/odp_schedule_internal.h  |  50 --
>>  .../include/odp_schedule_ordered_internal.h|  25 -
>>  platform/linux-generic/odp_packet_io.c |  17 +-
>>  platform/linux-generic/odp_pool.c  |  17 +-
>>  platform/linux-generic/odp_queue.c |  76 +-
>>  platform/linux-generic/odp_schedule.c  | 284 ++-
>>  platform/linux-generic/odp_schedule_ordered.c  | 818 
>> -
>>  platform/linux-generic/odp_schedule_sp.c   |  25 +-
>>  platform/linux-generic/odp_traffic_mngr.c  |  28 +-
>>  platform/linux-generic/pktio/loop.c|   2 +-
>>  16 files changed, 370 insertions(+), 1040 deletions(-)
>>  delete mode 100644 platform/linux-generic/include/odp_schedule_internal.h
>>  delete mode 100644 
>> platform/linux-generic/include/odp_schedule_ordered_internal.h
>>  delete mode 100644 platform/linux-generic/odp_schedule_ordered.c
>>
>> --
>> 2.7.4
>>

[lng-odp] [Bug 2685] New: l2fwd test does not switch output event queues correctly

[bugzilla-daemon]

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

Bug ID: 2685
   Summary: l2fwd test does not switch output event queues
correctly
   Product: OpenDataPlane - linux- generic reference
   Version: v1.12.0.0
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: ---
 Component: General ODP
  Assignee: maxim.uva...@linaro.org
  Reporter: petri.savolai...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

When there are multiple pktios per thread, output event queue handle is not
updated in non-scheduled input mode. This results that output going packets not
switched to correct output event queue (interface).

This patch set corrects the bug:

https://lists.linaro.org/pipermail/lng-odp/2016-December/026882.html

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

Re: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for sched mode

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

Ping.

> -Original Message-
> From: Savolainen, Petri (Nokia - FI/Espoo)
> Sent: Thursday, November 17, 2016 10:14 AM
> To: 'lng-odp@lists.linaro.org' 
> Cc: 'Maxim Uvarov' 
> Subject: RE: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for sched
> mode
> 
> Didn't make it to the list. Sending again.
> 
> > -Original Message-
> > From: Savolainen, Petri (Nokia - FI/Espoo)
> > Sent: Wednesday, November 16, 2016 11:21 AM
> > To: lng-odp@lists.linaro.org
> > Subject: RE: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for sched
> > mode
> >
> > Ping. This set has been on the list two months now.
> >
> > We use l2fwd to measure raw packet IO performance with and without
> > scheduler. As long as the scheduler mode of the application is un-
> > optimized, scheduler mode results are worse than those should be. A
> > perfect HW scheduler does not help, if the test itself loses cycles.
> >
> > -Petri
> >
> >
> >
> > > -Original Message-
> > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > > Savolainen, Petri (Nokia - FI/Espoo)
> > > Sent: Thursday, October 20, 2016 4:27 PM
> > > To: lng-odp@lists.linaro.org
> > > Subject: Re: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for sched
> > > mode
> > >
> > > Ping. Scheduler vs. direct mode performance comparison is more fair
> with
> > > these optimizations. Also corrects bugs.
> > >
> > >
> > > > -Original Message-
> > > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > > > Savolainen, Petri (Nokia - FI/Espoo)
> > > > Sent: Wednesday, October 05, 2016 9:38 AM
> > > > To: lng-odp@lists.linaro.org
> > > > Subject: Re: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for
> sched
> > > > mode
> > > >
> > > > Ping. Review needed. Optimizes sched mode and corrects bugs.
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf
> Of
> > > > > Savolainen, Petri (Nokia - FI/Espoo)
> > > > > Sent: Thursday, September 22, 2016 10:44 AM
> > > > > To: lng-odp@lists.linaro.org
> > > > > Subject: Re: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for
> > sched
> > > > mode
> > > > >
> > > > > Ping. This series optimizes l2fwd schedule mode performance by
> > > enabling
> > > > > lockless packet output (when possible) and corrects a bug in
> > > queue/plain
> > > > > mode forwarding.
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On
> Behalf
> > Of
> > > > > Petri
> > > > > > Savolainen
> > > > > > Sent: Thursday, September 15, 2016 12:51 PM
> > > > > > To: lng-odp@lists.linaro.org
> > > > > > Subject: [lng-odp] [PATCH 1/3] test: l2fwd: lookup table for
> sched
> > > > mode
> > > > > >
> > > > > > Replaced linear destination port search in scheduler mode
> > > > > > with a lookup table. Table index is API provided pktio_index
> > > > > > and data is application port index.
> > > > > >
> > > > > > Signed-off-by: Petri Savolainen 
> > > > > > ---
> > > > > >  test/common_plat/performance/odp_l2fwd.c | 68
> > +++--
> > > --
> > > > --
> > > > > --
> > > > > > -
> > > > > >  1 file changed, 41 insertions(+), 27 deletions(-)

Re: [lng-odp] API-NEXT: mlock for > 64 kb area

[Maxim Uvarov]

On 12/05/16 15:30, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> It does not help to have an mlock flag on API, since application would turn 
> that always "on" to get the best performance. This kind of limits should be 
> left as system configuration problem. Similarly application does not 
> explicitly request huge pages, but those are used if the user is 
> knowledgeable enough to configure the number of those to be large enough for 
> the application(s). User documentation needs just an up-to-date check list of 
> features / limits which affect performance.
> 
> -Petri
> 

yes, my mount for linux-generic that we still need to be able to work on
non mlocked variant and not just fail will error.

Maxim.

> 
> 
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Christophe Milard
>> Sent: Sunday, December 04, 2016 1:39 PM
>> To: Maxim Uvarov 
>> Cc: LNG ODP Mailman List 
>> Subject: Re: [lng-odp] API-NEXT: mlock for > 64 kb area
>>
>> The original patch set had a flag for mlock . Petri requested mlock  for
>> any allocation .  I mentioned the ulimit issue at the arch call if I
>> remember right. I still have a flag on the south API.
>>
>> On 3 Dec 2016 20:24, "Maxim Uvarov"  wrote:
>>
>>> Hello Christophe,
>>>
>>> Found one more thing. It looks like change ulimit for normal user
>>> without modifying system configs is not possible. And default mlock
>>> size is 64 kb. If I understand right - it's value per process. It will
>>> be good at least for linux-generic do not trap execution on failed
>>> mlock. Will remove mlock break any of your logic (drv) ?
>>>
>>>
>>> [pid 29700] munmap(0x7f0f332ec000, 4096) = 0
>>> [pid 29700] mmap(NULL, 71827456, PROT_READ|PROT_WRITE, MAP_SHARED, 11,
>>> 0) = 0x7f0efc841000
>>> [pid 29700] mlock(0x7f0efc841000, 71827456) = -1 ENOMEM (Cannot allocate
>>> memory)
>>>
>>> [pid 29700] munmap(0x7f0efc841000, 71827456) = 0
>>> [pid 29700] write(2, "_ishmphy.c:137:_odp_ishmphy_map("...,
>>> 70_ishmphy.c:137:_odp_ishmphy_map():mlock failed:Cannot allocate memory
>>>
>>> ulimit  -a |grep locked
>>> max locked memory   (kbytes, -l) 64
>>>
>>>
>>> Thank you,
>>> Maxim.
>>>

Re: [lng-odp] API-NEXT: mlock for > 64 kb area

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

It does not help to have an mlock flag on API, since application would turn 
that always "on" to get the best performance. This kind of limits should be 
left as system configuration problem. Similarly application does not explicitly 
request huge pages, but those are used if the user is knowledgeable enough to 
configure the number of those to be large enough for the application(s). User 
documentation needs just an up-to-date check list of features / limits which 
affect performance.

-Petri



> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Christophe Milard
> Sent: Sunday, December 04, 2016 1:39 PM
> To: Maxim Uvarov 
> Cc: LNG ODP Mailman List 
> Subject: Re: [lng-odp] API-NEXT: mlock for > 64 kb area
> 
> The original patch set had a flag for mlock . Petri requested mlock  for
> any allocation .  I mentioned the ulimit issue at the arch call if I
> remember right. I still have a flag on the south API.
> 
> On 3 Dec 2016 20:24, "Maxim Uvarov"  wrote:
> 
> > Hello Christophe,
> >
> > Found one more thing. It looks like change ulimit for normal user
> > without modifying system configs is not possible. And default mlock
> > size is 64 kb. If I understand right - it's value per process. It will
> > be good at least for linux-generic do not trap execution on failed
> > mlock. Will remove mlock break any of your logic (drv) ?
> >
> >
> > [pid 29700] munmap(0x7f0f332ec000, 4096) = 0
> > [pid 29700] mmap(NULL, 71827456, PROT_READ|PROT_WRITE, MAP_SHARED, 11,
> > 0) = 0x7f0efc841000
> > [pid 29700] mlock(0x7f0efc841000, 71827456) = -1 ENOMEM (Cannot allocate
> > memory)
> >
> > [pid 29700] munmap(0x7f0efc841000, 71827456) = 0
> > [pid 29700] write(2, "_ishmphy.c:137:_odp_ishmphy_map("...,
> > 70_ishmphy.c:137:_odp_ishmphy_map():mlock failed:Cannot allocate memory
> >
> > ulimit  -a |grep locked
> > max locked memory   (kbytes, -l) 64
> >
> >
> > Thank you,
> > Maxim.
> >

[lng-odp] [Bug 2683] New: Orphan odp_generator process after make check

[bugzilla-daemon]

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

Bug ID: 2683
   Summary: Orphan odp_generator process after make check
   Product: OpenDataPlane - linux- generic reference
   Version: api-next
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: General ODP
  Assignee: maxim.uva...@linaro.org
  Reporter: petri.savolai...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

Each run of 'sudo make check' in api-next branch leaves behind an orphan
odp_generator process. For example, run 'ps -aux | grep odp' to find it after
'make check' has finished. This is the output in my system:

root 12562  0.0  0.0  19720   456 pts/15   S12:10   0:00 odp_generator
--interval 0 -I pktiop0p1 --srcip 192.168.0.1 --dstip 192.168.0.2 -m u

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

[lng-odp] [Bug 2644] Event order doesn't always hold when new events are allocated within an ordered context

[bugzilla-daemon]

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

--- Comment #3 from Matias Elo  ---
(In reply to Yi He from comment #2)
> Hi, Matias
> 
> Can you confirm if this problem was fixed by Bill's patch
> http://patches.opendataplane.org/patch/7476/.
> 
> Thanks and best regards, Yi

This problem was not fixed by that patch. Patch
http://patches.opendataplane.org/patch/7528/ fixes this bug.

Regards,
Matias

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

Re: [lng-odp] API-NEXT: mlock for > 64 kb area

[Maxim Uvarov]

yes, I want. Some how I missed that part of discussion. I.e. that limit is
actually too small.

On 5 December 2016 at 11:21, Christophe Milard  wrote:

> If you want to re-open that question, schedule it ay tomorrow (tuesday)
> arch call, as I won't be bale to attend neither the arch call nor the sync
> call today due to conflicting compulsory ericsson meetings.
> Thanks,
>
> Christophe
>
> On 4 December 2016 at 12:39, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>> The original patch set had a flag for mlock . Petri requested mlock  for
>> any allocation .  I mentioned the ulimit issue at the arch call if I
>> remember right. I still have a flag on the south API.
>>
>> On 3 Dec 2016 20:24, "Maxim Uvarov"  wrote:
>>
>>> Hello Christophe,
>>>
>>> Found one more thing. It looks like change ulimit for normal user
>>> without modifying system configs is not possible. And default mlock
>>> size is 64 kb. If I understand right - it's value per process. It will
>>> be good at least for linux-generic do not trap execution on failed
>>> mlock. Will remove mlock break any of your logic (drv) ?
>>>
>>>
>>> [pid 29700] munmap(0x7f0f332ec000, 4096) = 0
>>> [pid 29700] mmap(NULL, 71827456, PROT_READ|PROT_WRITE, MAP_SHARED, 11,
>>> 0) = 0x7f0efc841000
>>> [pid 29700] mlock(0x7f0efc841000, 71827456) = -1 ENOMEM (Cannot allocate
>>> memory)
>>>
>>> [pid 29700] munmap(0x7f0efc841000, 71827456) = 0
>>> [pid 29700] write(2, "_ishmphy.c:137:_odp_ishmphy_map("...,
>>> 70_ishmphy.c:137:_odp_ishmphy_map():mlock failed:Cannot allocate memory
>>>
>>> ulimit  -a |grep locked
>>> max locked memory   (kbytes, -l) 64
>>>
>>>
>>> Thank you,
>>> Maxim.
>>>
>>
>

[lng-odp] [API-NEXT PATCH v2 3/7] linux-gen: crypto: add support to new enumerations

[Petri Savolainen]

Added support for new algorithm enumerations and algorithm
capability functions.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_crypto_internal.h|  19 +--
 platform/linux-generic/odp_crypto.c| 180 +++--
 2 files changed, 107 insertions(+), 92 deletions(-)

diff --git a/platform/linux-generic/include/odp_crypto_internal.h 
b/platform/linux-generic/include/odp_crypto_internal.h
index 7b104af..78feb3f 100644
--- a/platform/linux-generic/include/odp_crypto_internal.h
+++ b/platform/linux-generic/include/odp_crypto_internal.h
@@ -14,6 +14,7 @@ extern "C" {
 #include 
 #include 
 
+#define MAX_IV_LEN  64
 #define OP_RESULT_MAGIC 0x91919191
 
 /** Forward declaration of session structure */
@@ -31,16 +32,16 @@ odp_crypto_alg_err_t 
(*crypto_func_t)(odp_crypto_op_params_t *params,
  */
 struct odp_crypto_generic_session {
struct odp_crypto_generic_session *next;
-   odp_crypto_op_t op;
+
+   /* Session creation parameters */
+   odp_crypto_session_params_t p;
+
odp_bool_t do_cipher_first;
-   odp_queue_t compl_queue;
-   odp_pool_t output_pool;
+
struct {
-   odp_cipher_alg_t   alg;
-   struct {
-   uint8_t *data;
-   size_t   len;
-   } iv;
+   /* Copy of session IV data */
+   uint8_t iv_data[MAX_IV_LEN];
+
union {
struct {
DES_key_schedule ks1;
@@ -56,8 +57,8 @@ struct odp_crypto_generic_session {
} data;
crypto_func_t func;
} cipher;
+
struct {
-   odp_auth_alg_t  alg;
union {
struct {
uint8_t  key[16];
diff --git a/platform/linux-generic/odp_crypto.c 
b/platform/linux-generic/odp_crypto.c
index 453d6b7..a64b5a2 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -249,8 +249,8 @@ odp_crypto_alg_err_t aes_encrypt(odp_crypto_op_params_t 
*params,
 
if (params->override_iv_ptr)
iv_ptr = params->override_iv_ptr;
-   else if (session->cipher.iv.data)
-   iv_ptr = session->cipher.iv.data;
+   else if (session->p.iv.data)
+   iv_ptr = session->cipher.iv_data;
else
return ODP_CRYPTO_ALG_ERR_IV_INVALID;
 
@@ -281,8 +281,8 @@ odp_crypto_alg_err_t aes_decrypt(odp_crypto_op_params_t 
*params,
 
if (params->override_iv_ptr)
iv_ptr = params->override_iv_ptr;
-   else if (session->cipher.iv.data)
-   iv_ptr = session->cipher.iv.data;
+   else if (session->p.iv.data)
+   iv_ptr = session->cipher.iv_data;
else
return ODP_CRYPTO_ALG_ERR_IV_INVALID;
 
@@ -302,22 +302,20 @@ odp_crypto_alg_err_t aes_decrypt(odp_crypto_op_params_t 
*params,
return ODP_CRYPTO_ALG_ERR_NONE;
 }
 
-static
-int process_aes_params(odp_crypto_generic_session_t *session,
-  odp_crypto_session_params_t *params)
+static int process_aes_params(odp_crypto_generic_session_t *session)
 {
/* Verify IV len is either 0 or 16 */
-   if (!((0 == params->iv.length) || (16 == params->iv.length)))
+   if (!((0 == session->p.iv.length) || (16 == session->p.iv.length)))
return -1;
 
/* Set function */
-   if (ODP_CRYPTO_OP_ENCODE == params->op) {
+   if (ODP_CRYPTO_OP_ENCODE == session->p.op) {
session->cipher.func = aes_encrypt;
-   AES_set_encrypt_key(params->cipher_key.data, 128,
+   AES_set_encrypt_key(session->p.cipher_key.data, 128,
>cipher.data.aes.key);
} else {
session->cipher.func = aes_decrypt;
-   AES_set_decrypt_key(params->cipher_key.data, 128,
+   AES_set_decrypt_key(session->p.cipher_key.data, 128,
>cipher.data.aes.key);
}
 
@@ -340,8 +338,8 @@ odp_crypto_alg_err_t aes_gcm_encrypt(odp_crypto_op_params_t 
*params,
 
if (params->override_iv_ptr)
iv_ptr = params->override_iv_ptr;
-   else if (session->cipher.iv.data)
-   iv_ptr = session->cipher.iv.data;
+   else if (session->p.iv.data)
+   iv_ptr = session->cipher.iv_data;
else
return ODP_CRYPTO_ALG_ERR_IV_INVALID;
 
@@ -405,8 +403,8 @@ odp_crypto_alg_err_t aes_gcm_decrypt(odp_crypto_op_params_t 
*params,
 
if (params->override_iv_ptr)
iv_ptr = params->override_iv_ptr;
-   else if (session->cipher.iv.data)
-   iv_ptr = session->cipher.iv.data;
+   else if (session->p.iv.data)
+   iv_ptr = session->cipher.iv_data;
else
return ODP_CRYPTO_ALG_ERR_IV_INVALID;
 
@@ -455,19 +453,17 @@ 

[lng-odp] [API-NEXT PATCH v2 5/7] api: crypto: documentation clean up

[Petri Savolainen]

Moved documentation of struct fields over each field. Removed
references to buffers as crypto API works only with packets.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/crypto.h | 235 ++
 1 file changed, 149 insertions(+), 86 deletions(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 22fd735..5ce037a 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -198,109 +198,158 @@ typedef union odp_crypto_auth_algos_t {
  * Crypto API key structure
  */
 typedef struct odp_crypto_key {
-   uint8_t *data;   /**< Key data */
-   uint32_t length; /**< Key length in bytes */
+   /** Key data */
+   uint8_t *data;
+
+   /** Key length in bytes */
+   uint32_t length;
+
 } odp_crypto_key_t;
 
 /**
  * Crypto API IV structure
  */
 typedef struct odp_crypto_iv {
-   uint8_t *data;  /**< IV data */
-   uint32_t length;/**< IV length in bytes */
+   /** IV data */
+   uint8_t *data;
+
+   /** IV length in bytes */
+   uint32_t length;
+
 } odp_crypto_iv_t;
 
 /**
  * Crypto API data range specifier
  */
 typedef struct odp_crypto_data_range {
-   uint32_t offset;  /**< Offset from beginning of buffer (chain) */
-   uint32_t length;  /**< Length of data to operate on */
+   /** Offset from beginning of packet */
+   uint32_t offset;
+
+   /** Length of data to operate on */
+   uint32_t length;
+
 } odp_crypto_data_range_t;
 
 /**
  * Crypto API session creation parameters
  */
 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;
+   /** Encode vs. decode operation */
+   odp_crypto_op_t op;
 
-/**
- * @var odp_crypto_session_params_t::auth_cipher_text
- *
- *   Controls ordering of authentication and cipher operations,
- *   and is relative to the operation (encode vs decode).
- *   When encoding, @c TRUE indicates the authentication operation
- *   should be performed @b after the cipher operation else before.
- *   When decoding, @c TRUE indicates the reverse order of operation.
- *
- * @var odp_crypto_session_params_t::compl_queue
- *
- *   When the API operates asynchronously, the completion queue is
- *   used to return the completion status of the operation to the
- *   application.
- *
- * @var odp_crypto_session_params_t::output_pool
- *
- *   When the output packet is not specified during the call to
- *   odp_crypto_operation, the output packet buffer will be allocated
- *   from this pool.
- */
+   /** Authenticate cipher vs. plain text
+*
+*  Controls ordering of authentication and cipher operations,
+*  and is relative to the operation (encode vs decode). When encoding,
+*  TRUE indicates the authentication operation should be performed
+*  after the cipher operation else before. When decoding, TRUE
+*  indicates the reverse order of operation.
+*
+*  true:  Authenticate cipher text
+*  false: Authenticate plain text
+*/
+   odp_bool_t auth_cipher_text;
+
+   /** Preferred sync vs. async */
+   odp_crypto_op_mode_t pref_mode;
+
+   /** Cipher algorithm
+*
+*  Use odp_crypto_capability() for supported algorithms.
+*/
+   odp_cipher_alg_t cipher_alg;
+
+   /** Cipher key
+*
+* Use odp_crypto_cipher_capa() for supported key and IV lengths.
+*/
+   odp_crypto_key_t cipher_key;
+
+   /** Cipher Initialization Vector (IV) */
+   odp_crypto_iv_t iv;
+
+   /** Authentication algorithm
+*
+*  Use odp_crypto_capability() for supported algorithms.
+*/
+   odp_auth_alg_t auth_alg;
+
+   /** Authentication key
+*
+*  Use odp_crypto_auth_capa() for supported digest and key lengths.
+*/
+   odp_crypto_key_t auth_key;
+
+   /** Async mode completion event queue
+*
+*  When odp_crypto_operation() is asynchronous, the completion queue is
+*  used to return the completion status of the operation to the
+*  application.
+*/
+   odp_queue_t compl_queue;
+
+   

[lng-odp] [API-NEXT PATCH v2 7/7] validation: crypto: use algorithm capability

[Petri Savolainen]

Use new algorithm enumerations and capability functions.

Signed-off-by: Petri Savolainen 
---
 .../validation/api/crypto/odp_crypto_test_inp.c| 113 -
 1 file changed, 85 insertions(+), 28 deletions(-)

diff --git a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c 
b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
index 780380f..57223af 100644
--- a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
+++ b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
@@ -11,6 +11,8 @@
 #include "odp_crypto_test_inp.h"
 #include "crypto.h"
 
+#define MAX_ALG_CAPA 32
+
 struct suite_context_s {
odp_crypto_op_mode_t pref_mode;
odp_pool_t pool;
@@ -42,8 +44,7 @@ static void alg_test(odp_crypto_op_t op,
 const uint8_t *ciphertext,
 unsigned int ciphertext_len,
 const uint8_t *digest,
-unsigned int digest_len
-)
+uint32_t digest_len)
 {
odp_crypto_session_t session;
odp_crypto_capability_t capability;
@@ -57,6 +58,10 @@ static void alg_test(odp_crypto_op_t op,
odp_crypto_op_params_t op_params;
uint8_t *data_addr;
int data_off;
+   odp_crypto_cipher_capa_t cipher_capa[MAX_ALG_CAPA];
+   odp_crypto_auth_capa_t   auth_capa[MAX_ALG_CAPA];
+   int num, i;
+   int found;
 
rc = odp_crypto_capability();
CU_ASSERT(!rc);
@@ -65,36 +70,36 @@ static void alg_test(odp_crypto_op_t op,
if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
!(capability.hw_ciphers.bit.trides_cbc))
rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES128_CBC &&
-   !(capability.hw_ciphers.bit.aes128_cbc))
+   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
+   !(capability.hw_ciphers.bit.aes_cbc))
rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES128_GCM &&
-   !(capability.hw_ciphers.bit.aes128_gcm))
+   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
+   !(capability.hw_ciphers.bit.aes_gcm))
rc = -1;
} else {
if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
!(capability.ciphers.bit.trides_cbc))
rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES128_CBC &&
-   !(capability.ciphers.bit.aes128_cbc))
+   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
+   !(capability.ciphers.bit.aes_cbc))
rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES128_GCM &&
-   !(capability.ciphers.bit.aes128_gcm))
+   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
+   !(capability.ciphers.bit.aes_gcm))
rc = -1;
}
 
CU_ASSERT(!rc);
 
if (capability.hw_auths.all_bits) {
-   if (auth_alg == ODP_AUTH_ALG_AES128_GCM &&
-   !(capability.hw_auths.bit.aes128_gcm))
+   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
+   !(capability.hw_auths.bit.aes_gcm))
rc = -1;
if (auth_alg == ODP_AUTH_ALG_NULL &&
!(capability.hw_auths.bit.null))
rc = -1;
} else {
-   if (auth_alg == ODP_AUTH_ALG_AES128_GCM &&
-   !(capability.auths.bit.aes128_gcm))
+   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
+   !(capability.auths.bit.aes_gcm))
rc = -1;
if (auth_alg == ODP_AUTH_ALG_NULL &&
!(capability.auths.bit.null))
@@ -103,6 +108,58 @@ static void alg_test(odp_crypto_op_t op,
 
CU_ASSERT(!rc);
 
+   num = odp_crypto_cipher_capa(cipher_alg, cipher_capa, MAX_ALG_CAPA);
+
+   if (cipher_alg != ODP_CIPHER_ALG_NULL) {
+   CU_ASSERT(num > 0);
+   found = 0;
+   } else {
+   CU_ASSERT(num == 0);
+   found = 1;
+   }
+
+   CU_ASSERT(num <= MAX_ALG_CAPA);
+
+   if (num > MAX_ALG_CAPA)
+   num = MAX_ALG_CAPA;
+
+   /* Search for the test case */
+   for (i = 0; i < num; i++) {
+   if (cipher_capa[i].key_len == cipher_key.length &&
+   cipher_capa[i].iv_len  == ses_iv.length) {
+   found = 1;
+   break;
+   }
+   }
+
+   CU_ASSERT(found);
+
+   num = odp_crypto_auth_capa(auth_alg, auth_capa, MAX_ALG_CAPA);
+
+   if (auth_alg != ODP_AUTH_ALG_NULL) {
+   CU_ASSERT(num > 0);
+   found = 0;
+   } else {
+   CU_ASSERT(num == 0);
+   found = 1;
+   }
+
+   CU_ASSERT(num <= MAX_ALG_CAPA);
+
+   if 

[lng-odp] [API-NEXT PATCH v2 1/7] api: crypto: decouple key length from algorithm enumeration

[Petri Savolainen]

Enumerations for cipher and authentication algorithms grow
fast if key and digest lengths are included into the enum.
Decoupled lengths from algorithm names, only exception is
SHA-2 family of authentication algorithms which has established
naming convention with digest lengths (SHA-224, SHA-256, ...).
Old enumerations are still functional but deprecated.

Algotrithm level capability functions provide a flexible way to
handle all possible key/digest/iv length combinations.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/crypto.h | 167 --
 1 file changed, 146 insertions(+), 21 deletions(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 0cb8814..b136a80 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -65,14 +65,28 @@ typedef enum {
 typedef enum {
/** No cipher algorithm specified */
ODP_CIPHER_ALG_NULL,
+
/** DES */
ODP_CIPHER_ALG_DES,
+
/** Triple DES with cipher block chaining */
ODP_CIPHER_ALG_3DES_CBC,
-   /** AES128 with cipher block chaining */
+
+   /** AES with cipher block chaining */
+   ODP_CIPHER_ALG_AES_CBC,
+
+   /** AES in Galois/Counter Mode
+*
+*  @note Must be paired with cipher ODP_AUTH_ALG_AES_GCM
+*/
+   ODP_CIPHER_ALG_AES_GCM,
+
+   /** @deprecated  Use ODP_CIPHER_ALG_AES_CBC instead */
ODP_CIPHER_ALG_AES128_CBC,
-   /** AES128 in Galois/Counter Mode */
-   ODP_CIPHER_ALG_AES128_GCM,
+
+   /** @deprecated  Use ODP_CIPHER_ALG_AES_GCM instead */
+   ODP_CIPHER_ALG_AES128_GCM
+
 } odp_cipher_alg_t;
 
 /**
@@ -81,12 +95,33 @@ typedef enum {
 typedef enum {
 /** No authentication algorithm specified */
ODP_AUTH_ALG_NULL,
-   /** HMAC-MD5 with 96 bit key */
+
+   /** HMAC-MD5
+*
+* MD5 algorithm in HMAC mode
+*/
+   ODP_AUTH_ALG_MD5_HMAC,
+
+   /** HMAC-SHA-256
+*
+*  SHA-256 algorithm in HMAC mode
+*/
+   ODP_AUTH_ALG_SHA256_HMAC,
+
+   /** AES in Galois/Counter Mode
+*
+*  @note Must be paired with cipher ODP_CIPHER_ALG_AES_GCM
+*/
+   ODP_AUTH_ALG_AES_GCM,
+
+   /** @deprecated  Use ODP_AUTH_ALG_MD5_HMAC instead */
ODP_AUTH_ALG_MD5_96,
-   /** SHA256 with 128 bit key */
+
+   /** @deprecated  Use ODP_AUTH_ALG_SHA256_HMAC instead */
ODP_AUTH_ALG_SHA256_128,
-   /** AES128 in Galois/Counter Mode */
-   ODP_AUTH_ALG_AES128_GCM,
+
+   /** @deprecated  Use ODP_AUTH_ALG_AES_GCM instead */
+   ODP_AUTH_ALG_AES128_GCM
 } odp_auth_alg_t;
 
 /**
@@ -96,19 +131,25 @@ typedef union odp_crypto_cipher_algos_t {
/** Cipher algorithms */
struct {
/** ODP_CIPHER_ALG_NULL */
-   uint32_t null   : 1;
+   uint32_t null: 1;
 
/** ODP_CIPHER_ALG_DES */
-   uint32_t des: 1;
+   uint32_t des : 1;
 
/** ODP_CIPHER_ALG_3DES_CBC */
-   uint32_t trides_cbc : 1;
+   uint32_t trides_cbc  : 1;
+
+   /** ODP_CIPHER_ALG_AES_CBC */
+   uint32_t aes_cbc : 1;
 
-   /** ODP_CIPHER_ALG_AES128_CBC */
-   uint32_t aes128_cbc : 1;
+   /** ODP_CIPHER_ALG_AES_GCM */
+   uint32_t aes_gcm : 1;
 
-   /** ODP_CIPHER_ALG_AES128_GCM */
-   uint32_t aes128_gcm : 1;
+   /** @deprecated  Use aes_cbc instead */
+   uint32_t aes128_cbc  : 1;
+
+   /** @deprecated  Use aes_gcm instead */
+   uint32_t aes128_gcm  : 1;
} bit;
 
/** All bits of the bit field structure
@@ -125,16 +166,25 @@ typedef union odp_crypto_auth_algos_t {
/** Authentication algorithms */
struct {
/** ODP_AUTH_ALG_NULL */
-   uint32_t null   : 1;
+   uint32_t null: 1;
+
+   /** ODP_AUTH_ALG_MD5_HMAC */
+   uint32_t md5_hmac: 1;
+
+   /** ODP_AUTH_ALG_SHA256_HMAC */
+   uint32_t sha256_hmac : 1;
 
-   /** ODP_AUTH_ALG_MD5_96 */
-   uint32_t md5_96 : 1;
+   /** ODP_AUTH_ALG_AES_GCM */
+   uint32_t aes_gcm : 1;
 
-   /** ODP_AUTH_ALG_SHA256_128 */
-   uint32_t sha256_128 : 1;
+   /** @deprecated  Use md5_hmac instead */
+   uint32_t md5_96  : 1;
 
-   /** ODP_AUTH_ALG_AES128_GCM */
-   uint32_t aes128_gcm : 1;
+   /** @deprecated  Use sha256_hmac instead */
+   uint32_t sha256_128  : 1;
+
+   /** @deprecated  Use aes_gcm instead */
+   uint32_t aes128_gcm  : 1;
} bit;
 
/** All bits of the bit field structure
@@ -335,6 

[lng-odp] [API-NEXT PATCH v2 2/7] linux-gen: crypto: add algo capability functions

[Petri Savolainen]

Implemented cipher and authentication algorithm capability
functions.

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/odp_crypto.c | 107 
 1 file changed, 107 insertions(+)

diff --git a/platform/linux-generic/odp_crypto.c 
b/platform/linux-generic/odp_crypto.c
index 7e686ff..453d6b7 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -27,6 +27,37 @@
 
 #define MAX_SESSIONS 32
 
+/*
+ * Cipher algorithm capabilities
+ *
+ * Keep sorted: first by key length, then by IV length
+ */
+static const odp_crypto_cipher_capa_t cipher_capa_des[] = {
+{.key_len = 24, .iv_len = 8} };
+
+static const odp_crypto_cipher_capa_t cipher_capa_trides_cbc[] = {
+{.key_len = 24, .iv_len = 8} };
+
+static const odp_crypto_cipher_capa_t cipher_capa_aes_cbc[] = {
+{.key_len = 16, .iv_len = 16} };
+
+static const odp_crypto_cipher_capa_t cipher_capa_aes_gcm[] = {
+{.key_len = 16, .iv_len = 12} };
+
+/*
+ * Authentication algorithm capabilities
+ *
+ * Keep sorted: first by digest length, then by key length
+ */
+static const odp_crypto_auth_capa_t auth_capa_md5_hmac[] = {
+{.digest_len = 12, .key_len = 16, .aad_len = {.min = 0, .max = 0, .inc = 0} } 
};
+
+static const odp_crypto_auth_capa_t auth_capa_sha256_hmac[] = {
+{.digest_len = 16, .key_len = 32, .aad_len = {.min = 0, .max = 0, .inc = 0} } 
};
+
+static const odp_crypto_auth_capa_t auth_capa_aes_gcm[] = {
+{.digest_len = 16, .key_len = 0, .aad_len = {.min = 8, .max = 12, .inc = 4} } 
};
+
 typedef struct odp_crypto_global_s odp_crypto_global_t;
 
 struct odp_crypto_global_s {
@@ -623,6 +654,82 @@ int odp_crypto_capability(odp_crypto_capability_t *capa)
return 0;
 }
 
+int odp_crypto_cipher_capa(odp_cipher_alg_t cipher,
+  odp_crypto_cipher_capa_t dst[], int num_copy)
+{
+   const odp_crypto_cipher_capa_t *src;
+   int num;
+   int size = sizeof(odp_crypto_cipher_capa_t);
+
+   switch (cipher) {
+   case ODP_CIPHER_ALG_NULL:
+   src = NULL;
+   num = 0;
+   break;
+   case ODP_CIPHER_ALG_DES:
+   src = cipher_capa_des;
+   num = sizeof(cipher_capa_des) / size;
+   break;
+   case ODP_CIPHER_ALG_3DES_CBC:
+   src = cipher_capa_trides_cbc;
+   num = sizeof(cipher_capa_trides_cbc) / size;
+   break;
+   case ODP_CIPHER_ALG_AES_CBC:
+   src = cipher_capa_aes_cbc;
+   num = sizeof(cipher_capa_aes_cbc) / size;
+   break;
+   case ODP_CIPHER_ALG_AES_GCM:
+   src = cipher_capa_aes_gcm;
+   num = sizeof(cipher_capa_aes_gcm) / size;
+   break;
+   default:
+   return -1;
+   }
+
+   if (num < num_copy)
+   num_copy = num;
+
+   memcpy(dst, src, num_copy * size);
+
+   return num;
+}
+
+int odp_crypto_auth_capa(odp_auth_alg_t auth,
+odp_crypto_auth_capa_t dst[], int num_copy)
+{
+   const odp_crypto_auth_capa_t *src;
+   int num;
+   int size = sizeof(odp_crypto_auth_capa_t);
+
+   switch (auth) {
+   case ODP_AUTH_ALG_NULL:
+   src = NULL;
+   num = 0;
+   break;
+   case ODP_AUTH_ALG_MD5_HMAC:
+   src = auth_capa_md5_hmac;
+   num = sizeof(auth_capa_md5_hmac) / size;
+   break;
+   case ODP_AUTH_ALG_SHA256_HMAC:
+   src = auth_capa_sha256_hmac;
+   num = sizeof(auth_capa_sha256_hmac) / size;
+   break;
+   case ODP_AUTH_ALG_AES_GCM:
+   src = auth_capa_aes_gcm;
+   num = sizeof(auth_capa_aes_gcm) / size;
+   break;
+   default:
+   return -1;
+   }
+
+   if (num < num_copy)
+   num_copy = num;
+
+   memcpy(dst, src, num_copy * size);
+
+   return num;
+}
+
 int
 odp_crypto_session_create(odp_crypto_session_params_t *params,
  odp_crypto_session_t *session_out,
-- 
2.8.1

[lng-odp] [API-NEXT PATCH v2 6/7] test: crypto: use odp_crypto_session_params_init

[Petri Savolainen]

Use session params init function instead of memset() to zero.

Signed-off-by: Petri Savolainen 
---
 example/ipsec/odp_ipsec_cache.c  | 2 ++
 test/common_plat/performance/odp_crypto.c| 1 +
 test/common_plat/validation/api/crypto/odp_crypto_test_inp.c | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/example/ipsec/odp_ipsec_cache.c b/example/ipsec/odp_ipsec_cache.c
index 2bd44cf..35d9ecf 100644
--- a/example/ipsec/odp_ipsec_cache.c
+++ b/example/ipsec/odp_ipsec_cache.c
@@ -60,6 +60,8 @@ int create_ipsec_cache_entry(sa_db_entry_t *cipher_sa,
(cipher_sa->mode != auth_sa->mode))
return -1;
 
+   odp_crypto_session_params_init();
+
/* Setup parameters and call crypto library to create session */
params.op = (in) ? ODP_CRYPTO_OP_DECODE : ODP_CRYPTO_OP_ENCODE;
params.auth_cipher_text = TRUE;
diff --git a/test/common_plat/performance/odp_crypto.c 
b/test/common_plat/performance/odp_crypto.c
index 39df78b..72f6220 100644
--- a/test/common_plat/performance/odp_crypto.c
+++ b/test/common_plat/performance/odp_crypto.c
@@ -425,6 +425,7 @@ create_session_from_config(odp_crypto_session_t *session,
odp_pool_t pkt_pool;
odp_queue_t out_queue;
 
+   odp_crypto_session_params_init();
memcpy(, >session, sizeof(odp_crypto_session_params_t));
params.op = ODP_CRYPTO_OP_ENCODE;
params.pref_mode   = ODP_CRYPTO_SYNC;
diff --git a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c 
b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
index 4ac4a07..780380f 100644
--- a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
+++ b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
@@ -104,7 +104,7 @@ static void alg_test(odp_crypto_op_t op,
CU_ASSERT(!rc);
 
/* Create a crypto session */
-   memset(_params, 0, sizeof(ses_params));
+   odp_crypto_session_params_init(_params);
ses_params.op = op;
ses_params.auth_cipher_text = false;
ses_params.pref_mode = suite_context.pref_mode;
-- 
2.8.1

[lng-odp] [API-NEXT PATCH v2 4/7] api: crypto: added session params init

[Petri Savolainen]

Added session parameters init function which should be
used to initialize the structure before calling
odp_crypto_session_create().

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/crypto.h   | 16 +++-
 platform/linux-generic/odp_crypto.c |  5 +
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index b136a80..22fd735 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -472,7 +472,11 @@ int odp_crypto_auth_capa(odp_auth_alg_t auth,
 odp_crypto_auth_capa_t capa[], int num);
 
 /**
- * Crypto session creation (synchronous)
+ * Crypto session creation
+ *
+ * Create a crypto session according to the session parameters. Use
+ * odp_crypto_session_params_init() to initialize parameters into their
+ * default values.
  *
  * @param paramsSession parameters
  * @param session   Created session else ODP_CRYPTO_SESSION_INVALID
@@ -582,6 +586,16 @@ uint64_t odp_crypto_session_to_u64(odp_crypto_session_t 
hdl);
 uint64_t odp_crypto_compl_to_u64(odp_crypto_compl_t hdl);
 
 /**
+ * Initialize crypto session parameters
+ *
+ * Initialize an odp_crypto_session_params_t to its default values for
+ * all fields.
+ *
+ * @param params   Pointer to odp_crypto_session_params_t to be initialized
+ */
+void odp_crypto_session_params_init(odp_crypto_session_params_t *params);
+
+/**
  * @}
  */
 
diff --git a/platform/linux-generic/odp_crypto.c 
b/platform/linux-generic/odp_crypto.c
index a64b5a2..bdb06a9 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -1041,3 +1041,8 @@ odp_crypto_compl_free(odp_crypto_compl_t completion_event)
odp_buffer_from_event((odp_event_t)completion_event),
ODP_EVENT_PACKET);
 }
+
+void odp_crypto_session_params_init(odp_crypto_session_params_t *params)
+{
+   memset(params, 0, sizeof(odp_crypto_session_params_t));
+}
-- 
2.8.1

[lng-odp] [API-NEXT PATCH v2 0/7] crypto key length capability

[Petri Savolainen]

Various cipher and authentication algorithms support multiple key/IV/digest 
lengths. It's not a scalable solution to define these lengths as part of 
algorithm enumeration. This patch set deprecates enumerations (e.g. 
ODP_CIPHER_ALG_AES128_CBC) with length definitions. Those are still supported 
but will be removed in next API version. New enumerations define only
algorithm names, with the exception of SHA-2 family of algorithms which are 
commonly referred with their digest length (such as SHA-256). The supported 
key/IV/digest lengths are requested with two new functions 
odp_crypto_cipher_capa() and odp_crypto_auth_capa(). Usage of HMAC is included 
into authentication algorithm name (it used to be implicit). Only currently 
supported and validation tested algorithms are defined, but later on e.g. MD5 
or SHA-256 (without HMAC) may be defined as well as a set of new algorithms.

Supported key/IV/digest lengths are set to values that pass current validation 
test suite. Some tests may need to be updated with their key/IV/digest length 
usage. For example, AES-GCM authentication test uses key length of zero bytes 
(since it's paired with AES-GCM cipher).


Petri Savolainen (7):
  api: crypto: decouple key length from algorithm enumeration
  linux-gen: crypto: add algo capability functions
  linux-gen: crypto: add support to new enumerations
  api: crypto: added session params init
  api: crypto: documentation clean up
  test: crypto: use odp_crypto_session_params_init
  validation: crypto: use algorithm capability

 example/ipsec/odp_ipsec_cache.c|   2 +
 include/odp/api/spec/crypto.h  | 418 +++--
 .../linux-generic/include/odp_crypto_internal.h|  19 +-
 platform/linux-generic/odp_crypto.c| 293 +++
 test/common_plat/performance/odp_crypto.c  |   1 +
 .../validation/api/crypto/odp_crypto_test_inp.c| 115 --
 6 files changed, 619 insertions(+), 229 deletions(-)

-- 
2.8.1

Re: [lng-odp] clarification of pktout checksum offload feature

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

Hi,

> > There is also a second thing: how to disable checksum calculation
> > per-packet?

> We've talked about doing this but currently have no APIs for exposing this
> capability. Do you have a use case in mind?

The use cases include many UDP based tunneling protocols that want to disable
checksumming to save processing capacity both locally and in the other end.
These include VxLAN, IPsec-over-UDP, MPLS-over-UDP, GTP.

For instance, the VxLAN RFC says that the UDP checksum SHOULD be set to zero,
but currently there is no reliable way for an ODP application to do so if
the checksum offload feature is enabled in the output interface.

The pktin side could also benefit from checksum API changes. It seems that
now the ODP application must assume that L4 checksum was calculated if the
feature was enabled in the pktin config and if the received packet was UDP,
TCP or SCTP and if the packet was not a fragment. Per-packet checksum flags
could be more robust and convenient.

Janne


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill 
> Fischofer
> Sent: Wednesday, October 19, 2016 6:25 PM
> To: Maciej Czekaj 
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] clarification of pktout checksum offload feature
> 
> Hi Maciej, sorry for the delay in getting a response to you on this. See
> inline.
> 
> On Thu, Oct 13, 2016 at 6:33 AM, Maciej Czekaj <
> maciej.cze...@caviumnetworks.com> wrote:
> 
> >
> > Guys,
> >
> > I was going to implement checksum offload for OFP project based on Monarch
> > checksum offload capability and I found out that there is no example for
> > using that API. Also, documentation seams to leave some room for various
> > interpretations, so I would like to clarify that and post a patch to
> > documentation, too.
> >
> >
> > This is an exempt from pktio.h from Monarch LTS:
> >
> >
> > /**
> >  * Packet output configuration options bit field
> >  *
> >  * Packet output configuration options listed in a bit field structure.
> > Packet
> >  * output checksum insertion may be enabled or disabled. When it is
> > enabled,
> >  * implementation will calculate and insert checksum into every outgoing
> > packet
> >  * by default. Application may use a packet metadata flag to disable
> > checksum
> >  * insertion per packet bases. For correct operation, packet metadata must
> >  * provide valid offsets for the appropriate protocols. For example, UDP
> >  * checksum calculation needs both L3 and L4 offsets (to access IP and UDP
> >  * headers). When application (e.g. a switch) does not modify L3/L4 data
> > and
> >  * thus checksum does not need to be updated, output checksum insertion
> > should
> >  * be disabled for optimal performance.
> >
> >
> >
> > From my contact with varoius NICs, including Octeon PKO & VNIC from
> > ThunderX, offloading H/W needs at least:
> >
> > For L4 offload:
> > L4 packet type: TCP/UDP/SCTP
> > L4 header offset
> > L3 header offset
> > L3 type may or may not be required but it is good to define it for
> > consistency
> >
> > For L3 checksum:
> > L3 packet type: IPv4
> > L3 header offset
> >
> 
> Yes, this info will be set by the ODP classifier. If you're constructing
> packets "by hand" then these fields should be set with appropriate
> odp_packet_xxx_set() calls.
> 
> 
> >
> > There is also a second thing: how to disable checksum calculation
> > per-packet?
> > If packet has no type in metadata, then obviously checksum will not be
> > computed. I think that would be the recommended method for now, even if ODP
> > community plans to  extend odp_packet API in the future to cover that case.
> >
> 
> We've talked about doing this but currently have no APIs for exposing this
> capability. Do you have a use case in mind?
> 
> 
> >
> > Maybe that is implicit that packet types should be set along header
> > offsets, but it is good to state that clearly and provide some usage
> > example, e.g. in examples/generator. I can send a patch for both doc and
> > generator but I would like to make sure we are on the same page.
> >
> 
> Patches always welcome. :)
> 
> Thanks.
> 
> 
> >
> >
> > Regards
> > Maciej
> >
> >
> >
> >

Re: [lng-odp] API-NEXT: mlock for > 64 kb area

[Christophe Milard]

If you want to re-open that question, schedule it ay tomorrow (tuesday)
arch call, as I won't be bale to attend neither the arch call nor the sync
call today due to conflicting compulsory ericsson meetings.
Thanks,

Christophe

On 4 December 2016 at 12:39, Christophe Milard  wrote:

> The original patch set had a flag for mlock . Petri requested mlock  for
> any allocation .  I mentioned the ulimit issue at the arch call if I
> remember right. I still have a flag on the south API.
>
> On 3 Dec 2016 20:24, "Maxim Uvarov"  wrote:
>
>> Hello Christophe,
>>
>> Found one more thing. It looks like change ulimit for normal user
>> without modifying system configs is not possible. And default mlock
>> size is 64 kb. If I understand right - it's value per process. It will
>> be good at least for linux-generic do not trap execution on failed
>> mlock. Will remove mlock break any of your logic (drv) ?
>>
>>
>> [pid 29700] munmap(0x7f0f332ec000, 4096) = 0
>> [pid 29700] mmap(NULL, 71827456, PROT_READ|PROT_WRITE, MAP_SHARED, 11,
>> 0) = 0x7f0efc841000
>> [pid 29700] mlock(0x7f0efc841000, 71827456) = -1 ENOMEM (Cannot allocate
>> memory)
>>
>> [pid 29700] munmap(0x7f0efc841000, 71827456) = 0
>> [pid 29700] write(2, "_ishmphy.c:137:_odp_ishmphy_map("...,
>> 70_ishmphy.c:137:_odp_ishmphy_map():mlock failed:Cannot allocate memory
>>
>> ulimit  -a |grep locked
>> max locked memory   (kbytes, -l) 64
>>
>>
>> Thank you,
>> Maxim.
>>
>