Re: [lng-odp] [API-NEXT PATCH] linux-gen: scheduler: solve ordered context inversion

Hi, The point is that it cannot be reviewed as stand alone, since reviwer does not see the reason why it's needed. Other two schedulers do not need it, since those do not call dequeue simultaneously from multiple threads for the same queue. -Petri From: Yi He [mailto:yi...@linaro.org]

Re: [lng-odp] [API-NEXT PATCH] linux-gen: scheduler: solve ordered context inversion

Hi, Petri I think this patch can stand alone for the problem it explains and solves, the two actions (dequeue events and get context sequence) are non-atomic and preemptable. This patch suggest that in queue dequeue operation, to add a sched->save_context() callback in an atomic manner. So

Re: [lng-odp] [PATCH 1/2] configure: if no ABI reset .so to 0

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Wednesday, December 07, 2016 9:43 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 1/2] configure: if no ABI reset .so to 0 > > Signed-off-by: Mike Holmes

Re: [lng-odp] [API-NEXT PATCH] linux-gen: scheduler: solve ordered context inversion

This patch belongs to the iquery scheduler patch set. Without the rest of the code, it's impossible to tell if this change is needed or correct. -Petri > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Yi He > Sent: Thursday, December 08, 2016

[lng-odp] [API-NEXT PATCH] linux-gen: scheduler: solve ordered context inversion

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

Re: [lng-odp] [PATCH] linux-generic: move tm system barrier to tm group

Reviewed-by: Balasubramanian Manoharan On 2 December 2016 at 13:41, wrote: > From: Xuelin Shi > > since tm thread is handling tm group, move the thread based > barrier to tm group. otherwise, packet cannot get into the

Re: [lng-odp] [RFC v2] example: traffic_mgmt: enhancement with multiple pktios

ping On 2 December 2016 at 16:29, wrote: > From: Xuelin Shi > > This patch made the following changes: > - try to create one tm background thread for each pktio > - receiving packets from multiple pktios other than generating packets > -

Re: [lng-odp] [PATCH] linux-generic: only enable pktout when egress kind is pktio

ping. This is a simple fix. The original code skips the support of egress_kind as ODP_TM_EGRESS_FN On 2 December 2016 at 15:42, wrote: > From: Xuelin Shi > > Signed-off-by: Xuelin Shi > --- >

[lng-odp] [Bug 2557] API random.h contains doxygen todo

https://bugs.linaro.org/show_bug.cgi?id=2557 --- Comment #5 from Bill Fischofer --- Patch v7 submitted http://patches.opendataplane.org/patch/7589/ This should be the final revision. Waiting for final review by Petri. -- You are receiving this mail because: You are

[lng-odp] [Bug 2622] scheduler test fails in api-next

https://bugs.linaro.org/show_bug.cgi?id=2622 Bill Fischofer changed: What|Removed |Added Status|IN_PROGRESS |RESOLVED

Re: [lng-odp] [PATCH] helper: remove unused variable

On Fri, Dec 2, 2016 at 9:55 AM, Mike Holmes wrote: > Signed-off-by: Mike Holmes Reviewed-by: Bill Fischofer > --- > helper/linux.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/helper/linux.c

Re: [lng-odp] [PATCH 1/2] configure: if no ABI reset .so to 0

For this series: Reviewed-by: Bill Fischofer On Wed, Dec 7, 2016 at 1:43 PM, Mike Holmes wrote: > Signed-off-by: Mike Holmes > --- > configure.ac | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configure.ac

[lng-odp] [PATCH 2/2] configure: remove duplicate info

Signed-off-by: Mike Holmes --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 543f535..1b358ac 100644 --- a/configure.ac +++ b/configure.ac @@ -344,7 +344,6 @@ AC_MSG_RESULT([ static libraries:

[lng-odp] [PATCH 1/2] configure: if no ABI reset .so to 0

Signed-off-by: Mike Holmes --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 3e89b0a..543f535 100644 --- a/configure.ac +++ b/configure.ac @@ -254,6 +254,8 @@ AC_ARG_ENABLE([abi-compat], ODP_ABI_COMPAT=0

Re: [lng-odp] [PATCH] helper: remove unused variable

ping trivial fix that cleans up RPM generation logs On 2 December 2016 at 10:55, Mike Holmes wrote: > Signed-off-by: Mike Holmes > --- > helper/linux.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/helper/linux.c b/helper/linux.c >

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

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

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

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

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

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

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

On Wed, Dec 7, 2016 at 8:21 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> >> +int32_t odp_random_repeatable_data(uint8_t *buf, uint32_t len, >> >> +odp_random_kind_t kind, uint32_t >> *seed); >> >> >> > >> > If

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

> -Original Message- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Wednesday, December 07, 2016 2:35 PM > To: Savolainen, Petri (Nokia - FI/Espoo) labs.com> > Cc: lng-odp-forward > Subject: Re: [lng-odp]

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

> >> +int32_t odp_random_repeatable_data(uint8_t *buf, uint32_t len, > >> +odp_random_kind_t kind, uint32_t > *seed); > >> > > > > If pseudo/deterministic is not a good term for this, then I think it's > better to profile it strictly for testing (all production

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

On Wed, Dec 7, 2016 at 3:32 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> > /** >> > + * Cipher algorithm capabilities >> > + */ >> > +typedef struct odp_crypto_cipher_capa_t { >> > + /** Key length in bytes */ >> > + uint32_t key_len; >>

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

On Wed, Dec 7, 2016 at 3:10 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> -Original Message- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill >> Fischofer >> Sent: Monday, December 05, 2016 11:29 PM >> To:

Re: [lng-odp] [API-NEXT PATCHv3 0/5] driver initialisation framework

Ooops Clang. forgot this one will go through this. thanks... On 7 December 2016 at 13:21, Bill Fischofer wrote: > On Wed, Dec 7, 2016 at 1:19 AM, Christophe Milard > wrote: > > > > On 7 December 2016 at 01:19, Bill Fischofer

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

I've included this topic in today's ARCH call. On Wed, Dec 7, 2016 at 6:09 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > DDF may be part of some implementations, but it's not compulsory. So, DFF > must be able utilize dev API, but dev API does not

Re: [lng-odp] [API-NEXT PATCHv3 0/5] driver initialisation framework

On Wed, Dec 7, 2016 at 1:19 AM, Christophe Milard wrote: > > On 7 December 2016 at 01:19, Bill Fischofer > wrote: >> >> After applying this series ./configure fails: >> >> ./configure >> >> checking for GCC atomic builtins... yes >>

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

DDF may be part of some implementations, but it's not compulsory. So, DFF must be able utilize dev API, but dev API does not depend on DDF. Dev API needs to provide freedom of implementation. Weather a device is behind PCI or not (or if SFP is used or not) is far beyond the API level.

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

Well, we need to formalize the scope and it looks like this is part of the Device and Driver Framework (DDF) that Christophe works on. I have asked Christophe to create a document complementing the patches it pushed so that we have a human readable reference on what the DDF does and the general

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

... sending again as plain text ... I know device trees and how ugly those can be ….  values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean… Anyway, the idea here is that • an implementation has a way to

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

I know device trees and how ugly those can be …. values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean… Anyway, the idea here is that · an implementation has a way to enumerate resources to the

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

> > /** > > + * 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

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

> > /** > > + * Cipher algorithm capabilities > > + */ > > +typedef struct odp_crypto_cipher_capa_t { > > + /** Key length in bytes */ > > + uint32_t key_len; > > + > > + /** IV length in bytes */ > > + uint32_t iv_len; > > + > > +} odp_crypto_cipher_capa_t; > > This

Re: [lng-odp] [PATCH] validation: packet: fix concat test

The goal for me is to get this into monarch_lts so I posted it on master first. If API-next should fix this, I'll post the monarch patch instead Nicolas Le 12/07/2016 à 10:21 AM, Savolainen, Petri (Nokia - FI/Espoo) a écrit : > Pool re-implementation in api-next fixes a number of validation

Re: [lng-odp] [PATCH] validation: packet: fix concat test

Pool re-implementation in api-next fixes a number of validation test bugs. This may be fixed already there, since I first implemented pools with single segment. Also concat test tried to concat a single packet into the end of itself... I suggest to postpone this until api-next is merged to

[lng-odp] [PATCH] validation: classification: increase SHM_PKT_BUF_SIZE

classification_test_pmr_term_packet_len allocs a packet with 1024 of payload + headers which is greater than the segsize used to allocate the pool and breaks on implementation without segmentation support Signed-off-by: Nicolas Morey-Chaisemartin --- Should be aplied on

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

> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill > Fischofer > Sent: Monday, December 05, 2016 11:29 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [APO-NEXT PATCHv6 1/3] api: random: add explicit > controls over random data > >

[lng-odp] [PATCH] validation: packet: fix concat test

concat test assumes that segmentation is supported. Add an extra concat_test_packet that can fit twice into seglen if segmentation is not supported. Signed-off-by: Nicolas Morey-Chaisemartin --- The patch should be applied on monarch_lts too. apart from the path change, it

Re: [lng-odp] [PATCH v2 4/6] helper: use ODP_LIB_FLAVOR to generate libodp name

The test code needs some of those (the no_barrier for examples). I'm pretty sure the hashtable will need some of those because it used a globally shared structure. Le 12/07/2016 à 09:15 AM, Maxim Uvarov a écrit : > it's ok if this places in api. But do we have such places in examples or >

Re: [lng-odp] [PATCH v2 4/6] helper: use ODP_LIB_FLAVOR to generate libodp name

it's ok if this places in api. But do we have such places in examples or helper code? On 7 December 2016 at 10:43, Nicolas Morey-Chaisemartin wrote: > I usually force somme access to be uncached. A whole barrier would work, > but the performance cost is way too big. > > > Just

[lng-odp] odp_rwlock_read_trylock

HI, While looking into the test/code, I noticed something weird in the implementation of the rwlock read trylock on monarch. int odp_rwlock_read_trylock(odp_rwlock_t *rwlock) { uint32_t zero = 0; return odp_atomic_cas_acq_u32(>cnt, , (uint32_t)1); } This mean the trylock only