date:20170111

Re: [lng-odp] [API-NEXTv5 1/6] linux-gen: _ishm: adding buddy and slab allocation

2017-01-11 Thread Yi He

Hi, Christophe,

Q1: this patchset name seems a little problem: API-NEXTv5 -> API-NEXT
PATCHv5

Q2: the 1/6 patch cannot be applied to the api-next, I've tried to fix to
continue the test but did not work, need to re-base and I'll test then.

For the patchset code looks OK to me and below questions are to clarify the
usage of these APIs:

Q3: In the practical usage does it mean all ishmpool creations need to be
happened in
1st control thread before all other threads spawning?

Otherwise if a worker ODP thread spawn firstly and after then create an
ishmpool, the
memories allocated from this pool seems won't be accessible to other ODP
threads? because
the shm_attach and mmap did not happen in other ODP threads (processes).

So control thread needs to collect all worker threads requirements on small
memory size
requirements and creates all ishmpools in a batch manner before spawning
worker threads?

Understand the typical usage:

If the size requirements of small memory are not very specific, create one
or several pools of
range [min, max] to support small memory allocation.

If the size requirements of small memory are specific, for example to
specific data
structure or small packets, create several pools of dedicated [size].

Thanks and best regards, Yi

On 3 January 2017 at 23:10, Christophe Milard 
wrote:

> _ishm now provides functions to create/destroy pools for buddy/slab
> memory allocation, as well as functions to allocated/release memory

from the created pools.
>
> Signed-off-by: Christophe Milard 
> ---
>  platform/linux-generic/Makefile.am |   2 +
>  platform/linux-generic/_ishm.c |  14 +-
>  platform/linux-generic/_ishmpool.c | 811
> +
>  .../linux-generic/include/_ishmpool_internal.h |  56 ++
>  4 files changed, 882 insertions(+), 1 deletion(-)
>  create mode 100644 platform/linux-generic/_ishmpool.c
>  create mode 100644 platform/linux-generic/include/_ishmpool_internal.h
>
> diff --git a/platform/linux-generic/Makefile.am
> b/platform/linux-generic/Makefile.am
> index 999a7f5..d153c5d 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -127,6 +127,7 @@ noinst_HEADERS = \
>   ${srcdir}/include/_fdserver_internal.h \
>   ${srcdir}/include/_ishm_internal.h \
>   ${srcdir}/include/_ishmphy_internal.h \
> + ${srcdir}/include/_ishmpool_internal.h \
>   ${srcdir}/include/odp_align_internal.h \
>   ${srcdir}/include/odp_atomic_internal.h \
>   ${srcdir}/include/odp_buffer_inlines.h \
> @@ -171,6 +172,7 @@ __LIB__libodp_linux_la_SOURCES = \
>_fdserver.c \
>_ishm.c \
>_ishmphy.c \
> +  _ishmpool.c \
>odp_atomic.c \
>odp_barrier.c \
>odp_buffer.c \
> diff --git a/platform/linux-generic/_ishm.c b/platform/linux-generic/_ishm
> .c
> index 6d5b752..0befdba 100644
> --- a/platform/linux-generic/_ishm.c
> +++ b/platform/linux-generic/_ishm.c
> @@ -59,6 +59,7 @@
>  #include <_fdserver_internal.h>
>  #include <_ishm_internal.h>
>  #include <_ishmphy_internal.h>
> +#include <_ishmpool_internal.h>
>  #include 
>  #include 
>  #include 
> @@ -1441,8 +1442,19 @@ int _odp_ishm_init_global(void)
>  * is performed for the main thread... Many init_global() functions
>  * indeed assume the availability of odp_shm_reserve()...:
>  */
> -   return do_odp_ishm_init_local();
> +   if (do_odp_ishm_init_local()) {
> +   ODP_ERR("unable to init the main thread\n.");
> +   goto init_glob_err4;
> +   }
> +
> +   /* get ready to create pools: */
> +   _odp_ishm_pool_init();
>
> +   return 0;
> +
> +init_glob_err4:
> +   if (_odp_ishmphy_unbook_va())
> +   ODP_ERR("unable to unbook virtual space\n.");
>  init_glob_err3:
> if (munmap(ishm_ftbl, sizeof(ishm_ftable_t)) < 0)
> ODP_ERR("unable to munmap main fragment table\n.");
> diff --git a/platform/linux-generic/_ishmpool.c
> b/platform/linux-generic/_ishmpool.c
> new file mode 100644
> index 000..df6e49e
> --- /dev/null
> +++ b/platform/linux-generic/_ishmpool.c
> @@ -0,0 +1,811 @@
> +/* Copyright (c) 2017, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/* This file gathers the buddy and slab allocation functionality provided
> + * by _ishm.
> + * _odp_ishmpool_create() can be used to create a pool for buddy/slab
> + * allocation. _odp_ishmpool_create() will allocate a memory area using
> + * ishm_reserve() for both the control part (needed for tracking
> + * allocation/free...) and the user memory itself (part of which will

Re: [lng-odp] [API-NEXT PATCHv3] linux-generic: crypto: add openssl locking support for thread safety

2017-01-11 Thread Christophe Milard

Hi Bill,

On 11 January 2017 at 13:25, Bill Fischofer  wrote:
> On Wed, Jan 11, 2017 at 3:35 AM, Christophe Milard
>  wrote:
>> On 2017-01-09 09:24, Bill Fischofer wrote:
>>> Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2798 by adding
>>> OpenSSL callbacks for locking that use ticketlocks to provide
>>> thread-safety for OpenSSL calls made by ODP components such as random
>>> number generation.
>>>
>>> Signed-off-by: Bill Fischofer 
>>> ---
>>
>> I remember someone asking why this was sent agains API-next rather than
>> master,... I cannot remember any reason why...
>> Should this be a master patch?
>>
>
> It's against api-next because the code that exposes the issue (the
> random changes) and your shm tests are in api-next. I figured it's
> easier to test there and then merge into master since we don't have a
> way to verify the bug fix in master directly.

ok. I am fine with that.

>
>>> Changes for v3:
>>> - Move code from odp_init.c to odp_crypto.c as suggested by Petri
>>>   and Christophe
>>>
>>> Changes for v2:
>>> - OPENSSL_INIT stage should precede CRYPTO_INIT stage since crypto uses 
>>> OpenSSL
>>>
>>>  platform/linux-generic/odp_crypto.c | 35 
>>> +++
>>>  1 file changed, 35 insertions(+)
>>>
>>> diff --git a/platform/linux-generic/odp_crypto.c 
>>> b/platform/linux-generic/odp_crypto.c
>>> index 5808d16..4f17fd6 100644
>>> --- a/platform/linux-generic/odp_crypto.c
>>> +++ b/platform/linux-generic/odp_crypto.c
>>> @@ -64,6 +64,7 @@ typedef struct odp_crypto_global_s odp_crypto_global_t;
>>>
>>>  struct odp_crypto_global_s {
>>>   odp_spinlock_tlock;
>>> + odp_ticketlock_t **openssl_lock;
>>>   odp_crypto_generic_session_t *free;
>>>   odp_crypto_generic_session_t  sessions[0];
>>>  };
>>> @@ -948,16 +949,35 @@ odp_crypto_operation(odp_crypto_op_param_t *param,
>>>   return 0;
>>>  }
>>>
>>> +static unsigned long openssl_thread_id(void)
>>> +{
>>> + return (unsigned long)odp_thread_id();
>>> +}
>>
>> Question here (and sorry, I should have picked that in my first review):
>> 1) The man page I found for CRYPTO_set_id_callback() has a different
>> prototype:
>> int CRYPTO_THREADID_set_callback(void (*threadid_func)(CRYPTO_THREADID *));
>>  for the callback function and says:
>> "The implementation of this callback should not fill in id directly,
>> but should use CRYPTO_THREADID_set_numeric() if thread IDs are numeric"
>> It seems your  callback function can return directely the thread_id...
>
> Yes, the documentation is not the best on these. I found a few
> examples on the net and also examined the OpenSSL source code. This
> code seems to work and since this is temporary for older versions of
> OpenSSL seems simplest.
>
>>
>> 2)odp_thread_id() will return different "thread_id" for different linux
>> processes (when ODP threads are linux processes). Not sure how open-ssl will
>> react to that (e.g. a single threaded linux process using open-ssl may
>> return thread-id x, where x can be any value, 0, or more).
>
> All OpenSSL requires is a unique thread id and that's what
> odp_thread_id() provides.
>
>> Probably it is safe as the address or errno (see below) will probably exibit
>> a similar behaviour...
>> The man page I found also state:
>> " If the application does not register such a callback using
>> CRYPTO_THREADID_set_callback(), then a default implementation is used - on
>> Windows and BeOS this uses the system's default thread identifying APIs,
>> and on all other platforms it uses the address of errno. The latter is
>> satisfactory for thread-safety if and only if the platform has a thread-local
>> error number facility."
>
> Not applicable as we're supplying a unique thread id.

Confused here: "Not applicable as we're supplying a unique thread
id.". But may understanding is that if we do not supply the unique
thread ID, openssl will do it by istelf, using 
What is wrong with that?

>
>> Do we have any linux version where errno is not thread local?
>> If not, considering both point 1) (different prototypes with different 
>> version)
>> and 2) (unclear behaviour on thread_id),
>> isn't is safer and clearer to skip the above function and its
>> callback registration, and let the default behaviour be used?
>>
>> I honestely think what you wrote would work, but if the default does the job
>> with less code, shoudn't we just go for it?
>
> No, again this is a temporary fix for a bug that has already been
> fixed in OpenSSL 1.1.0 and above since the library itself is thread
> safe. All of these APIs are already deprecated (they are no-ops in
> OpenSSL 1.1.0) so these considerations don't apply. We're just
> ensuring that ODP behaves in a thread-safe manner in the OpenSSL 1.0.2
> series which is still distributed in Ubuntu (and perhaps other
> distros). These were the original APIs and work across the widest
> range of older

Re: [lng-odp] [API-NEXT PATCH 1/4] validation: crypto: fix hw cipher/auth algorithm check

2017-01-11 Thread Krishna Garapati

for this series,

Reviewed-by: Balakrishna Garapati 

/Krishna

On 10 January 2017 at 13:09, Matias Elo  wrote:

> Some algorithms may be implemented using hardware and some using software.
> All supported algorithms should be set in capacity.auths /capacity.ciphers
> independent of implementation types.
>
> Signed-off-by: Matias Elo 
> ---
>  .../validation/api/crypto/odp_crypto_test_inp.c| 69
> ++
>  1 file changed, 31 insertions(+), 38 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 de9d6e4..db58344 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
> @@ -47,7 +47,7 @@ static void alg_test(odp_crypto_op_t op,
>  uint32_t digest_len)
>  {
> odp_crypto_session_t session;
> -   odp_crypto_capability_t capability;
> +   odp_crypto_capability_t capa;
> int rc;
> odp_crypto_ses_create_err_t status;
> odp_bool_t posted;
> @@ -63,50 +63,43 @@ static void alg_test(odp_crypto_op_t op,
> int num, i;
> int found;
>
> -   rc = odp_crypto_capability();
> +   rc = odp_crypto_capability();
> CU_ASSERT(!rc);
>
> -   if (capability.hw_ciphers.all_bits) {
> -   if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
> -   !(capability.hw_ciphers.bit.trides_cbc))
> -   rc = -1;
> -   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
> -   !(capability.hw_ciphers.bit.aes_cbc))
> -   rc = -1;
> -   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_AES_CBC &&
> -   !(capability.ciphers.bit.aes_cbc))
> -   rc = -1;
> -   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
> -   !(capability.ciphers.bit.aes_gcm))
> -   rc = -1;
> -   }
> +   if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
> +   !(capa.ciphers.bit.trides_cbc))
> +   rc = -1;
> +   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
> +   !(capa.ciphers.bit.aes_cbc))
> +   rc = -1;
> +   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
> +   !(capa.ciphers.bit.aes_gcm))
> +   rc = -1;
> +   if (cipher_alg == ODP_CIPHER_ALG_DES &&
> +   !(capa.ciphers.bit.des))
> +   rc = -1;
> +   if (cipher_alg == ODP_CIPHER_ALG_NULL &&
> +   !(capa.ciphers.bit.null))
> +   rc = -1;
>
> CU_ASSERT(!rc);
> +   CU_ASSERT((~capa.ciphers.all_bits & capa.hw_ciphers.all_bits) ==
> 0);
>
> -   if (capability.hw_auths.all_bits) {
> -   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_AES_GCM &&
> -   !(capability.auths.bit.aes_gcm))
> -   rc = -1;
> -   if (auth_alg == ODP_AUTH_ALG_NULL &&
> -   !(capability.auths.bit.null))
> -   rc = -1;
> -   }
> +   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
> +   !(capa.auths.bit.aes_gcm))
> +   rc = -1;
> +   if (auth_alg == ODP_AUTH_ALG_MD5_HMAC &&
> +   !(capa.auths.bit.md5_hmac))
> +   rc = -1;
> +   if (auth_alg == ODP_AUTH_ALG_NULL &&
> +   !(capa.auths.bit.null))
> +   rc = -1;
> +   if (auth_alg == ODP_AUTH_ALG_SHA256_HMAC &&
> +   !(capa.auths.bit.sha256_hmac))
> +   rc = -1;
>
> CU_ASSERT(!rc);
> +   CU_ASSERT((~capa.auths.all_bits & capa.hw_auths.all_bits) == 0);
>
> num = odp_crypto_cipher_capability(cipher_alg, cipher_capa,
>MAX_ALG_CAPA);
> --
> 2.7.4
>
>

Re: [lng-odp] [API-NEXT PATCHv3 3/4] linux-gen: add generic bitmaps and iterators

2017-01-11 Thread Yi He

Yes, ARRAY_SIZE is a kernel macro, I looked into the checkpatch.pl and see
no flag to enable/disable this check, shall we comment it out or remove
that piece of code?

Best Regards, Yi

On 12 January 2017 at 07:40, Bill Fischofer 
wrote:

> On Wed, Jan 11, 2017 at 1:50 AM, Yi He  wrote:
> > Add C++ template alike bitmap to allow
> > instantiate bitmap data structure of any size,
> > and provide iterators to help walking through
> > the bitmap objects.
> >
> > Signed-off-by: Yi He 
> > ---
> >  platform/linux-generic/Makefile.am |   2 +
> >  .../linux-generic/include/odp_bitmap_internal.h| 317
> +
> >  platform/linux-generic/odp_bitmap.c| 315
> 
> >  3 files changed, 634 insertions(+)
> >  create mode 100644 platform/linux-generic/include/odp_bitmap_internal.h
> >  create mode 100644 platform/linux-generic/odp_bitmap.c
> >
> > diff --git a/platform/linux-generic/Makefile.am
> b/platform/linux-generic/Makefile.am
> > index 999a7f5..5b38c7b 100644
> > --- a/platform/linux-generic/Makefile.am
> > +++ b/platform/linux-generic/Makefile.am
> > @@ -130,6 +130,7 @@ noinst_HEADERS = \
> >   ${srcdir}/include/odp_align_internal.h \
> >   ${srcdir}/include/odp_atomic_internal.h \
> >   ${srcdir}/include/odp_buffer_inlines.h \
> > + ${srcdir}/include/odp_bitmap_internal.h \
> >   ${srcdir}/include/odp_buffer_internal.h \
> >   ${srcdir}/include/odp_classification_datamodel.h \
> >   ${srcdir}/include/odp_classification_inlines.h \
> > @@ -173,6 +174,7 @@ __LIB__libodp_linux_la_SOURCES = \
> >_ishmphy.c \
> >odp_atomic.c \
> >odp_barrier.c \
> > +  odp_bitmap.c \
> >odp_buffer.c \
> >odp_byteorder.c \
> >odp_classification.c \
> > diff --git a/platform/linux-generic/include/odp_bitmap_internal.h
> b/platform/linux-generic/include/odp_bitmap_internal.h
> > new file mode 100644
> > index 000..1be4d02
> > --- /dev/null
> > +++ b/platform/linux-generic/include/odp_bitmap_internal.h
> > @@ -0,0 +1,317 @@
> > +/* Copyright (c) 2016, Linaro Limited
> > + * All rights reserved.
> > + *
> > + * SPDX-License-Identifier: BSD-3-Clause
> > + */
> > +
> > +/**
> > + * @file
> > + *
> > + * ODP generic bitmap types and operations.
> > + */
> > +
> > +#ifndef ODP_BITMAP_INTERNAL_H_
> > +#define ODP_BITMAP_INTERNAL_H_
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Generate unique identifier for instantiated class */
> > +#define TOKENIZE(template, line) \
> > +   template ## _ ## line ## _ ## __COUNTER__
> > +
> > +/* Array size in general */
> > +#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
>
> Checkpatch flags this with the following:
> ---
> WARNING: Prefer ARRAY_SIZE(array)
> #76: FILE: platform/linux-generic/include/odp_bitmap_internal.h:30:
> +#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
>
> total: 0 errors, 1 warnings, 0 checks, 646 lines checked
>
> NOTE: Ignored message types: BIT_MACRO COMPARISON_TO_NULL
> DEPRECATED_VARIABLE NEW_TYPEDEFS SPLIT_STRING SSCANF_TO_KSTRTO
>
> 0003-linux-gen-add-generic-bitmaps-and-iterators.patch has style
> problems, please review.
> ---
>
> I suspect that ARRAY_SIZE is a Linux internal macro, in which case our
> internal checkpatch rules may need updating.
> > +
> > +#define BITS_PER_BYTE  (8)
> > +#define BITS_PER_LONG  __WORDSIZE
> > +#define BYTES_PER_LONG (BITS_PER_LONG / BITS_PER_BYTE)
> > +
> > +#define BIT_WORD(nr)   ((nr) / BITS_PER_LONG)
> > +#define BITS_TO_LONGS(nr) BIT_WORD(nr + BITS_PER_LONG - 1)
> > +
> > +#define BITMAP_FIRST_WORD_MASK(start) \
> > +   (~0UL << ((start) & (BITS_PER_LONG - 1)))
> > +#define BITMAP_LAST_WORD_MASK(nbits)  \
> > +   (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
> > +
> > +/* WAPL bitmap base class */
> > +typedef struct {
> > +   unsigned int  nwords;
> > +   unsigned int  *pl;
> > +   unsigned long *ul;
> > +} wapl_bitmap_t;
> > +
> > +/*
> > + * Word-Aligned Position List (WAPL) bitmap, which actually
> > + * is not a compression, but with an extra list of non-empty
> > + * word positions.
> > + *
> > + * WAPL accelerates bitwise operations and iterations by
> > + * applying only to non-empty positions instead of walking
> > + * through the whole bitmap.
> > + *
> > + * WAPL uses [1 ~ N] instead of [0 ~ N - 1] as position
> > + * values and an extra 0 as end indicator for position list.
> > + * This is the reason to allocate one extra room below.
> > + */
> > +#define instantiate_wapl_bitmap(line, nbits)   \
> > +   struct

[lng-odp] [Bug 2765] Pool fixed memory overhead is excessive

2017-01-11 Thread bugzilla-daemon

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

Bill Fischofer  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Fischofer  ---
Merged. Commit ID ed3cfdeed1a99f024be2538aac31b71c8eddcf07

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

Re: [lng-odp] [API-NEXT PATCHv3 1/4] linux-gen: sched: solve ordered context inversion

2017-01-11 Thread Bill Fischofer

For this series:

Reviewed-and-tested-by: Bill Fischofer 

On Wed, Jan 11, 2017 at 1:50 AM, Yi He  wrote:
> For ordered queue, a thread consumes events (dequeue) and
> acquires its unique sequential context in two steps, non
> atomic and preemptable.
>
> This leads to potential ordered context inversion in case
> the thread consumes prior events acquired subsequent context,
> while the thread consumes subsequent events but acquired
> prior context.
>
> This patch insert the ordered context acquisition into
> event dequeue operation to make these two steps atomic.
>
> Signed-off-by: Yi He 
> ---
>  platform/linux-generic/include/odp_schedule_if.h | 3 +++
>  platform/linux-generic/odp_queue.c   | 3 +++
>  platform/linux-generic/odp_schedule.c| 7 ++-
>  platform/linux-generic/odp_schedule_sp.c | 7 ++-
>  4 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/platform/linux-generic/include/odp_schedule_if.h 
> b/platform/linux-generic/include/odp_schedule_if.h
> index 6c2b050..c0aee42 100644
> --- a/platform/linux-generic/include/odp_schedule_if.h
> +++ b/platform/linux-generic/include/odp_schedule_if.h
> @@ -12,6 +12,7 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
>  #include 
>
>  typedef void (*schedule_pktio_start_fn_t)(int pktio_index, int num_in_queue,
> @@ -33,6 +34,7 @@ typedef int (*schedule_term_local_fn_t)(void);
>  typedef void (*schedule_order_lock_fn_t)(void);
>  typedef void (*schedule_order_unlock_fn_t)(void);
>  typedef unsigned (*schedule_max_ordered_locks_fn_t)(void);
> +typedef void (*schedule_save_context_fn_t)(queue_entry_t *queue);
>
>  typedef struct schedule_fn_t {
> schedule_pktio_start_fn_t   pktio_start;
> @@ -50,6 +52,7 @@ typedef struct schedule_fn_t {
> schedule_order_lock_fn_torder_lock;
> schedule_order_unlock_fn_t  order_unlock;
> schedule_max_ordered_locks_fn_t max_ordered_locks;
> +   schedule_save_context_fn_t  save_context;
>  } schedule_fn_t;
>
>  /* Interface towards the scheduler */
> diff --git a/platform/linux-generic/odp_queue.c 
> b/platform/linux-generic/odp_queue.c
> index d9cb9f3..3b6a68b 100644
> --- a/platform/linux-generic/odp_queue.c
> +++ b/platform/linux-generic/odp_queue.c
> @@ -568,6 +568,9 @@ static inline int deq_multi(queue_entry_t *queue, 
> odp_buffer_hdr_t *buf_hdr[],
> if (hdr == NULL)
> queue->s.tail = NULL;
>
> +   if (queue->s.type == ODP_QUEUE_TYPE_SCHED)
> +   sched_fn->save_context(queue);
> +
> UNLOCK(>s.lock);
>
> return i;
> diff --git a/platform/linux-generic/odp_schedule.c 
> b/platform/linux-generic/odp_schedule.c
> index 645630a..264c58f 100644
> --- a/platform/linux-generic/odp_schedule.c
> +++ b/platform/linux-generic/odp_schedule.c
> @@ -1205,6 +1205,10 @@ static int schedule_num_grps(void)
> return NUM_SCHED_GRPS;
>  }
>
> +static void schedule_save_context(queue_entry_t *queue ODP_UNUSED)
> +{
> +}
> +
>  /* Fill in scheduler interface */
>  const schedule_fn_t schedule_default_fn = {
> .pktio_start = schedule_pktio_start,
> @@ -1221,7 +1225,8 @@ const schedule_fn_t schedule_default_fn = {
> .term_local  = schedule_term_local,
> .order_lock = order_lock,
> .order_unlock = order_unlock,
> -   .max_ordered_locks = schedule_max_ordered_locks
> +   .max_ordered_locks = schedule_max_ordered_locks,
> +   .save_context = schedule_save_context
>  };
>
>  /* Fill in scheduler API calls */
> diff --git a/platform/linux-generic/odp_schedule_sp.c 
> b/platform/linux-generic/odp_schedule_sp.c
> index 5150d28..1406312 100644
> --- a/platform/linux-generic/odp_schedule_sp.c
> +++ b/platform/linux-generic/odp_schedule_sp.c
> @@ -803,6 +803,10 @@ static void order_unlock(void)
>  {
>  }
>
> +static void save_context(queue_entry_t *queue ODP_UNUSED)
> +{
> +}
> +
>  /* Fill in scheduler interface */
>  const schedule_fn_t schedule_sp_fn = {
> .pktio_start   = pktio_start,
> @@ -819,7 +823,8 @@ const schedule_fn_t schedule_sp_fn = {
> .term_local= term_local,
> .order_lock =order_lock,
> .order_unlock =  order_unlock,
> -   .max_ordered_locks = max_ordered_locks
> +   .max_ordered_locks = max_ordered_locks,
> +   .save_context  = save_context
>  };
>
>  /* Fill in scheduler API calls */
> --
> 2.7.4
>

Re: [lng-odp] [API-NEXT PATCHv3 3/4] linux-gen: add generic bitmaps and iterators

2017-01-11 Thread Bill Fischofer

On Wed, Jan 11, 2017 at 1:50 AM, Yi He  wrote:
> Add C++ template alike bitmap to allow
> instantiate bitmap data structure of any size,
> and provide iterators to help walking through
> the bitmap objects.
>
> Signed-off-by: Yi He 
> ---
>  platform/linux-generic/Makefile.am |   2 +
>  .../linux-generic/include/odp_bitmap_internal.h| 317 
> +
>  platform/linux-generic/odp_bitmap.c| 315 
>  3 files changed, 634 insertions(+)
>  create mode 100644 platform/linux-generic/include/odp_bitmap_internal.h
>  create mode 100644 platform/linux-generic/odp_bitmap.c
>
> diff --git a/platform/linux-generic/Makefile.am 
> b/platform/linux-generic/Makefile.am
> index 999a7f5..5b38c7b 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -130,6 +130,7 @@ noinst_HEADERS = \
>   ${srcdir}/include/odp_align_internal.h \
>   ${srcdir}/include/odp_atomic_internal.h \
>   ${srcdir}/include/odp_buffer_inlines.h \
> + ${srcdir}/include/odp_bitmap_internal.h \
>   ${srcdir}/include/odp_buffer_internal.h \
>   ${srcdir}/include/odp_classification_datamodel.h \
>   ${srcdir}/include/odp_classification_inlines.h \
> @@ -173,6 +174,7 @@ __LIB__libodp_linux_la_SOURCES = \
>_ishmphy.c \
>odp_atomic.c \
>odp_barrier.c \
> +  odp_bitmap.c \
>odp_buffer.c \
>odp_byteorder.c \
>odp_classification.c \
> diff --git a/platform/linux-generic/include/odp_bitmap_internal.h 
> b/platform/linux-generic/include/odp_bitmap_internal.h
> new file mode 100644
> index 000..1be4d02
> --- /dev/null
> +++ b/platform/linux-generic/include/odp_bitmap_internal.h
> @@ -0,0 +1,317 @@
> +/* Copyright (c) 2016, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * ODP generic bitmap types and operations.
> + */
> +
> +#ifndef ODP_BITMAP_INTERNAL_H_
> +#define ODP_BITMAP_INTERNAL_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Generate unique identifier for instantiated class */
> +#define TOKENIZE(template, line) \
> +   template ## _ ## line ## _ ## __COUNTER__
> +
> +/* Array size in general */
> +#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))

Checkpatch flags this with the following:
---
WARNING: Prefer ARRAY_SIZE(array)
#76: FILE: platform/linux-generic/include/odp_bitmap_internal.h:30:
+#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))

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

NOTE: Ignored message types: BIT_MACRO COMPARISON_TO_NULL
DEPRECATED_VARIABLE NEW_TYPEDEFS SPLIT_STRING SSCANF_TO_KSTRTO

0003-linux-gen-add-generic-bitmaps-and-iterators.patch has style
problems, please review.
---

I suspect that ARRAY_SIZE is a Linux internal macro, in which case our
internal checkpatch rules may need updating.
> +
> +#define BITS_PER_BYTE  (8)
> +#define BITS_PER_LONG  __WORDSIZE
> +#define BYTES_PER_LONG (BITS_PER_LONG / BITS_PER_BYTE)
> +
> +#define BIT_WORD(nr)   ((nr) / BITS_PER_LONG)
> +#define BITS_TO_LONGS(nr) BIT_WORD(nr + BITS_PER_LONG - 1)
> +
> +#define BITMAP_FIRST_WORD_MASK(start) \
> +   (~0UL << ((start) & (BITS_PER_LONG - 1)))
> +#define BITMAP_LAST_WORD_MASK(nbits)  \
> +   (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
> +
> +/* WAPL bitmap base class */
> +typedef struct {
> +   unsigned int  nwords;
> +   unsigned int  *pl;
> +   unsigned long *ul;
> +} wapl_bitmap_t;
> +
> +/*
> + * Word-Aligned Position List (WAPL) bitmap, which actually
> + * is not a compression, but with an extra list of non-empty
> + * word positions.
> + *
> + * WAPL accelerates bitwise operations and iterations by
> + * applying only to non-empty positions instead of walking
> + * through the whole bitmap.
> + *
> + * WAPL uses [1 ~ N] instead of [0 ~ N - 1] as position
> + * values and an extra 0 as end indicator for position list.
> + * This is the reason to allocate one extra room below.
> + */
> +#define instantiate_wapl_bitmap(line, nbits)   \
> +   struct TOKENIZE(wapl_bitmap, line) {\
> +   unsigned int pl[BITS_TO_LONGS(nbits) + 1];  \
> +   unsigned long ul[BITS_TO_LONGS(nbits) + 1]; \
> +   }
> +
> +#define WAPL_BITMAP(nbits) instantiate_wapl_bitmap(__LINE__, nbits)
> +
> +/*
> + * Upcast any derived WAPL bitmap class to its base class
> + */
> +#define __wapl_upcast(base, derived)   \
> +   do {\
> +   __typeof__(derived) p

[lng-odp] ODP and Ingress Flow Control

2017-01-11 Thread Bill Fischofer

We discussed this briefly during today's ARCH call so I wanted to
raise this as a topic to explore here as well as possibly discuss as
part of the ODP Design Summit at BUD17.

Background

When packets are received via PktIO, they become odp_packet_t objects
that are stored in an associated packet pool associated either with
the PktIO or with the CoS that the packet is assigned to by the
classifier. ODP pools have a defined capacity assigned at
odp_pool_create() time. The question arises is what happens as pools
are depleted and packets continue to arrive?

Strategies
--

Historically, packets that have no place to be stored were simply
dropped at the RX interface. Such "tail dropping" is undesirable as it
results in sharp "edges" in responsiveness and is indiscriminate in
how it is applied.

There are two basic strategies for dealing with this situation,
depending on whether or not it is acceptable to drop packets at all.
Since Ethernet was designed to be a "lossy" protocol, for most
protocols some sort of drop strategy is acceptable. The most common
employed is RED [1] and its variants.

Some protocols such as FCoE [2] cannot tolerate losses, and so
Ethernet Flow Control [3] protocols were developed, the main one being
Priority Flow Control [4] that extends the Ethernet Pause frame to
enable up to 8 separate flow classes that can be paused independently.

Both of these mechanisms rely on watermarking. When a pool depletes to
its low water mark, RED-based systems begin discarding packets while
PFC-based systems issue Pause frames to halt incoming traffic classes.
Given the timing involved in ensuring lossless Ethernet, PFC requires
HW support as well as careful tuning of the watermarks to ensure that
there is sufficient buffer space left for the pause frame to be
received at the other end of the link and the link to drain once the
other end stops transmitting.

To enable hysteresis, once initiated flow control actions continue
until the pool has recovered to a high water mark, signaling that it
is safe to return to normal operation. In the case of RED, multiple
low water marks can exist, with each one triggering the next level of
aggressiveness in the algorithms until if the pool is depleted
entirely all packets are dropped. PFC uses only a single low
watermark, as a link is either paused or not paused.

ODP Support
--

ODP could offer support for drop/pause policies as capabilities at the
PktIO and pool levels. Pools could have APIs that permit watermarks to
be queried or set, and PktIOs could have drop/pause policies
configured that would be triggered by watermark notifications received
from pools they are filling for RX processing. How a pool notifies a
PktIO of watermark levels would be implementation-dependent since
these tend to be tightly integrated in most systems and these
notifications are essentially private. Appropriate statistics would
also need to be defined to accompany this support to permit
applications to report on drop/pause activity.

Request for Comments
---

It would be useful to know what capabilities exist in various HW
platforms that ODP is being implemented as well as any application
use-cases for implementing ODP support for enabling and managing these
capabilities. Please respond to this thread and we'll see whether
this is worth having further technical discussions on this topic as
part of the BUD17 design summit.

Thanks.

Bill

---
[1] https://en.wikipedia.org/wiki/Random_early_detection
[2] https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
[3] https://en.wikipedia.org/wiki/Ethernet_flow_control
[4]
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-542809.pdf

Re: [lng-odp] [API-NEXT PATCH v2 0/5] Packet header optimizations

2017-01-11 Thread Maxim Uvarov

On 01/10/17 22:42, Bill Fischofer wrote:
> For this series:
> 
> Reviewed-and-tested-by: Bill Fischofer 
> 

Merged!

> On Tue, Jan 10, 2017 at 3:19 AM, Petri Savolainen
>  wrote:
>> Packet and buffer header structure sizes are optimized. Smaller and more 
>> packed
>> structures fit better to caches and provide better performance.
>>
>> Structure sizes decreased about 20%: odp_buffer_hdr_t from 440 to 352 bytes,
>> and odp_packet_hdr_t from 592 to 488 bytes. While single core
>> odp_packet_alloc() and _alloc_multi() performance increased more than 50%.
>>

./test/linux-generic/pktio_ipc/pktio_ipc_run.sh

also shows performance improvement from 3.7M to 3.9M single core packets
per second processing.

Maxim.


>> Improved also packet validation test output in case of data compare failure
>> (which happened during development).
>>
>> v2:
>>   * use line number as label for data compare functions
>>
>> Petri Savolainen (5):
>>   linux-gen: packet: clean and pack packet header struct
>>   linux-gen: packet: optimize alloc and init
>>   linux-gen: packet: replace base_len with constant
>>   validation: packet: add line number to compare data checks
>>   validation: packet: limit number of failed asserts
>>
>>  .../linux-generic/include/odp_buffer_internal.h|  87 +++-
>>  .../linux-generic/include/odp_packet_internal.h|  34 +++--
>>  platform/linux-generic/include/odp_pool_internal.h |  21 ++-
>>  platform/linux-generic/odp_packet.c|  83 ++-
>>  platform/linux-generic/odp_pool.c  |  24 ++--
>>  platform/linux-generic/odp_queue.c |   3 -
>>  platform/linux-generic/pktio/ipc.c |   6 +-
>>  test/common_plat/validation/api/packet/packet.c| 154 
>> ++---
>>  8 files changed, 243 insertions(+), 169 deletions(-)
>>
>> --
>> 2.8.1
>>

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring allocation until pool creation

2017-01-11 Thread Maxim Uvarov

Merged,
Maxim.

On 01/11/17 16:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> Reviewed-by: Petri Savolainen 
> 
> 
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill
>> Fischofer
>> Sent: Tuesday, January 10, 2017 6:00 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring
>> allocation until pool creation
>>
>> To avoid excessive memory overhead for pools, defer the allocation of
>> the pool ring until odp_pool_create() is called. This keeps pool memory
>> overhead proportional to the number of pools actually in use rather
>> than the architected maximum number of pools.
>>
>> This patch addresses Bug https://bugs.linaro.org/show_bug.cgi?id=2765
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>> Changes for v4:
>> - Change ring name per Maxim's suggestion
>> - Add lock/unlock calls around setting pool->reserved back to 0 per Petri
>>
>> Changes for v3:
>> - Do not reference pool ring on buffer alloc/free if cache can satisfy
>> request
>>
>> Changes for v2:
>> - Reset reserved to 0 if ring allocation fails to recover properly
>>
>>  platform/linux-generic/include/odp_pool_internal.h |  3 +-
>>  platform/linux-generic/odp_pool.c  | 33
>> +-
>>  2 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_pool_internal.h
>> b/platform/linux-generic/include/odp_pool_internal.h
>> index 5d7b817..4915bda 100644
>> --- a/platform/linux-generic/include/odp_pool_internal.h
>> +++ b/platform/linux-generic/include/odp_pool_internal.h
>> @@ -69,7 +69,8 @@ typedef struct pool_t {
>>
>>  pool_cache_t local_cache[ODP_THREAD_COUNT_MAX];
>>
>> -pool_ring_t  ring;
>> +odp_shm_tring_shm;
>> +pool_ring_t *ring;
>>
>>  } pool_t;
>>
>> diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
>> generic/odp_pool.c
>> index cae2759..932efe3 100644
>> --- a/platform/linux-generic/odp_pool.c
>> +++ b/platform/linux-generic/odp_pool.c
>> @@ -143,7 +143,7 @@ static void flush_cache(pool_cache_t *cache, pool_t
>> *pool)
>>  uint32_t mask;
>>  uint32_t cache_num, i, data;
>>
>> -ring = >ring.hdr;
>> +ring = >ring->hdr;
>>  mask = pool->ring_mask;
>>  cache_num = cache->num;
>>
>> @@ -172,6 +172,7 @@ static pool_t *reserve_pool(void)
>>  {
>>  int i;
>>  pool_t *pool;
>> +char ring_name[ODP_POOL_NAME_LEN];
>>
>>  for (i = 0; i < ODP_CONFIG_POOLS; i++) {
>>  pool = pool_entry(i);
>> @@ -180,6 +181,19 @@ static pool_t *reserve_pool(void)
>>  if (pool->reserved == 0) {
>>  pool->reserved = 1;
>>  UNLOCK(>lock);
>> +sprintf(ring_name, "pool_ring_%d", i);
>> +pool->ring_shm =
>> +odp_shm_reserve(ring_name,
>> +sizeof(pool_ring_t),
>> +ODP_CACHE_LINE_SIZE, 0);
>> +if (odp_unlikely(pool->ring_shm == ODP_SHM_INVALID)) {
>> +ODP_ERR("Unable to alloc pool ring %d\n", i);
>> +LOCK(>lock);
>> +pool->reserved = 0;
>> +UNLOCK(>lock);
>> +break;
>> +}
>> +pool->ring = odp_shm_addr(pool->ring_shm);
>>  return pool;
>>  }
>>  UNLOCK(>lock);
>> @@ -214,7 +228,7 @@ static void init_buffers(pool_t *pool)
>>  int type;
>>  uint32_t seg_size;
>>
>> -ring = >ring.hdr;
>> +ring = >ring->hdr;
>>  mask = pool->ring_mask;
>>  type = pool->params.type;
>>
>> @@ -411,7 +425,7 @@ static odp_pool_t pool_create(const char *name,
>> odp_pool_param_t *params,
>>  pool->uarea_base_addr = odp_shm_addr(pool->uarea_shm);
>>  }
>>
>> -ring_init(>ring.hdr);
>> +ring_init(>ring->hdr);
>>  init_buffers(pool);
>>
>>  return pool->pool_hdl;
>> @@ -536,6 +550,8 @@ int odp_pool_destroy(odp_pool_t pool_hdl)
>>  odp_shm_free(pool->uarea_shm);
>>
>>  pool->reserved = 0;
>> +odp_shm_free(pool->ring_shm);
>> +pool->ring = NULL;
>>  UNLOCK(>lock);
>>
>>  return 0;
>> @@ -592,8 +608,6 @@ int buffer_alloc_multi(pool_t *pool, odp_buffer_t
>> buf[],
>>  pool_cache_t *cache;
>>  uint32_t cache_num, num_ch, num_deq, burst;
>>
>> -ring  = >ring.hdr;
>> -mask  = pool->ring_mask;
>>  cache = local.cache[pool->pool_idx];
>>
>>  cache_num = cache->num;
>> @@ -620,6 +634,8 @@ int buffer_alloc_multi(pool_t *pool, odp_buffer_t
>> buf[],
>>   * and not uint32_t. */
>>  uint32_t data[burst];
>>
>> +ring  = >ring->hdr;
>> +mask  = pool->ring_mask;
>>

[lng-odp] [PATCH v5 1/2] test: perf: add new ordered pktio application

2017-01-11 Thread Matias Elo

Add new test application for ordered queue functionality and performance
validation. The application sets sequence numbers to incoming packets using
ordered pktin queues and ordered context locks. After being tagged packets
are enqueued to atomic queues based on flow hash (IPv4 5-tuple). In atomic
flow processing the sequence number is validated and packet is sent to
selected output interface.

Main options:
-m: Input queue type can be changed to atomic or parallel to enable easy
performance comparison. With parallel input queues the packet order is
not maintained.
-r: Number of input queues per interface
-f: Number of atomic flow queues per interface
-e: Number of extra input processing rounds. This can be used to simulate
"fat pipe" traffic processing.

Signed-off-by: Matias Elo 
Reviewed-and-tested-by: Bill Fischofer 
---
 test/common_plat/performance/.gitignore  |1 +
 test/common_plat/performance/Makefile.am |7 +-
 test/common_plat/performance/dummy_crc.h |  493 
 test/common_plat/performance/odp_pktio_ordered.c | 1342 ++
 4 files changed, 1842 insertions(+), 1 deletion(-)
 create mode 100644 test/common_plat/performance/dummy_crc.h
 create mode 100644 test/common_plat/performance/odp_pktio_ordered.c

diff --git a/test/common_plat/performance/.gitignore 
b/test/common_plat/performance/.gitignore
index 1527d25..8bb18f5 100644
--- a/test/common_plat/performance/.gitignore
+++ b/test/common_plat/performance/.gitignore
@@ -3,6 +3,7 @@
 odp_atomic
 odp_crypto
 odp_l2fwd
+odp_pktio_ordered
 odp_pktio_perf
 odp_sched_latency
 odp_scheduling
diff --git a/test/common_plat/performance/Makefile.am 
b/test/common_plat/performance/Makefile.am
index f184609..790ddae 100644
--- a/test/common_plat/performance/Makefile.am
+++ b/test/common_plat/performance/Makefile.am
@@ -5,6 +5,7 @@ TESTS_ENVIRONMENT += TEST_DIR=${builddir}
 EXECUTABLES = odp_crypto$(EXEEXT) odp_pktio_perf$(EXEEXT)
 
 COMPILE_ONLY = odp_l2fwd$(EXEEXT) \
+  odp_pktio_ordered$(EXEEXT) \
   odp_sched_latency$(EXEEXT) \
   odp_scheduling$(EXEEXT)
 
@@ -22,15 +23,19 @@ bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
 
 odp_crypto_LDFLAGS = $(AM_LDFLAGS) -static
 odp_crypto_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/test
+odp_pktio_ordered_LDFLAGS = $(AM_LDFLAGS) -static
+odp_pktio_ordered_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/test
 odp_sched_latency_LDFLAGS = $(AM_LDFLAGS) -static
 odp_sched_latency_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/test
 odp_scheduling_LDFLAGS = $(AM_LDFLAGS) -static
 odp_scheduling_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/test
 
 noinst_HEADERS = \
- $(top_srcdir)/test/test_debug.h
+ $(top_srcdir)/test/test_debug.h \
+ dummy_crc.h
 
 dist_odp_crypto_SOURCES = odp_crypto.c
+dist_odp_pktio_ordered_SOURCES = odp_pktio_ordered.c
 dist_odp_sched_latency_SOURCES = odp_sched_latency.c
 dist_odp_scheduling_SOURCES = odp_scheduling.c
 dist_odp_pktio_perf_SOURCES = odp_pktio_perf.c
diff --git a/test/common_plat/performance/dummy_crc.h 
b/test/common_plat/performance/dummy_crc.h
new file mode 100644
index 000..38da444
--- /dev/null
+++ b/test/common_plat/performance/dummy_crc.h
@@ -0,0 +1,493 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2013 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR

[lng-odp] [PATCH v5 2/2] test: pktio_ordered: add test script

2017-01-11 Thread Matias Elo

Enable application testing using pcap pktio.

Signed-off-by: Matias Elo 
---
v5:
- Loop pcap input file LOOPS times to better test application throughput (Maxim)

 test/common_plat/performance/Makefile.am   |   1 +
 .../performance/odp_pktio_ordered_run.sh   |  42 +
 test/common_plat/performance/udp64.pcap| Bin 0 -> 7624 bytes
 3 files changed, 43 insertions(+)
 create mode 100755 test/common_plat/performance/odp_pktio_ordered_run.sh
 create mode 100644 test/common_plat/performance/udp64.pcap

diff --git a/test/common_plat/performance/Makefile.am 
b/test/common_plat/performance/Makefile.am
index 790ddae..2de07aa 100644
--- a/test/common_plat/performance/Makefile.am
+++ b/test/common_plat/performance/Makefile.am
@@ -10,6 +10,7 @@ COMPILE_ONLY = odp_l2fwd$(EXEEXT) \
   odp_scheduling$(EXEEXT)
 
 TESTSCRIPTS = odp_l2fwd_run.sh \
+ odp_pktio_ordered_run.sh \
  odp_sched_latency_run.sh \
  odp_scheduling_run.sh
 
diff --git a/test/common_plat/performance/odp_pktio_ordered_run.sh 
b/test/common_plat/performance/odp_pktio_ordered_run.sh
new file mode 100755
index 000..d91211c
--- /dev/null
+++ b/test/common_plat/performance/odp_pktio_ordered_run.sh
@@ -0,0 +1,42 @@
+#!/bin/bash
+#
+# Copyright (c) 2016, Linaro Limited
+# All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+#
+
+DURATION=5
+LOG=odp_pktio_ordered.log
+LOOPS=1
+PASS_PPS=5000
+PCAP_IN=`find . ${TEST_DIR} $(dirname $0) -name udp64.pcap -print -quit`
+PCAP_OUT=/dev/null
+
+# This just turns off output buffering so that you still get periodic
+# output while piping to tee, as long as stdbuf is available.
+if [ "$(which stdbuf)" != "" ]; then
+   STDBUF="stdbuf -o 0"
+else
+   STDBUF=
+fi
+
+$STDBUF ./odp_pktio_ordered${EXEEXT} -i pcap:in=${PCAP_IN}:loops=$LOOPS,\
+pcap:out=${PCAP_OUT} -t $DURATION | tee $LOG
+
+ret=$?
+
+if [ ! -f $LOG ]; then
+   echo "FAIL: $LOG not found"
+   ret=1
+elif [ $ret -eq 0 ]; then
+   MAX_PPS=$(awk '/TEST RESULT/ {print $3}' $LOG)
+   if [ "$MAX_PPS" -lt "$PASS_PPS" ]; then
+   echo "FAIL: pps below threshold $MAX_PPS < $PASS_PPS"
+   ret=1
+   fi
+fi
+
+rm -f $LOG
+
+exit $ret
diff --git a/test/common_plat/performance/udp64.pcap 
b/test/common_plat/performance/udp64.pcap
new file mode 100644
index 
..45f9d6e6341a331125e1e3e49ab8ad1e71b20712
GIT binary patch
literal 7624
zcmca|c+)~A1{MYw_+QV!zzF1AIDRVZQX4OW4Ui4OOdthJV3Lu8!IgnQ52VaNFl`SP
zPy-M%&2gOL#31#rG%+bTB{eNQBQq;ICpRy@ps;AvtkLiqO%tPeXtbOdEel8Mj?wyY
zv^_D}W*Ti5GK{vPNBat+eXG&_<7gilID#

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring allocation until pool creation

2017-01-11 Thread Savolainen, Petri (Nokia - FI/Espoo)

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill
> Fischofer
> Sent: Tuesday, January 10, 2017 6:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring
> allocation until pool creation
> 
> To avoid excessive memory overhead for pools, defer the allocation of
> the pool ring until odp_pool_create() is called. This keeps pool memory
> overhead proportional to the number of pools actually in use rather
> than the architected maximum number of pools.
> 
> This patch addresses Bug https://bugs.linaro.org/show_bug.cgi?id=2765
> 
> Signed-off-by: Bill Fischofer 
> ---
> Changes for v4:
> - Change ring name per Maxim's suggestion
> - Add lock/unlock calls around setting pool->reserved back to 0 per Petri
> 
> Changes for v3:
> - Do not reference pool ring on buffer alloc/free if cache can satisfy
> request
> 
> Changes for v2:
> - Reset reserved to 0 if ring allocation fails to recover properly
> 
>  platform/linux-generic/include/odp_pool_internal.h |  3 +-
>  platform/linux-generic/odp_pool.c  | 33
> +-
>  2 files changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/platform/linux-generic/include/odp_pool_internal.h
> b/platform/linux-generic/include/odp_pool_internal.h
> index 5d7b817..4915bda 100644
> --- a/platform/linux-generic/include/odp_pool_internal.h
> +++ b/platform/linux-generic/include/odp_pool_internal.h
> @@ -69,7 +69,8 @@ typedef struct pool_t {
> 
>   pool_cache_t local_cache[ODP_THREAD_COUNT_MAX];
> 
> - pool_ring_t  ring;
> + odp_shm_tring_shm;
> + pool_ring_t *ring;
> 
>  } pool_t;
> 
> diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
> generic/odp_pool.c
> index cae2759..932efe3 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -143,7 +143,7 @@ static void flush_cache(pool_cache_t *cache, pool_t
> *pool)
>   uint32_t mask;
>   uint32_t cache_num, i, data;
> 
> - ring = >ring.hdr;
> + ring = >ring->hdr;
>   mask = pool->ring_mask;
>   cache_num = cache->num;
> 
> @@ -172,6 +172,7 @@ static pool_t *reserve_pool(void)
>  {
>   int i;
>   pool_t *pool;
> + char ring_name[ODP_POOL_NAME_LEN];
> 
>   for (i = 0; i < ODP_CONFIG_POOLS; i++) {
>   pool = pool_entry(i);
> @@ -180,6 +181,19 @@ static pool_t *reserve_pool(void)
>   if (pool->reserved == 0) {
>   pool->reserved = 1;
>   UNLOCK(>lock);
> + sprintf(ring_name, "pool_ring_%d", i);
> + pool->ring_shm =
> + odp_shm_reserve(ring_name,
> + sizeof(pool_ring_t),
> + ODP_CACHE_LINE_SIZE, 0);
> + if (odp_unlikely(pool->ring_shm == ODP_SHM_INVALID)) {
> + ODP_ERR("Unable to alloc pool ring %d\n", i);
> + LOCK(>lock);
> + pool->reserved = 0;
> + UNLOCK(>lock);
> + break;
> + }
> + pool->ring = odp_shm_addr(pool->ring_shm);
>   return pool;
>   }
>   UNLOCK(>lock);
> @@ -214,7 +228,7 @@ static void init_buffers(pool_t *pool)
>   int type;
>   uint32_t seg_size;
> 
> - ring = >ring.hdr;
> + ring = >ring->hdr;
>   mask = pool->ring_mask;
>   type = pool->params.type;
> 
> @@ -411,7 +425,7 @@ static odp_pool_t pool_create(const char *name,
> odp_pool_param_t *params,
>   pool->uarea_base_addr = odp_shm_addr(pool->uarea_shm);
>   }
> 
> - ring_init(>ring.hdr);
> + ring_init(>ring->hdr);
>   init_buffers(pool);
> 
>   return pool->pool_hdl;
> @@ -536,6 +550,8 @@ int odp_pool_destroy(odp_pool_t pool_hdl)
>   odp_shm_free(pool->uarea_shm);
> 
>   pool->reserved = 0;
> + odp_shm_free(pool->ring_shm);
> + pool->ring = NULL;
>   UNLOCK(>lock);
> 
>   return 0;
> @@ -592,8 +608,6 @@ int buffer_alloc_multi(pool_t *pool, odp_buffer_t
> buf[],
>   pool_cache_t *cache;
>   uint32_t cache_num, num_ch, num_deq, burst;
> 
> - ring  = >ring.hdr;
> - mask  = pool->ring_mask;
>   cache = local.cache[pool->pool_idx];
> 
>   cache_num = cache->num;
> @@ -620,6 +634,8 @@ int buffer_alloc_multi(pool_t *pool, odp_buffer_t
> buf[],
>* and not uint32_t. */
>   uint32_t data[burst];
> 
> + ring  = >ring->hdr;
> + mask  = pool->ring_mask;
>   burst = ring_deq_multi(ring, mask, data, burst);
>   cache_num = burst - num_deq;
> 
> @@ -671,12 +687,12 @@ static

Re: [lng-odp] [PATCH] test: perf: add assert since src_idx cannot be negative

2017-01-11 Thread Bala Manoharan

Reviewed-by: Balasubramanian Manoharan 

On 22 December 2016 at 18:13, Bill Fischofer  wrote:
> Address Bug https://bugs.linaro.org/show_bug.cgi?id=2790 by adding an
> assert. odp_packet_input_index() only returns a negative value if the
> packet did not originate on an I/O interface, which is known to be false
> here.
>
> Signed-off-by: Bill Fischofer 
> ---
>  test/common_plat/performance/odp_l2fwd.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/test/common_plat/performance/odp_l2fwd.c 
> b/test/common_plat/performance/odp_l2fwd.c
> index 651ed10..1fee9ff 100644
> --- a/test/common_plat/performance/odp_l2fwd.c
> +++ b/test/common_plat/performance/odp_l2fwd.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -353,6 +354,7 @@ static int run_worker_sched_mode(void *arg)
>
> /* packets from the same queue are from the same interface */
> src_idx = odp_packet_input_index(pkt_tbl[0]);
> +   assert(src_idx >= 0);
> dst_idx = gbl_args->dst_port_from_idx[src_idx];
> fill_eth_addrs(pkt_tbl, pkts, dst_idx);
>
> --
> 2.7.4
>

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

2017-01-11 Thread Yi He

Hi, Mike and Maxim

It seems the patchwork missed the latest one, I resend and wish it can
reach the patchwork soon. Thanks for the review and test.

Best Regards

On 11 January 2017 at 21:06, Mike Holmes  wrote:

>
>
> On 11 January 2017 at 08:04, Maxim Uvarov  wrote:
>
>> On 01/11/17 16:00, Mike Holmes wrote:
>> > Hi Yi
>> >
>> > Am I missing a prerequisite patch ?
>> >
>>
>> I see in ML 4 patches.
>>
>
> You were directly mailed in the original post, I think the list did not
> get number 4
>
>
>
>>
>> > http://patches.opendataplane.org/project/lng-odp/list/
>> >
>>
>> Looks like some bug on that link.
>>
>> > Shows only three of the 4 patches, same in my mailbox
>> >
>> >
>> > On branch api-next
>> > Your branch is ahead of 'origin/api-next' by 3 commits.
>> >   (use "git push" to publish your local commits)
>> > nothing to commit, working tree clean
>> >
>> >
>> > * 13131d1 :2017-01-11 - (HEAD -> api-next) linux-gen: add generic
>> > bitmaps and iterators 
>> > * a265a1c :2017-01-11 - linux-gen: sched: add unsched_queue callback
>> 
>> > * 2d41bcd :2017-01-11 - linux-gen: sched: solve ordered context
>> > inversion 
>> > * 29b05df :2016-12-21 - (origin/api-next) linux-gen: _ishm: fixing typos
>> > 
>> >
>> >  2091  git am ~/Downloads/bundle-10-scheduler.mbox
>> >  2093  ./bootstrap
>> >  2094  ./configure --enable-schedule-iquery
>> >
>> > config.status: executing depfiles commands
>> > config.status: executing libtool commands
>> > configure: WARNING: unrecognized options: --enable-schedule-iquery
>> >
>> > Mike
>> >
>> >
>> >
>> > On 11 January 2017 at 02:50, Yi He > > > wrote:
>> >
>> > v3: fix checkpatch.pl  errors and warnings.
>> > v2: rebase to Matias' ordered queue impl, fix clang compilation.
>> >
>> > This patchset provides an alternate scheduler which can be enabled
>> > with --enable-schedule-iquery configuration option.
>> >
>> > Run l2fwd and odp_scheduling performance test programs show
>> equivalent
>> > performance with the improved default scheduler, and can benifit use
>> > cases of fewer queue count such as microservices, etc.
>> >
>> > Supported parallel, atomic and ordered queue, with pktio polling.
>> > ordered queue re-uses the algorithm in default scheduler.
>> > pktio polling re-uses the same algorithm in default scheduler.
>> >
>> > l2fwd performance: 2 x 10GE, 64B frame, Bi-directional
>> > -- DPDK pktgen --
>> > -- ODP-linux l2fwd (DPDK pktio) --
>> > 2 x E5-2650 v3 @ 2.30GHz 40 cores
>> >
>> >  "DIRECT (REFERENCE)"  PARALLEL ATOMIC
>> > core default (improved, Petri) default  iquery  default  iquery
>> > 120%   16%  16% 16%  16%
>> > 238%   27%  28% 26%  24%
>> > 437%   16%  16% 5%   5%
>> >
>> > * Multi-core scaling downgrade may be related to software DPDK
>> > pktgen receive issue
>> >
>> > Yi He (4):
>> >   linux-gen: sched: solve ordered context inversion
>> >   linux-gen: sched: add unsched_queue callback
>> >   linux-gen: add generic bitmaps and iterators
>> >   linux-gen: add interests query (iquery) scheduler
>> >
>> >  platform/linux-generic/Makefile.am |3 +
>> >  .../linux-generic/include/odp_bitmap_internal.h|  320 
>> >  platform/linux-generic/include/odp_schedule_if.h   |5 +
>> >  platform/linux-generic/m4/odp_schedule.m4  |7 +
>> >  platform/linux-generic/odp_bitmap.c|  315 
>> >  platform/linux-generic/odp_queue.c |7 +-
>> >  platform/linux-generic/odp_schedule.c  |   13 +-
>> >  platform/linux-generic/odp_schedule_if.c   |6 +
>> >  platform/linux-generic/odp_schedule_iquery.c   | 1523
>> > 
>> >  platform/linux-generic/odp_schedule_sp.c   |   13 +-
>> >  10 files changed, 2209 insertions(+), 3 deletions(-)
>> >  create mode 100644 platform/linux-generic/include
>> /odp_bitmap_internal.h
>> >  create mode 100644 platform/linux-generic/odp_bitmap.c
>> >  create mode 100644 platform/linux-generic/odp_schedule_iquery.c
>> >
>> > --
>> > 2.7.4
>> >
>> >
>> >
>> >
>> > --
>> > 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"
>
>
>

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

2017-01-11 Thread Mike Holmes

Wow, long delay it has showed up just now.

On 11 January 2017 at 08:06, Mike Holmes  wrote:

>
>
> On 11 January 2017 at 08:04, Maxim Uvarov  wrote:
>
>> On 01/11/17 16:00, Mike Holmes wrote:
>> > Hi Yi
>> >
>> > Am I missing a prerequisite patch ?
>> >
>>
>> I see in ML 4 patches.
>>
>
> You were directly mailed in the original post, I think the list did not
> get number 4
>
>
>
>>
>> > http://patches.opendataplane.org/project/lng-odp/list/
>> >
>>
>> Looks like some bug on that link.
>>
>> > Shows only three of the 4 patches, same in my mailbox
>> >
>> >
>> > On branch api-next
>> > Your branch is ahead of 'origin/api-next' by 3 commits.
>> >   (use "git push" to publish your local commits)
>> > nothing to commit, working tree clean
>> >
>> >
>> > * 13131d1 :2017-01-11 - (HEAD -> api-next) linux-gen: add generic
>> > bitmaps and iterators 
>> > * a265a1c :2017-01-11 - linux-gen: sched: add unsched_queue callback
>> 
>> > * 2d41bcd :2017-01-11 - linux-gen: sched: solve ordered context
>> > inversion 
>> > * 29b05df :2016-12-21 - (origin/api-next) linux-gen: _ishm: fixing typos
>> > 
>> >
>> >  2091  git am ~/Downloads/bundle-10-scheduler.mbox
>> >  2093  ./bootstrap
>> >  2094  ./configure --enable-schedule-iquery
>> >
>> > config.status: executing depfiles commands
>> > config.status: executing libtool commands
>> > configure: WARNING: unrecognized options: --enable-schedule-iquery
>> >
>> > Mike
>> >
>> >
>> >
>> > On 11 January 2017 at 02:50, Yi He > > > wrote:
>> >
>> > v3: fix checkpatch.pl  errors and warnings.
>> > v2: rebase to Matias' ordered queue impl, fix clang compilation.
>> >
>> > This patchset provides an alternate scheduler which can be enabled
>> > with --enable-schedule-iquery configuration option.
>> >
>> > Run l2fwd and odp_scheduling performance test programs show
>> equivalent
>> > performance with the improved default scheduler, and can benifit use
>> > cases of fewer queue count such as microservices, etc.
>> >
>> > Supported parallel, atomic and ordered queue, with pktio polling.
>> > ordered queue re-uses the algorithm in default scheduler.
>> > pktio polling re-uses the same algorithm in default scheduler.
>> >
>> > l2fwd performance: 2 x 10GE, 64B frame, Bi-directional
>> > -- DPDK pktgen --
>> > -- ODP-linux l2fwd (DPDK pktio) --
>> > 2 x E5-2650 v3 @ 2.30GHz 40 cores
>> >
>> >  "DIRECT (REFERENCE)"  PARALLEL ATOMIC
>> > core default (improved, Petri) default  iquery  default  iquery
>> > 120%   16%  16% 16%  16%
>> > 238%   27%  28% 26%  24%
>> > 437%   16%  16% 5%   5%
>> >
>> > * Multi-core scaling downgrade may be related to software DPDK
>> > pktgen receive issue
>> >
>> > Yi He (4):
>> >   linux-gen: sched: solve ordered context inversion
>> >   linux-gen: sched: add unsched_queue callback
>> >   linux-gen: add generic bitmaps and iterators
>> >   linux-gen: add interests query (iquery) scheduler
>> >
>> >  platform/linux-generic/Makefile.am |3 +
>> >  .../linux-generic/include/odp_bitmap_internal.h|  320 
>> >  platform/linux-generic/include/odp_schedule_if.h   |5 +
>> >  platform/linux-generic/m4/odp_schedule.m4  |7 +
>> >  platform/linux-generic/odp_bitmap.c|  315 
>> >  platform/linux-generic/odp_queue.c |7 +-
>> >  platform/linux-generic/odp_schedule.c  |   13 +-
>> >  platform/linux-generic/odp_schedule_if.c   |6 +
>> >  platform/linux-generic/odp_schedule_iquery.c   | 1523
>> > 
>> >  platform/linux-generic/odp_schedule_sp.c   |   13 +-
>> >  10 files changed, 2209 insertions(+), 3 deletions(-)
>> >  create mode 100644 platform/linux-generic/include
>> /odp_bitmap_internal.h
>> >  create mode 100644 platform/linux-generic/odp_bitmap.c
>> >  create mode 100644 platform/linux-generic/odp_schedule_iquery.c
>> >
>> > --
>> > 2.7.4
>> >
>> >
>> >
>> >
>> > --
>> > 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"
>
>
>


-- 
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 PATCHv3 4/4] linux-gen: add interests query (iquery) scheduler

2017-01-11 Thread Yi He

Add this interests query (iquery) scheduler as an
alternate choice of ODP-linux scheduler component
for performance optimization especially in lower
queue counts use cases.

It includes a new core algorithm, but adopted the
ring-based pktio poll algorithm from default scheduler,
and still uses the old ordered queue implementation.

Signed-off-by: Yi He 
---
 platform/linux-generic/Makefile.am   |1 +
 platform/linux-generic/m4/odp_schedule.m4|7 +
 platform/linux-generic/odp_schedule_if.c |6 +
 platform/linux-generic/odp_schedule_iquery.c | 1521 ++
 4 files changed, 1535 insertions(+)
 create mode 100644 platform/linux-generic/odp_schedule_iquery.c

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 5b38c7b..6bbe775 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -211,6 +211,7 @@ __LIB__libodp_linux_la_SOURCES = \
   odp_schedule.c \
   odp_schedule_if.c \
   odp_schedule_sp.c \
+  odp_schedule_iquery.c \
   odp_shared_memory.c \
   odp_sorted_list.c \
   odp_spinlock.c \
diff --git a/platform/linux-generic/m4/odp_schedule.m4 
b/platform/linux-generic/m4/odp_schedule.m4
index bc70c1f..2dcc9a7 100644
--- a/platform/linux-generic/m4/odp_schedule.m4
+++ b/platform/linux-generic/m4/odp_schedule.m4
@@ -4,3 +4,10 @@ AC_ARG_ENABLE([schedule-sp],
schedule-sp=yes
ODP_CFLAGS="$ODP_CFLAGS -DODP_SCHEDULE_SP"
 fi])
+
+AC_ARG_ENABLE([schedule-iquery],
+[  --enable-schedule-iqueryenable interests query (sparse bitmap) 
scheduler],
+[if test x$enableval = xyes; then
+   schedule-iquery=yes
+   ODP_CFLAGS="$ODP_CFLAGS -DODP_SCHEDULE_IQUERY"
+fi])
diff --git a/platform/linux-generic/odp_schedule_if.c 
b/platform/linux-generic/odp_schedule_if.c
index daf6c98..a9ede98 100644
--- a/platform/linux-generic/odp_schedule_if.c
+++ b/platform/linux-generic/odp_schedule_if.c
@@ -12,9 +12,15 @@ extern const schedule_api_t schedule_sp_api;
 extern const schedule_fn_t schedule_default_fn;
 extern const schedule_api_t schedule_default_api;
 
+extern const schedule_fn_t schedule_iquery_fn;
+extern const schedule_api_t schedule_iquery_api;
+
 #ifdef ODP_SCHEDULE_SP
 const schedule_fn_t *sched_fn   = _sp_fn;
 const schedule_api_t *sched_api = _sp_api;
+#elif defined(ODP_SCHEDULE_IQUERY)
+const schedule_fn_t *sched_fn   = _iquery_fn;
+const schedule_api_t *sched_api = _iquery_api;
 #else
 const schedule_fn_t  *sched_fn  = _default_fn;
 const schedule_api_t *sched_api = _default_api;
diff --git a/platform/linux-generic/odp_schedule_iquery.c 
b/platform/linux-generic/odp_schedule_iquery.c
new file mode 100644
index 000..b692457
--- /dev/null
+++ b/platform/linux-generic/odp_schedule_iquery.c
@@ -0,0 +1,1521 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Number of priority levels */
+#define NUM_SCHED_PRIO 8
+
+ODP_STATIC_ASSERT(ODP_SCHED_PRIO_LOWEST == (NUM_SCHED_PRIO - 1),
+ "lowest_prio_does_not_match_with_num_prios");
+
+ODP_STATIC_ASSERT((ODP_SCHED_PRIO_NORMAL > 0) &&
+ (ODP_SCHED_PRIO_NORMAL < (NUM_SCHED_PRIO - 1)),
+ "normal_prio_is_not_between_highest_and_lowest");
+
+/* Number of scheduling groups */
+#define NUM_SCHED_GRPS 256
+
+/* Start of named groups in group mask arrays */
+#define SCHED_GROUP_NAMED (ODP_SCHED_GROUP_CONTROL + 1)
+
+/* Instantiate a WAPL bitmap to be used as queue index bitmap */
+typedef WAPL_BITMAP(ODP_CONFIG_QUEUES) queue_index_bitmap_t;
+
+typedef struct {
+   odp_rwlock_t lock;
+   queue_index_bitmap_t queues; /* queues in this priority level */
+} sched_prio_t;
+
+typedef struct {
+   odp_rwlock_t lock;
+   bool allocated;
+   odp_thrmask_t threads; /* threads subscribe to this group */
+   queue_index_bitmap_t queues; /* queues in this group */
+   char name[ODP_SCHED_GROUP_NAME_LEN];
+} sched_group_t;
+
+/* Packet input poll command queues */
+#define PKTIO_CMD_QUEUES 4
+
+/* Maximum number of packet input queues per command */
+#define MAX_PKTIN 16
+
+/* Maximum number of packet IO interfaces */
+#define NUM_PKTIO ODP_CONFIG_PKTIO_ENTRIES
+
+/* Maximum number of pktio poll commands */
+#define NUM_PKTIO_CMD (MAX_PKTIN * NUM_PKTIO)
+
+/* Pktio command is free */
+#define PKTIO_CMD_FREE ((uint32_t)-1)
+
+/* Packet IO poll queue ring size. In worst case, all pktios
+ * have all pktins enabled and one poll command is created per
+ * pktin queue. The ring size must be larger than or equal to
+ *

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

2017-01-11 Thread Mike Holmes

On 11 January 2017 at 08:04, Maxim Uvarov  wrote:

> On 01/11/17 16:00, Mike Holmes wrote:
> > Hi Yi
> >
> > Am I missing a prerequisite patch ?
> >
>
> I see in ML 4 patches.
>

You were directly mailed in the original post, I think the list did not get
number 4



>
> > http://patches.opendataplane.org/project/lng-odp/list/
> >
>
> Looks like some bug on that link.
>
> > Shows only three of the 4 patches, same in my mailbox
> >
> >
> > On branch api-next
> > Your branch is ahead of 'origin/api-next' by 3 commits.
> >   (use "git push" to publish your local commits)
> > nothing to commit, working tree clean
> >
> >
> > * 13131d1 :2017-01-11 - (HEAD -> api-next) linux-gen: add generic
> > bitmaps and iterators 
> > * a265a1c :2017-01-11 - linux-gen: sched: add unsched_queue callback  He>
> > * 2d41bcd :2017-01-11 - linux-gen: sched: solve ordered context
> > inversion 
> > * 29b05df :2016-12-21 - (origin/api-next) linux-gen: _ishm: fixing typos
> > 
> >
> >  2091  git am ~/Downloads/bundle-10-scheduler.mbox
> >  2093  ./bootstrap
> >  2094  ./configure --enable-schedule-iquery
> >
> > config.status: executing depfiles commands
> > config.status: executing libtool commands
> > configure: WARNING: unrecognized options: --enable-schedule-iquery
> >
> > Mike
> >
> >
> >
> > On 11 January 2017 at 02:50, Yi He  > > wrote:
> >
> > v3: fix checkpatch.pl  errors and warnings.
> > v2: rebase to Matias' ordered queue impl, fix clang compilation.
> >
> > This patchset provides an alternate scheduler which can be enabled
> > with --enable-schedule-iquery configuration option.
> >
> > Run l2fwd and odp_scheduling performance test programs show
> equivalent
> > performance with the improved default scheduler, and can benifit use
> > cases of fewer queue count such as microservices, etc.
> >
> > Supported parallel, atomic and ordered queue, with pktio polling.
> > ordered queue re-uses the algorithm in default scheduler.
> > pktio polling re-uses the same algorithm in default scheduler.
> >
> > l2fwd performance: 2 x 10GE, 64B frame, Bi-directional
> > -- DPDK pktgen --
> > -- ODP-linux l2fwd (DPDK pktio) --
> > 2 x E5-2650 v3 @ 2.30GHz 40 cores
> >
> >  "DIRECT (REFERENCE)"  PARALLEL ATOMIC
> > core default (improved, Petri) default  iquery  default  iquery
> > 120%   16%  16% 16%  16%
> > 238%   27%  28% 26%  24%
> > 437%   16%  16% 5%   5%
> >
> > * Multi-core scaling downgrade may be related to software DPDK
> > pktgen receive issue
> >
> > Yi He (4):
> >   linux-gen: sched: solve ordered context inversion
> >   linux-gen: sched: add unsched_queue callback
> >   linux-gen: add generic bitmaps and iterators
> >   linux-gen: add interests query (iquery) scheduler
> >
> >  platform/linux-generic/Makefile.am |3 +
> >  .../linux-generic/include/odp_bitmap_internal.h|  320 
> >  platform/linux-generic/include/odp_schedule_if.h   |5 +
> >  platform/linux-generic/m4/odp_schedule.m4  |7 +
> >  platform/linux-generic/odp_bitmap.c|  315 
> >  platform/linux-generic/odp_queue.c |7 +-
> >  platform/linux-generic/odp_schedule.c  |   13 +-
> >  platform/linux-generic/odp_schedule_if.c   |6 +
> >  platform/linux-generic/odp_schedule_iquery.c   | 1523
> > 
> >  platform/linux-generic/odp_schedule_sp.c   |   13 +-
> >  10 files changed, 2209 insertions(+), 3 deletions(-)
> >  create mode 100644 platform/linux-generic/
> include/odp_bitmap_internal.h
> >  create mode 100644 platform/linux-generic/odp_bitmap.c
> >  create mode 100644 platform/linux-generic/odp_schedule_iquery.c
> >
> > --
> > 2.7.4
> >
> >
> >
> >
> > --
> > 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"

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

2017-01-11 Thread Maxim Uvarov

On 01/11/17 16:00, Mike Holmes wrote:
> Hi Yi 
> 
> Am I missing a prerequisite patch ?
> 

I see in ML 4 patches.

> http://patches.opendataplane.org/project/lng-odp/list/
> 

Looks like some bug on that link.

> Shows only three of the 4 patches, same in my mailbox
> 
> 
> On branch api-next
> Your branch is ahead of 'origin/api-next' by 3 commits.
>   (use "git push" to publish your local commits)
> nothing to commit, working tree clean
> 
> 
> * 13131d1 :2017-01-11 - (HEAD -> api-next) linux-gen: add generic
> bitmaps and iterators 
> * a265a1c :2017-01-11 - linux-gen: sched: add unsched_queue callback 
> * 2d41bcd :2017-01-11 - linux-gen: sched: solve ordered context
> inversion 
> * 29b05df :2016-12-21 - (origin/api-next) linux-gen: _ishm: fixing typos
> 
> 
>  2091  git am ~/Downloads/bundle-10-scheduler.mbox
>  2093  ./bootstrap 
>  2094  ./configure --enable-schedule-iquery
> 
> config.status: executing depfiles commands
> config.status: executing libtool commands
> configure: WARNING: unrecognized options: --enable-schedule-iquery
> 
> Mike
> 
> 
> 
> On 11 January 2017 at 02:50, Yi He  > wrote:
> 
> v3: fix checkpatch.pl  errors and warnings.
> v2: rebase to Matias' ordered queue impl, fix clang compilation.
> 
> This patchset provides an alternate scheduler which can be enabled
> with --enable-schedule-iquery configuration option.
> 
> Run l2fwd and odp_scheduling performance test programs show equivalent
> performance with the improved default scheduler, and can benifit use
> cases of fewer queue count such as microservices, etc.
> 
> Supported parallel, atomic and ordered queue, with pktio polling.
> ordered queue re-uses the algorithm in default scheduler.
> pktio polling re-uses the same algorithm in default scheduler.
> 
> l2fwd performance: 2 x 10GE, 64B frame, Bi-directional
> -- DPDK pktgen --
> -- ODP-linux l2fwd (DPDK pktio) --
> 2 x E5-2650 v3 @ 2.30GHz 40 cores
> 
>  "DIRECT (REFERENCE)"  PARALLEL ATOMIC
> core default (improved, Petri) default  iquery  default  iquery
> 120%   16%  16% 16%  16%
> 238%   27%  28% 26%  24%
> 437%   16%  16% 5%   5%
> 
> * Multi-core scaling downgrade may be related to software DPDK
> pktgen receive issue
> 
> Yi He (4):
>   linux-gen: sched: solve ordered context inversion
>   linux-gen: sched: add unsched_queue callback
>   linux-gen: add generic bitmaps and iterators
>   linux-gen: add interests query (iquery) scheduler
> 
>  platform/linux-generic/Makefile.am |3 +
>  .../linux-generic/include/odp_bitmap_internal.h|  320 
>  platform/linux-generic/include/odp_schedule_if.h   |5 +
>  platform/linux-generic/m4/odp_schedule.m4  |7 +
>  platform/linux-generic/odp_bitmap.c|  315 
>  platform/linux-generic/odp_queue.c |7 +-
>  platform/linux-generic/odp_schedule.c  |   13 +-
>  platform/linux-generic/odp_schedule_if.c   |6 +
>  platform/linux-generic/odp_schedule_iquery.c   | 1523
> 
>  platform/linux-generic/odp_schedule_sp.c   |   13 +-
>  10 files changed, 2209 insertions(+), 3 deletions(-)
>  create mode 100644 platform/linux-generic/include/odp_bitmap_internal.h
>  create mode 100644 platform/linux-generic/odp_bitmap.c
>  create mode 100644 platform/linux-generic/odp_schedule_iquery.c
> 
> --
> 2.7.4
> 
> 
> 
> 
> -- 
> 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 0/4] Add iquery scheduler

2017-01-11 Thread Mike Holmes

Hi Yi

Am I missing a prerequisite patch ?

http://patches.opendataplane.org/project/lng-odp/list/

Shows only three of the 4 patches, same in my mailbox


On branch api-next
Your branch is ahead of 'origin/api-next' by 3 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean


* 13131d1 :2017-01-11 - (HEAD -> api-next) linux-gen: add generic bitmaps
and iterators 
* a265a1c :2017-01-11 - linux-gen: sched: add unsched_queue callback 
* 2d41bcd :2017-01-11 - linux-gen: sched: solve ordered context inversion

* 29b05df :2016-12-21 - (origin/api-next) linux-gen: _ishm: fixing typos


 2091  git am ~/Downloads/bundle-10-scheduler.mbox
 2093  ./bootstrap
 2094  ./configure --enable-schedule-iquery

config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --enable-schedule-iquery

Mike



On 11 January 2017 at 02:50, Yi He  wrote:

> v3: fix checkpatch.pl errors and warnings.
> v2: rebase to Matias' ordered queue impl, fix clang compilation.
>
> This patchset provides an alternate scheduler which can be enabled
> with --enable-schedule-iquery configuration option.
>
> Run l2fwd and odp_scheduling performance test programs show equivalent
> performance with the improved default scheduler, and can benifit use
> cases of fewer queue count such as microservices, etc.
>
> Supported parallel, atomic and ordered queue, with pktio polling.
> ordered queue re-uses the algorithm in default scheduler.
> pktio polling re-uses the same algorithm in default scheduler.
>
> l2fwd performance: 2 x 10GE, 64B frame, Bi-directional
> -- DPDK pktgen --
> -- ODP-linux l2fwd (DPDK pktio) --
> 2 x E5-2650 v3 @ 2.30GHz 40 cores
>
>  "DIRECT (REFERENCE)"  PARALLEL ATOMIC
> core default (improved, Petri) default  iquery  default  iquery
> 120%   16%  16% 16%  16%
> 238%   27%  28% 26%  24%
> 437%   16%  16% 5%   5%
>
> * Multi-core scaling downgrade may be related to software DPDK pktgen
> receive issue
>
> Yi He (4):
>   linux-gen: sched: solve ordered context inversion
>   linux-gen: sched: add unsched_queue callback
>   linux-gen: add generic bitmaps and iterators
>   linux-gen: add interests query (iquery) scheduler
>
>  platform/linux-generic/Makefile.am |3 +
>  .../linux-generic/include/odp_bitmap_internal.h|  320 
>  platform/linux-generic/include/odp_schedule_if.h   |5 +
>  platform/linux-generic/m4/odp_schedule.m4  |7 +
>  platform/linux-generic/odp_bitmap.c|  315 
>  platform/linux-generic/odp_queue.c |7 +-
>  platform/linux-generic/odp_schedule.c  |   13 +-
>  platform/linux-generic/odp_schedule_if.c   |6 +
>  platform/linux-generic/odp_schedule_iquery.c   | 1523
> 
>  platform/linux-generic/odp_schedule_sp.c   |   13 +-
>  10 files changed, 2209 insertions(+), 3 deletions(-)
>  create mode 100644 platform/linux-generic/include/odp_bitmap_internal.h
>  create mode 100644 platform/linux-generic/odp_bitmap.c
>  create mode 100644 platform/linux-generic/odp_schedule_iquery.c
>
> --
> 2.7.4
>
>


-- 
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] Pktio Queue scheduling configuration

2017-01-11 Thread Bill Fischofer

Good question. I've added this to today's ARCH call agenda so we can
discuss.  Thanks.

On Wed, Jan 11, 2017 at 6:14 AM, Nikhil Agarwal  wrote:
> Hi,
>
> In the current ODP API ODP_PKTIN_QUEUE_CONFIG, to configure input queues to 
> Pktio, there is only one set of input queue_param in structure 
> odp_pktin_queue_param_t while num_queues can be more than 1. If I want to 
> attach different queues of a pktio to different scheduler groups, I did not 
> find an option to configure the same. This seems to be a valid configuration.
>
> Am I missing something here?
>
> Regards
> Nikhil

[lng-odp] Pktio Queue scheduling configuration

2017-01-11 Thread Nikhil Agarwal

Hi,

In the current ODP API ODP_PKTIN_QUEUE_CONFIG, to configure input queues to 
Pktio, there is only one set of input queue_param in structure 
odp_pktin_queue_param_t while num_queues can be more than 1. If I want to 
attach different queues of a pktio to different scheduler groups, I did not 
find an option to configure the same. This seems to be a valid configuration.

Am I missing something here?

Regards
Nikhil

Re: [lng-odp] [API-NEXT PATCHv3] linux-generic: crypto: add openssl locking support for thread safety

2017-01-11 Thread Christophe Milard

On 2017-01-09 09:24, Bill Fischofer wrote:
> Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2798 by adding
> OpenSSL callbacks for locking that use ticketlocks to provide
> thread-safety for OpenSSL calls made by ODP components such as random
> number generation.
> 
> Signed-off-by: Bill Fischofer 
> ---

I remember someone asking why this was sent agains API-next rather than
master,... I cannot remember any reason why...
Should this be a master patch?

> Changes for v3:
> - Move code from odp_init.c to odp_crypto.c as suggested by Petri
>   and Christophe
> 
> Changes for v2:
> - OPENSSL_INIT stage should precede CRYPTO_INIT stage since crypto uses 
> OpenSSL
> 
>  platform/linux-generic/odp_crypto.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/platform/linux-generic/odp_crypto.c 
> b/platform/linux-generic/odp_crypto.c
> index 5808d16..4f17fd6 100644
> --- a/platform/linux-generic/odp_crypto.c
> +++ b/platform/linux-generic/odp_crypto.c
> @@ -64,6 +64,7 @@ typedef struct odp_crypto_global_s odp_crypto_global_t;
>  
>  struct odp_crypto_global_s {
>   odp_spinlock_tlock;
> + odp_ticketlock_t **openssl_lock;
>   odp_crypto_generic_session_t *free;
>   odp_crypto_generic_session_t  sessions[0];
>  };
> @@ -948,16 +949,35 @@ odp_crypto_operation(odp_crypto_op_param_t *param,
>   return 0;
>  }
>  
> +static unsigned long openssl_thread_id(void)
> +{
> + return (unsigned long)odp_thread_id();
> +}

Question here (and sorry, I should have picked that in my first review):
1) The man page I found for CRYPTO_set_id_callback() has a different
prototype:
int CRYPTO_THREADID_set_callback(void (*threadid_func)(CRYPTO_THREADID *));
 for the callback function and says:
"The implementation of this callback should not fill in id directly,
but should use CRYPTO_THREADID_set_numeric() if thread IDs are numeric"
It seems your  callback function can return directely the thread_id...

2)odp_thread_id() will return different "thread_id" for different linux
processes (when ODP threads are linux processes). Not sure how open-ssl will
react to that (e.g. a single threaded linux process using open-ssl may
return thread-id x, where x can be any value, 0, or more).
Probably it is safe as the address or errno (see below) will probably exibit
a similar behaviour...
The man page I found also state:
" If the application does not register such a callback using
CRYPTO_THREADID_set_callback(), then a default implementation is used - on
Windows and BeOS this uses the system's default thread identifying APIs,
and on all other platforms it uses the address of errno. The latter is
satisfactory for thread-safety if and only if the platform has a thread-local
error number facility."
Do we have any linux version where errno is not thread local?
If not, considering both point 1) (different prototypes with different version)
and 2) (unclear behaviour on thread_id),
isn't is safer and clearer to skip the above function and its
callback registration, and let the default behaviour be used?

I honestely think what you wrote would work, but if the default does the job
with less code, shoudn't we just go for it?

I have started testing this patch anyway :-)

Christophe

> +
> +static void openssl_lock(int mode, int n,
> +  const char *file ODP_UNUSED,
> +  int line ODP_UNUSED)
> +{
> + if (mode & CRYPTO_LOCK)
> + odp_ticketlock_lock((odp_ticketlock_t *)
> + >openssl_lock[n]);
> + else
> + odp_ticketlock_unlock((odp_ticketlock_t *)
> +   >openssl_lock[n]);
> +}
> +
>  int
>  odp_crypto_init_global(void)
>  {
>   size_t mem_size;
>   odp_shm_t shm;
>   int idx;
> + int nlocks = CRYPTO_num_locks();
>  
>   /* Calculate the memory size we need */
>   mem_size  = sizeof(*global);
>   mem_size += (MAX_SESSIONS * sizeof(odp_crypto_generic_session_t));
> + mem_size += nlocks * sizeof(odp_ticketlock_t);
>  
>   /* Allocate our globally shared memory */
>   shm = odp_shm_reserve("crypto_pool", mem_size,
> @@ -975,6 +995,18 @@ odp_crypto_init_global(void)
>   }
>   odp_spinlock_init(>lock);
>  
> + if (nlocks > 0) {
> + global->openssl_lock =
> + (odp_ticketlock_t **)>sessions[MAX_SESSIONS];
> +
> + for (idx = 0; idx < nlocks; idx++)
> + odp_ticketlock_init((odp_ticketlock_t *)
> + >openssl_lock[idx]);
> +
> + CRYPTO_set_id_callback(openssl_thread_id);
> + CRYPTO_set_locking_callback(openssl_lock);
> + }
> +
>   return 0;
>  }
>  
> @@ -992,6 +1024,9 @@ int odp_crypto_term_global(void)
>   rc = -1;
>   }
>  
> + CRYPTO_set_locking_callback(NULL);
> + CRYPTO_set_id_callback(NULL);
> +
>   ret =

Re: [lng-odp] [API-NEXTv5 1/6] linux-gen: _ishm: adding buddy and slab allocation

Re: [lng-odp] [API-NEXT PATCHv3] linux-generic: crypto: add openssl locking support for thread safety

Re: [lng-odp] [API-NEXT PATCH 1/4] validation: crypto: fix hw cipher/auth algorithm check

Re: [lng-odp] [API-NEXT PATCHv3 3/4] linux-gen: add generic bitmaps and iterators

[lng-odp] [Bug 2765] Pool fixed memory overhead is excessive

Re: [lng-odp] [API-NEXT PATCHv3 1/4] linux-gen: sched: solve ordered context inversion

Re: [lng-odp] [API-NEXT PATCHv3 3/4] linux-gen: add generic bitmaps and iterators

[lng-odp] ODP and Ingress Flow Control

Re: [lng-odp] [API-NEXT PATCH v2 0/5] Packet header optimizations

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring allocation until pool creation

[lng-odp] [PATCH v5 1/2] test: perf: add new ordered pktio application

[lng-odp] [PATCH v5 2/2] test: pktio_ordered: add test script

Re: [lng-odp] [API-NEXT PATCHv4] linux-generic: pool: defer ring allocation until pool creation

Re: [lng-odp] [PATCH] test: perf: add assert since src_idx cannot be negative

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

[lng-odp] [API-NEXT PATCHv3 4/4] linux-gen: add interests query (iquery) scheduler

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

Re: [lng-odp] [API-NEXT PATCHv3 0/4] Add iquery scheduler

Re: [lng-odp] Pktio Queue scheduling configuration

[lng-odp] Pktio Queue scheduling configuration

Re: [lng-odp] [API-NEXT PATCHv3] linux-generic: crypto: add openssl locking support for thread safety

23 matches

Site Navigation

Mail list logo

Footer information