There is queue level context (odp_queue_get_context() /
odp_queue_set_context()), which is (close to) flow level (depending on flow to
queue mapping).
-Petri
From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Wednesday, April 22, 2015 3:50 PM
To: Savolainen, Petri (Nokia -
-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
Taras Kondratiuk
Sent: Wednesday, April 22, 2015 2:47 PM
To: Mike Holmes
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH] validation: odp_pool: add double destroy
On 04/22/2015
On Wed, Apr 22, 2015 at 5:13 PM, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 04/22/15 15:53, Bill Fischofer wrote:
It does that, but as Taras points out there is a race condition. If one
thread does an odp_pool_destroy() and it succeeds, another thread could do
an odp_pool_create() before
On 22 April 2015 at 06:55, Taras Kondratiuk taras.kondrat...@linaro.org
wrote:
On 04/22/2015 12:39 AM, Mike Holmes wrote:
Code rules IMHO - the compiler will ensure we follow the rules.
Can we add test cases to prove the behavior across all platforms,
linux-generic being one of them, and
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
---
This triggers some warnings in checkpatch about long string and multi-line
strings.
Seeing the latest debate about split string vs 80 cols, I tried to keep the
same format.
If you want me to fix it one way opr the other, please let
On 22 April 2015 at 08:57, Savolainen, Petri (Nokia - FI/Espoo)
petri.savolai...@nokia.com wrote:
-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
Taras Kondratiuk
Sent: Wednesday, April 22, 2015 2:47 PM
To: Mike Holmes
Cc: LNG ODP
On 04/20/2015 02:04 PM, Taras Kondratiuk wrote:
On 04/17/2015 11:55 PM, Rosenboim, Leonid wrote:
Guys,
There are several versions of the Classifier API document floating in Google
docs, here is one such copy:
Hi,
One question. The operation of linking a pmr to a port is performed by pmr
creation function
by providing as src_cos the default port cos?
-Original Message-
From: Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
Sent: Wednesday, April 22, 2015 4:21 PM
To: Rosenboim, Leonid;
These proposed changes are ok. From my point of view the patch can be applied.
-Original Message-
From: Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
Sent: Wednesday, April 22, 2015 4:44 PM
To: Bulie Radu-Andrei-B37577
Cc: Rosenboim, Leonid; bala.manoha...@linaro.org;
The question of prefetching is part of the larger issue of context
management, which is something we discussed last year and then deferred. I
agree that this is key to achieving best performance, but we should address
that as a first-order design rather than trying to tack it onto some
existing
Hi,
Tracking the change where calloc was introduced in the example:
https://git.linaro.org/lng/odp.git/commit/7e924cfb0b230795e4f372cdb0d57fb2e1141732
which is linked to this bug:
https://bugs.linaro.org/show_bug.cgi?id=856
Basically for using shared memory from ODP you need to initialize ODP,
On 04/22/2015 04:39 PM, Radu-Andrei Bulie wrote:
Hi,
One question. The operation of linking a pmr to a port is performed by pmr
creation function
by providing as src_cos the default port cos?
Right.
___
lng-odp mailing list
lng-odp@lists.linaro.org
On 04/22/15 15:53, Bill Fischofer wrote:
It does that, but as Taras points out there is a race condition. If
one thread does an odp_pool_destroy() and it succeeds, another thread
could do an odp_pool_create() before the second odp_pool_destroy() and
get the same pool handle which would then
On 22 April 2015 at 10:17, Nicolas Morey-Chaisemartin nmo...@kalray.eu
wrote:
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
Reviewed-and-tested-by: Mike Holmes mike.hol...@linaro.org
---
This triggers some warnings in checkpatch about long string and multi-line
strings.
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
v2 add doxygen description
doc/api_guide_lines.dox | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/api_guide_lines.dox b/doc/api_guide_lines.dox
index 2bc63a1..0832cae 100644
--- a/doc/api_guide_lines.dox
+++
On 04/22/15 19:06, Ciprian Barbu wrote:
On Wed, Apr 22, 2015 at 5:13 PM, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 04/22/15 15:53, Bill Fischofer wrote:
It does that, but as Taras points out there is a race condition. If one
thread does an odp_pool_destroy() and it succeeds, another
We have mentioned EOs in only one place and not defined them any where in
the API doc
/**
* Set queue context
*
* Its the responsability of the interface user to make sure
* queue context allocation is done in an area reachable for
* all EOs accessing the context
*
* @param queueQueue
This is a good change. We should adopt global use of PRIu32 and PRIu64
throughout linux-generic (and odp-dpdk) for maximum portability.
On Wed, Apr 22, 2015 at 9:57 AM, Mike Holmes mike.hol...@linaro.org wrote:
On 22 April 2015 at 10:17, Nicolas Morey-Chaisemartin nmo...@kalray.eu
wrote:
On Wed, Apr 22, 2015 at 12:12 PM, Mike Holmes mike.hol...@linaro.org
wrote:
Signed-off-by: Mike Holmes mike.hol...@linaro.org
Reviewed-by: Bill Fischofer bill.fischo...@linaro.org
---
v2 add doxygen description
doc/api_guide_lines.dox | 5 +
1 file changed, 5 insertions(+)
diff
On 20 April 2015 at 21:55, Mike Holmes mike.hol...@linaro.org wrote:
If the examples are on the src path they pollute the documentation
with their own declarations.
The correct mechanism is to declare the examples to be seen in the
documentation in one location that is on the .dox path, and
It does that, but as Taras points out there is a race condition. If one
thread does an odp_pool_destroy() and it succeeds, another thread could do
an odp_pool_create() before the second odp_pool_destroy() and get the same
pool handle which would then be deleted by the second odp_pool_destroy()
From: ext Mike Holmes [mailto:mike.hol...@linaro.org]
Sent: Wednesday, April 22, 2015 4:00 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: ext Taras Kondratiuk; LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH] validation: odp_pool: add double destroy
On 22 April 2015 at 08:57, Savolainen,
On 21/04/15 22:45, Bill Fischofer wrote:
One of the reasons why I was looking to use the rte_mbuf to represent
packet data rather than packets is that ODP has a richer set of packet
manipulation primitives than does DPDK, and this set will only grow over
time. Trying to overload the rte_mbuf
On 21 April 2015 at 15:08, Ola Liljedahl ola.liljed...@linaro.org wrote:
On 21 April 2015 at 14:01, Nicolas Morey-Chaisemartin nmo...@kalray.eu
wrote:
On 04/21/2015 01:31 PM, Ola Liljedahl wrote:
On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin
nmo...@kalray.eunmo...@kalray.eu
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
---
platform/linux-generic/odp_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/platform/linux-generic/odp_pool.c
b/platform/linux-generic/odp_pool.c
index ea993bb..a3d80b5 100644
---
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
---
platform/linux-generic/odp_pool.c | 12
1 file changed, 12 insertions(+)
diff --git a/platform/linux-generic/odp_pool.c
b/platform/linux-generic/odp_pool.c
index bf49623..ea993bb 100644
---
On 22 April 2015 at 11:04, Nicolas Morey-Chaisemartin nmo...@kalray.eu
wrote:
On 04/22/2015 09:56 AM, Maxim Uvarov wrote:
I don't know if this influences the location of odp_atomic_internal.h
in the ODP source structure. Maybe the makefiles can grab files (to be
installed) from
On 04/22/2015 10:07 AM, Maxim Uvarov wrote:
On 22 April 2015 at 11:04, Nicolas Morey-Chaisemartin nmo...@kalray.eu
mailto:nmo...@kalray.eu wrote:
I guess the idea would be to move odp_atomic_internal.h to
include/odp/plat/atomic.h (or something similar) and use its function to
On 04/22/2015 09:56 AM, Maxim Uvarov wrote:
I don't know if this influences the location of odp_atomic_internal.h in
the ODP source structure. Maybe the makefiles can grab files (to be
installed) from anywhere. Maxim, Anders?
_internal.h prefixes says that file has internal
On 04/22/2015 11:39 AM, Maxim Uvarov wrote:
In that case what you need is.
That is odp API:
./include/odp/api/atomic.h
That is platfrom implementation (linux-generic):
./platform/linux-generic/include/odp/atomic.h
That is some internal functions which linux-generic platfrom does.
On 04/21/2015 10:14 PM, Mike Holmes wrote:
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
test/validation/odp_pool.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/test/validation/odp_pool.c b/test/validation/odp_pool.c
index 1a518a0..c2f9a1b 100644
---
On 04/22/15 11:09, Nicolas Morey-Chaisemartin wrote:
On 04/22/2015 10:07 AM, Maxim Uvarov wrote:
On 22 April 2015 at 11:04, Nicolas Morey-Chaisemartin
nmo...@kalray.eu wrote:
I guess the idea would be to move odp_atomic_internal.h to
include/odp/plat/atomic.h (or something
On Wed, Apr 22, 2015 at 3:01 AM, Nicolas Morey-Chaisemartin
nmo...@kalray.eu wrote:
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
Reviewed-and-tested-by: Bill Fischofer bill.fischo...@linaro.org
---
platform/linux-generic/odp_pool.c | 12
1 file changed, 12
On Wed, Apr 22, 2015 at 3:01 AM, Nicolas Morey-Chaisemartin
nmo...@kalray.eu wrote:
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
Reviewed-and-tested-by: Bill Fischofer bill.fischo...@linaro.org
---
platform/linux-generic/odp_pool.c | 2 +-
1 file changed, 1 insertion(+), 1
On 04/22/2015 12:39 AM, Mike Holmes wrote:
Code rules IMHO - the compiler will ensure we follow the rules.
Can we add test cases to prove the behavior across all platforms,
linux-generic being one of them, and thus the code is correct no matter
what is written anywhere else. Presumably the api
On 04/22/15 13:34, Nicolas Morey-Chaisemartin wrote:
On 04/22/2015 11:39 AM, Maxim Uvarov wrote:
In that case what you need is.
That is odp API:
./include/odp/api/atomic.h
That is platfrom implementation (linux-generic):
./platform/linux-generic/include/odp/atomic.h
That is some internal
Good points. I agree it's better to leave this behavior undefined.
On Wed, Apr 22, 2015 at 5:44 AM, Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
On 04/21/2015 10:14 PM, Mike Holmes wrote:
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
test/validation/odp_pool.c | 25
On 04/22/15 14:20, Maxim Uvarov wrote:
On 04/22/15 13:34, Nicolas Morey-Chaisemartin wrote:
On 04/22/2015 11:39 AM, Maxim Uvarov wrote:
In that case what you need is.
That is odp API:
./include/odp/api/atomic.h
That is platfrom implementation (linux-generic):
On 22 April 2015 at 06:44, Taras Kondratiuk taras.kondrat...@linaro.org
wrote:
On 04/21/2015 10:14 PM, Mike Holmes wrote:
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
test/validation/odp_pool.c | 25 +
1 file changed, 25 insertions(+)
diff --git
On 22 April 2015 at 07:26, Bill Fischofer bill.fischo...@linaro.org wrote:
Good points. I agree it's better to leave this behavior undefined.
If that is consensus I will send a patch for the docs to add.
Deleting an already deleted pool results in unspecified behavior.
On Wed, Apr 22,
We just need to be specific about what we're testing here. This really is
no different than attempting to free a memory area twice. Clearly an
error, but do we require an implementation to detect and report this or is
it an application responsibility?
Taras' point about race conditions in
Hi,
After thinking this again, it's cleaner for the API (and the user) if these two
user metadata fields are kept separate (as they currently are). The
user_ptr/_u64 is always present and user_data only when param.pkt.udata_size is
non-zero. Implementations have different ways to store both of
On 04/22/2015 02:29 PM, Mike Holmes wrote:
On 22 April 2015 at 07:26, Bill Fischofer bill.fischo...@linaro.org
mailto:bill.fischo...@linaro.org wrote:
Good points. I agree it's better to leave this behavior undefined.
If that is consensus I will send a patch for the docs to add.
I think we need to introduce thread mask and at the same time consider the role
of cpumask again. My initial thinking is that cpumask could stay in the API, at
least ODP API debug type calls and helpers dealing with physical CPU IDs need
it. Schedule, etc ODP APIs need thread IDs (worker thread
I’m thinking different usage for these. The context pointer
(odp_packet_userctx_ptr()) would point to some data structure in the memory,
where as odp_packet_userarea() would be used as a per packet scratchpad memory.
When implementation knows that the user stores a pointer, it can also prefetch
45 matches
Mail list logo
