Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files
ODP_BUFFER_TYPE_RAWbr + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size And odp_buffer_size says: The size returned by this rouine is the size of the application data contained within the buffer Size of application data in a RAW buffer is not statically computable so does this mean RAW buffers don't support this function or that they report their fixed size? I don't have problem either way, in fact I think it's great - I just want to understand. Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com Ethernet always wins. — Andy Bechtolsheim -Original Message- From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp- boun...@lists.linaro.org] On Behalf Of Bill Fischofer Sent: Monday, November 03, 2014 5:07 AM To: lng-odp@lists.linaro.org Subject: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files RFC version of patches for new buffer .h files. Includes all API changes from buffer design doc + extended notes. Do not merge until corresponding code changes are posted. Signed-off-by: Bill Fischofer bill.fischo...@linaro.org --- platform/linux-generic/include/api/odp_buffer.h| 532 - .../linux-generic/include/api/odp_buffer_pool.h| 242 +- 2 files changed, 740 insertions(+), 34 deletions(-) diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h index 289e0eb..9910d0e 100644 --- a/platform/linux-generic/include/api/odp_buffer.h +++ b/platform/linux-generic/include/api/odp_buffer.h @@ -8,7 +8,88 @@ /** * @file * - * ODP buffer descriptor + * @par Buffer + * A buffer is an element of a buffer pool used for storing + * information. Buffers are referenced by an abstract handle of type + * odp_buffer_t. Buffers have associated buffer types that describe + * their intended use and the type of meta data that is associated + * with them. Buffers of a specific type may be referenced for + * processing by cores or by offload engines. Buffers are also + * transmitted via queues from one processing element to another. + * + * @par Buffer Types + * An ODP buffer type is identified by the + * odp_buffer_type_e enum. It defines the semantics that are to be + * attached to the buffer and defines the type of meta data that is + * associated with it. ODP implementations MUST support the following + * buffer types:brbr + * + * - ODP_BUFFER_TYPE_RAWbr + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size. This type of + * buffer is entirely under application control and most of the buffer + * APIs defined in this document are not available. APIs for this + * type of buffer are described in this document.brbr + * + * - ODP_BUFFER_TYPE_PACKETbr + * This buffer type is suitable for receiving, + * processing, and transmitting network packet data. Included in this + * type is a rich set of primitives for manipulating buffer aggregates + * and for storing system and user meta data. APIs for this type of + * buffer are described here and in the ODP Packet Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_TIMEOUTbr + * This buffer type is suitable for + * representing timer timeout events. Does not support buffer + * aggregation but does support user meta data. APIs for this type of + * buffer are described here and in the ODP Timer Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_ANYbr + * A “universal” buffer type capable of + * storing information needed for any other buffer type. It is not + * intended to be used directly, but exists for possible + * implementation convenience. + * + * @par Meta Data + * Meta Data is additional information relating to a + * buffer that is distinct from the application data normally held in + * the buffer. Implementations MAY choose to implement meta data as + * contiguous with a buffer (e.g., in an implementation-managed prefix + * area of the buffer) or in a physically separate meta data area + * efficiently accessible by the implementation using the same + * identifier as the buffer itself. ODP applications MUST NOT make + * assumptions about the addressability relationship between a buffer + * and its associated meta data, or between meta
Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions
What NPS does in HW is that each buffer you dequeue actually stays on the queue (but is marked as consumed by the application) and you are given a tag for it. When I want to queue the buffer to the next, I give the HW the tag I got, not the buffer handle and what the HW does is only than fully dequeue the buffer from the original queue before queuing it into the new queue – but only after all preceding (older) buffers on the original queue have been fully dequeued, Free of a buffer causes a dequeue from the original queue as well. And I can also give release a buffer from the original queue (give the HW the tag back and say you don't have to wait for this buffer any longer). I hope this helps, Gilad Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.commailto:gil...@ezchip.com, Web: http://www.ezchip.comhttp://www.ezchip.com/ Ethernet always wins. — Andy Bechtolsheim From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: Sunday, November 02, 2014 5:44 PM To: Gilad Ben Yossef Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions Thanks Gilad. Can you elaborate on that a bit more? I can understand how step-by-step would be potentially easier to implement, but does it also capture the majority of expected application use cases? A good confirmation that this is the correct approach for v1.0 though. On Sun, Nov 2, 2014 at 9:26 AM, Gilad Ben Yossef gil...@ezchip.commailto:gil...@ezchip.com wrote: For what it's worth, as a SoC vendor rep. that has ordered queue in HW, Petri's definition is actually preferred for us even going forward ☺ Thanks, Gilad Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576tel:%2B972-4-959-%20ext.%20576, Fax: +972-8-681-1483tel:%2B972-8-681-1483 Mobile: +972-52-826-0388tel:%2B972-52-826-0388, US Mobile: +1-973-826-0388tel:%2B1-973-826-0388 Email: gil...@ezchip.commailto:gil...@ezchip.com, Web: http://www.ezchip.comhttp://www.ezchip.com/ Ethernet always wins. — Andy Bechtolsheim From: lng-odp-boun...@lists.linaro.orgmailto:lng-odp-boun...@lists.linaro.org [mailto:lng-odp-boun...@lists.linaro.orgmailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill Fischofer Sent: Friday, October 31, 2014 2:59 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: lng-odp@lists.linaro.orgmailto:lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions This may well be a reasonable restriction for ODP v1.0 but I believe it's something we need to put on the list for production grade improvements for 2015. Bill On Fri, Oct 31, 2014 at 7:57 AM, Savolainen, Petri (NSN - FI/Espoo) petri.savolai...@nsn.commailto:petri.savolai...@nsn.com wrote: Yes, it’s step-by-step and I think it’s the level of ordering we need for v1.0. Most SoCs can implement it, even when the HW scheduler would not have order support but only atomic/parallel. This way defined atomic scheduling can be used to implement functionality correct ordered queues, the throughput is not improved but it functions correctly. -Petri From: ext Bill Fischofer [mailto:bill.fischo...@linaro.orgmailto:bill.fischo...@linaro.org] Sent: Friday, October 31, 2014 2:48 PM To: Alexandru Badicioiu Cc: Petri Savolainen; lng-odp@lists.linaro.orgmailto:lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions I can well imagine the step-by-step order preservation to be simpler to implement (in SW) but it would also seem to limit performance since the only way to ensure end-to-end order preservation would be if each intermediate queue from ingress to egress were an ordered queue. If there is a parallel queue anywhere in the chain that would break things. The question is: Is this restriction needed and/or sufficient for ODP v1.0? On Fri, Oct 31, 2014 at 7:42 AM, Alexandru Badicioiu alexandru.badici...@linaro.orgmailto:alexandru.badici...@linaro.org wrote: + * The original enqueue order of the source queue is maintained when buffers are + * enqueued to their destination queue(s) before another schedule call Is this assuming that the order will be restored always at the next enqueue? I think there should be an option to explicitly indicate if the next enqueue is supposed to restore the order or not, especially when packets move from queue to queue. Ordered queues are costly compared with the ordinary ones. Alex On 31 October 2014 14:25, Petri Savolainen petri.savolai...@linaro.orgmailto:petri.savolai...@linaro.org wrote: Improved atomic and ordered synchronisation definitions. Added order skip function prototype. Signed-off-by: Petri Savolainen
Re: [lng-odp] [PATCH v2] add tests for queue
Hi Maxim,
Thanks for you advice.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
like this ?
cunit queue test to test_odp_queue_base for none syn queue. --
this comments should be the same as the previouse patch ?
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
Fix spelling problem. Add term_local and term_global. Move
--add comments here when i have any changes from previouse patch ?
cunit queue test to test_odp_queue_base for none syn queue.
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
yan.songm...@linaro.org
From: Maxim Uvarov
Date: 2014-11-01 18:15
To: lng-odp
Subject: Re: [lng-odp] [PATCH v2] add tests for queue
Hello Yan,
few notes about sending patches.
1. pelase use 'git send-email' command.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
In that case when I do git am that lines will be skipped.
3. git commits usually look like:
short subject
empty line
long description
sign-off.
Thanks,
Maxim.
On 11/01/2014 04:44 AM, yan.songm...@linaro.org wrote:
Fix spelling problem. Add term_local and term_global. Move
cunit queue test to test_odp_queue_base for none syn queue.
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c
b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message
pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base,
MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue,
ODP_QUEUE_TYPE_POLL, param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL,
odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+
Re: [lng-odp] [PATCH v2] add tests for queue
Yan, for discussing patches, it is better to set your mail client to plain
text only mode.
On 3 November 2014 17:15, yan.songm...@linaro.org yan.songm...@linaro.org
wrote:
Hi Maxim,
Thanks for you advice.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
like this ?
* cunit queue test to test_odp_queue_base for none syn queue.
-- this **comments **should be the same as the **previouse patch** ?*
It is up to you, you can describe what you want.
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
*Fix spelling problem. Add term_local and term_global. Move
--add comments here when i have any * *changes from previouse patch ?*
* cunit queue test to test_odp_queue_base for none syn queue.*
Another --- is needed here I think.
Then anything between these two --- won't be merged into git tree.
(hope I remember correct, I used cover letter for history description)
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
--
yan.songm...@linaro.org
*From:* Maxim Uvarov maxim.uva...@linaro.org
*Date:* 2014-11-01 18:15
*To:* lng-odp lng-odp@lists.linaro.org
*Subject:* Re: [lng-odp] [PATCH v2] add tests for queue
Hello Yan,
few notes about sending patches.
1. pelase use 'git send-email' command.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
In that case when I do git am that lines will be skipped.
3. git commits usually look like:
short subject
empty line
long description
sign-off.
Thanks,
Maxim.
On 11/01/2014 04:44 AM, yan.songm...@linaro.org wrote:
Fix spelling problem. Add term_local and term_global. Move
cunit queue test to test_odp_queue_base for none syn queue.
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c
b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message
pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE,
0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base,
MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+
Re: [lng-odp] [PATCH v2] add tests for queue
Yan,
Search this patch in you mail for example:
[PATCH] Scheduler atomic and ordered definitions
On 3 November 2014 17:15, yan.songm...@linaro.org yan.songm...@linaro.org
wrote:
Hi Maxim,
Thanks for you advice.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
like this ?
* cunit queue test to test_odp_queue_base for none syn queue.
-- this **comments **should be the same as the **previouse patch** ?*
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
*Fix spelling problem. Add term_local and term_global. Move
--add comments here when i have any * *changes from previouse patch ?*
* cunit queue test to test_odp_queue_base for none syn queue.*
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
--
yan.songm...@linaro.org
*From:* Maxim Uvarov maxim.uva...@linaro.org
*Date:* 2014-11-01 18:15
*To:* lng-odp lng-odp@lists.linaro.org
*Subject:* Re: [lng-odp] [PATCH v2] add tests for queue
Hello Yan,
few notes about sending patches.
1. pelase use 'git send-email' command.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
In that case when I do git am that lines will be skipped.
3. git commits usually look like:
short subject
empty line
long description
sign-off.
Thanks,
Maxim.
On 11/01/2014 04:44 AM, yan.songm...@linaro.org wrote:
Fix spelling problem. Add term_local and term_global. Move
cunit queue test to test_odp_queue_base for none syn queue.
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c
b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message
pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE,
0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base,
MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
[lng-odp] [RFC] Addition to odp_init interface
Hi, I'd like to suggest the following addition to odp_init.h: diff --git a/platform/linux-generic/include/api/odp_init.h b/platform/linux-generic/include/api/odp_init.h index 8e018cbdba..9b75609fc7 100644 --- a/platform/linux-generic/include/api/odp_init.h +++ b/platform/linux-generic/include/api/odp_init.h @@ -108,6 +108,15 @@ int odp_term_global(void); */ int odp_init_local(void); +/** + * Register a function to be called upon thread local initialization + * + * XXX: Should the 'init_local_fn' be invoked for currently existing threads? + * Probably yes. + * (Alternative: user must call 'odp_init_local_register' before the + * first 'odp_init_local' call) + */ +int odp_init_local_register(int (*init_local_fn)(void)); Motivation is to allow a custom library built on top of ODP to initialize its per-thread local data structures. Comments? Shmulik ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On 11/03/2014 11:50 AM, Shmulik Ladkani wrote: Hi, I'd like to suggest the following addition to odp_init.h: diff --git a/platform/linux-generic/include/api/odp_init.h b/platform/linux-generic/include/api/odp_init.h index 8e018cbdba..9b75609fc7 100644 --- a/platform/linux-generic/include/api/odp_init.h +++ b/platform/linux-generic/include/api/odp_init.h @@ -108,6 +108,15 @@ int odp_term_global(void); */ int odp_init_local(void); +/** + * Register a function to be called upon thread local initialization + * + * XXX: Should the 'init_local_fn' be invoked for currently existing threads? + * Probably yes. + * (Alternative: user must call 'odp_init_local_register' before the + * first 'odp_init_local' call) + */ +int odp_init_local_register(int (*init_local_fn)(void)); Motivation is to allow a custom library built on top of ODP to initialize its per-thread local data structures. Could you please elaborate it? What is a usecase? ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On Mon, 3 Nov 2014 12:22:25 +0200 Shmulik Ladkani shmulik.ladk...@gmail.com wrote: An 'odp_init_local_register' interface would allow one to do so, and it's pretty harmful as it exposes none of ODP's internals. harmless is what I meant ;) ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files
The intent here is that they report their fixed size since RAW buffers are just blocks without any structure. It's not the intent for static to imply compile-time since the caller specifies the size of the buffer block being used. The reality is I don't believe we have any actual uses of ODP_BUFFER_TYPE_RAW at this point. It was added for completeness. Bill On Mon, Nov 3, 2014 at 2:54 AM, Gilad Ben Yossef gil...@ezchip.com wrote: ODP_BUFFER_TYPE_RAWbr + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size And odp_buffer_size says: The size returned by this rouine is the size of the application data contained within the buffer Size of application data in a RAW buffer is not statically computable so does this mean RAW buffers don't support this function or that they report their fixed size? I don't have problem either way, in fact I think it's great - I just want to understand. Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com Ethernet always wins. — Andy Bechtolsheim -Original Message- From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp- boun...@lists.linaro.org] On Behalf Of Bill Fischofer Sent: Monday, November 03, 2014 5:07 AM To: lng-odp@lists.linaro.org Subject: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files RFC version of patches for new buffer .h files. Includes all API changes from buffer design doc + extended notes. Do not merge until corresponding code changes are posted. Signed-off-by: Bill Fischofer bill.fischo...@linaro.org --- platform/linux-generic/include/api/odp_buffer.h| 532 - .../linux-generic/include/api/odp_buffer_pool.h| 242 +- 2 files changed, 740 insertions(+), 34 deletions(-) diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h index 289e0eb..9910d0e 100644 --- a/platform/linux-generic/include/api/odp_buffer.h +++ b/platform/linux-generic/include/api/odp_buffer.h @@ -8,7 +8,88 @@ /** * @file * - * ODP buffer descriptor + * @par Buffer + * A buffer is an element of a buffer pool used for storing + * information. Buffers are referenced by an abstract handle of type + * odp_buffer_t. Buffers have associated buffer types that describe + * their intended use and the type of meta data that is associated + * with them. Buffers of a specific type may be referenced for + * processing by cores or by offload engines. Buffers are also + * transmitted via queues from one processing element to another. + * + * @par Buffer Types + * An ODP buffer type is identified by the + * odp_buffer_type_e enum. It defines the semantics that are to be + * attached to the buffer and defines the type of meta data that is + * associated with it. ODP implementations MUST support the following + * buffer types:brbr + * + * - ODP_BUFFER_TYPE_RAWbr + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size. This type of + * buffer is entirely under application control and most of the buffer + * APIs defined in this document are not available. APIs for this + * type of buffer are described in this document.brbr + * + * - ODP_BUFFER_TYPE_PACKETbr + * This buffer type is suitable for receiving, + * processing, and transmitting network packet data. Included in this + * type is a rich set of primitives for manipulating buffer aggregates + * and for storing system and user meta data. APIs for this type of + * buffer are described here and in the ODP Packet Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_TIMEOUTbr + * This buffer type is suitable for + * representing timer timeout events. Does not support buffer + * aggregation but does support user meta data. APIs for this type of + * buffer are described here and in the ODP Timer Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_ANYbr + * A “universal” buffer type capable of + * storing information needed for any other buffer type. It is not + * intended to be used directly, but exists for possible + * implementation convenience. + * + * @par Meta Data + * Meta Data is additional information relating to a + *
Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions
OK, thanks. That certainly matches the step-by-step semantics Petri proposed. We'll have to discuss what, if anything, more we need regarding ORDERED queues post-v1.0 next year. Bill On Mon, Nov 3, 2014 at 3:03 AM, Gilad Ben Yossef gil...@ezchip.com wrote: What NPS does in HW is that each buffer you dequeue actually stays on the queue (but is marked as consumed by the application) and you are given a tag for it. When I want to queue the buffer to the next, I give the HW the tag I got, not the buffer handle and what the HW does is only than fully dequeue the buffer from the original queue before queuing it into the new queue – but only after all preceding (older) buffers on the original queue have been fully dequeued, Free of a buffer causes a dequeue from the original queue as well. And I can also give release a buffer from the original queue (give the HW the tag back and say you don't have to wait for this buffer any longer). I hope this helps, Gilad *Gilad Ben-Yossef* Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com *Ethernet always wins.* — Andy Bechtolsheim *From:* Bill Fischofer [mailto:bill.fischo...@linaro.org] *Sent:* Sunday, November 02, 2014 5:44 PM *To:* Gilad Ben Yossef *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org *Subject:* Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions Thanks Gilad. Can you elaborate on that a bit more? I can understand how step-by-step would be potentially easier to implement, but does it also capture the majority of expected application use cases? A good confirmation that this is the correct approach for v1.0 though. On Sun, Nov 2, 2014 at 9:26 AM, Gilad Ben Yossef gil...@ezchip.com wrote: For what it's worth, as a SoC vendor rep. that has ordered queue in HW, Petri's definition is actually preferred for us even going forward J Thanks, Gilad *Gilad Ben-Yossef* Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com *Ethernet always wins.* — Andy Bechtolsheim *From:* lng-odp-boun...@lists.linaro.org [mailto: lng-odp-boun...@lists.linaro.org] *On Behalf Of *Bill Fischofer *Sent:* Friday, October 31, 2014 2:59 PM *To:* Savolainen, Petri (NSN - FI/Espoo) *Cc:* lng-odp@lists.linaro.org *Subject:* Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions This may well be a reasonable restriction for ODP v1.0 but I believe it's something we need to put on the list for production grade improvements for 2015. Bill On Fri, Oct 31, 2014 at 7:57 AM, Savolainen, Petri (NSN - FI/Espoo) petri.savolai...@nsn.com wrote: Yes, it’s step-by-step and I think it’s the level of ordering we need for v1.0. Most SoCs can implement it, even when the HW scheduler would not have order support but only atomic/parallel. This way defined atomic scheduling can be used to implement functionality correct ordered queues, the throughput is not improved but it functions correctly. -Petri *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] *Sent:* Friday, October 31, 2014 2:48 PM *To:* Alexandru Badicioiu *Cc:* Petri Savolainen; lng-odp@lists.linaro.org *Subject:* Re: [lng-odp] [PATCH] Scheduler atomic and ordered definitions I can well imagine the step-by-step order preservation to be simpler to implement (in SW) but it would also seem to limit performance since the only way to ensure end-to-end order preservation would be if each intermediate queue from ingress to egress were an ordered queue. If there is a parallel queue anywhere in the chain that would break things. The question is: Is this restriction needed and/or sufficient for ODP v1.0? On Fri, Oct 31, 2014 at 7:42 AM, Alexandru Badicioiu alexandru.badici...@linaro.org wrote: + * The original enqueue order of the source queue is maintained when buffers are + * enqueued to their destination queue(s) before another schedule call Is this assuming that the order will be restored always at the next enqueue? I think there should be an option to explicitly indicate if the next enqueue is supposed to restore the order or not, especially when packets move from queue to queue. Ordered queues are costly compared with the ordinary ones. Alex On 31 October 2014 14:25, Petri Savolainen petri.savolai...@linaro.org wrote: Improved atomic and ordered synchronisation definitions. Added order skip function prototype. Signed-off-by: Petri Savolainen petri.savolai...@linaro.org --- This is the ordered queue
Re: [lng-odp] [RFC] Addition to odp_init interface
Make that 15:00 UTC (fingers still waking up) Bill On Mon, Nov 3, 2014 at 5:49 AM, Bill Fischofer bill.fischo...@linaro.org wrote: Hi Shmulik, This sounds like an interesting idea. Will you be able to join tomorrow's ODP call (uberconference.com/opendataplane at 15L00 UTC)? It might be interesting to discuss this idea there. Thanks. Bill On Mon, Nov 3, 2014 at 4:32 AM, Shmulik Ladkani shmulik.ladk...@gmail.com wrote: On Mon, 3 Nov 2014 12:22:25 +0200 Shmulik Ladkani shmulik.ladk...@gmail.com wrote: An 'odp_init_local_register' interface would allow one to do so, and it's pretty harmful as it exposes none of ODP's internals. harmless is what I meant ;) ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
Hi Shmulik, This sounds like an interesting idea. Will you be able to join tomorrow's ODP call (uberconference.com/opendataplane at 15L00 UTC)? It might be interesting to discuss this idea there. Thanks. Bill On Mon, Nov 3, 2014 at 4:32 AM, Shmulik Ladkani shmulik.ladk...@gmail.com wrote: On Mon, 3 Nov 2014 12:22:25 +0200 Shmulik Ladkani shmulik.ladk...@gmail.com wrote: An 'odp_init_local_register' interface would allow one to do so, and it's pretty harmful as it exposes none of ODP's internals. harmless is what I meant ;) ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] C compilation error question
I've used that sort of construct in the past and have confirmed that it
solves the problem (in addition to producing cleaner-looking code).
Thank you!
Bill
On Mon, Nov 3, 2014 at 2:45 AM, Shmulik Ladkani shmulik.ladk...@gmail.com
wrote:
Hi Bill,
On Sun, 2 Nov 2014 21:50:18 -0600 Bill Fischofer
bill.fischo...@linaro.org wrote:
I'm working on code to implement the new buffer APIs and have the
following
internal function:
static inline void *get_block(struct pool_entry_s *pool)
{
void volatile *oldhead;
void volatile *newhead;
do {
oldhead = pool-blk_freelist;
if (oldhead == NULL) break;
newhead = ((odp_buf_blk_t *)oldhead)-next;
} while (odp_cs(pool-blk_freelist,oldhead,newhead) == 0);
return (void *)oldhead;
}
However when compiling this generates the following strange error
message:
./include/odp_buffer_pool_internal.h: In function 'get_block':
./include/odp_buffer_pool_internal.h:88:14: error: cast discards
'__attribute__((noreturn))' qualifier from pointer target type
[-Werror=cast-qual]
newhead = ((odp_buf_blk_t *)oldhead)-next;
^
On gcc version 4.9.1 it gives:
warning: cast discards 'volatile' qualifier from pointer target type
[-Wcast-qual]
newhead = ((odp_buf_blk_t *)oldhead)-next;
^
The warning is indeed correct and suitable for -Wcast-qual, since
'oldhead' is a volatile pointer while it is casted to a non volatile
pointer type.
In your gcc the warning output shown is incorrect.
Using -Wcast-qual is a bit evil. It won't allow you to cast away
properties of pointers such as const or volatile without some tricks.
The easy option would be to disable -Wcast-qual.
However this might work for you:
#define VOLATILE_ACCESS_PTR(p) \
((typeof(p))(uintptr_t) *(volatile typeof(p) const *)(p))
static inline void *get_block(struct pool_entry_s *pool)
{
void *oldhead;
void *newhead;
do {
oldhead = VOLATILE_ACCESS_PTR(pool-blk_freelist);
if (oldhead == NULL) break;
newhead = ((odp_buf_blk_t *)oldhead)-next;
} while (odp_cs(pool-blk_freelist,oldhead,newhead) == 0);
return oldhead;
}
Advantage is pool-blk_freelist is accessed once (which I beleive was
your intention), and encapsulating all details of the ugly casts needed
to solve -Wcast-qual warnings into a single place.
Regards,
Shmulik
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On 11/03/2014 12:22 PM, Shmulik Ladkani wrote:
Hi Taras,
On Mon, 03 Nov 2014 12:00:33 +0200 Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
Could you please elaborate it? What is a usecase?
Think of a library extending the ODP library.
Specifically, I was playing around creating a C++ STL compatible
allocator template, whose implementation is based on ODP building
blocks.
(Well, I assume that most ODP apps would be written in C, and even if
written in C++, they'd probably use ODP memory allocation interfaces
directly for their specific needs. However such a library *could* allow
one to use STL data structures allocated by ODP means).
Such a library is unaware of how many threads its user will create, but
it needs to initialize some per-thread locals it has.
An 'odp_init_local_register' interface would allow one to do so, and
it's pretty harmful as it exposes none of ODP's internals.
The registered function may use any standard interfaces the ODP allows.
Won't it be simpler to add a new local initialization API in your
library instead of piggy-backing on ODP local init call?
Something like:
stl_odp_local_init()
{
odp_local_init();
stl_local_init(); /* Here your lib local init is done */
}
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On Mon, 3 Nov 2014 05:49:40 -0600 Bill Fischofer bill.fischo...@linaro.org wrote: This sounds like an interesting idea. Will you be able to join tomorrow's ODP call (uberconference.com/opendataplane at 15L00 UTC)? It might be interesting to discuss this idea there. Sure. I'll try to join tomorrow's call. Thanks, Shmulik ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On Mon, 03 Nov 2014 14:09:02 +0200 Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
Won't it be simpler to add a new local initialization API in your
library instead of piggy-backing on ODP local init call?
Something like:
stl_odp_local_init()
{
odp_local_init();
stl_local_init(); /* Here your lib local init is done */
}
That would be one approach, yes.
But IMO it has some disadvantages over registering a hook into
'odp_init_local':
1. Users must call 'stl_odp_local_init' upon program init (and not
odp_init_local).
2. 'odp_init_local' is currently invoked automatically from the thread
created by 'odph_linux_pthread_create()'.
(See odp_run_start_routine, which first calls 'odp_init_local' and only
then calls the user's start_routine).
Meaning, following the 'stl_odp_local_init' paradigm, I would also
need to expose a 'stl_odph_linux_pthread_create()' that properly
invokes 'stl_odp_local_init' automatically, too.
Combine these two, and let's even imagine there's more than one entity
that requires per-thread initialization - following the
'stl_odp_local_init' approach might get messy.
Regards,
Shmulik
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files
On Mon, 3 Nov 2014 05:42:52 -0600 Bill Fischofer bill.fischo...@linaro.org wrote: The reality is I don't believe we have any actual uses of ODP_BUFFER_TYPE_RAW at this point. Well... it's part of the API... don't make such assumptions ;-) (although I might just be mis-using it. I'll post a follow-up question) ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files
On 2 November 2014 22:06, Bill Fischofer bill.fischo...@linaro.org wrote: RFC version of patches for new buffer .h files. Includes all API changes from buffer design doc + extended notes. Do not merge until corresponding code changes are posted. Signed-off-by: Bill Fischofer bill.fischo...@linaro.org --- platform/linux-generic/include/api/odp_buffer.h| 532 - .../linux-generic/include/api/odp_buffer_pool.h| 242 +- 2 files changed, 740 insertions(+), 34 deletions(-) diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h index 289e0eb..9910d0e 100644 --- a/platform/linux-generic/include/api/odp_buffer.h +++ b/platform/linux-generic/include/api/odp_buffer.h @@ -8,7 +8,88 @@ /** * @file * - * ODP buffer descriptor + * @par Buffer + * A buffer is an element of a buffer pool used for storing + * information. Buffers are referenced by an abstract handle of type You have two spaces after the full stop -multiple instance + * odp_buffer_t. Buffers have associated buffer types that describe + * their intended use and the type of meta data that is associated + * with them. Buffers of a specific type may be referenced for + * processing by cores or by offload engines. Buffers are also + * transmitted via queues from one processing element to another. + * + * @par Buffer Types + * An ODP buffer type is identified by the + * odp_buffer_type_e enum. It defines the semantics that are to be + * attached to the buffer and defines the type of meta data that is + * associated with it. ODP implementations MUST support the following + * buffer types:brbr + * + * - ODP_BUFFER_TYPE_RAWbr Don't use raw HTML, use doxygen primitives, delete br multiple instances + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size. This type of + * buffer is entirely under application control and most of the buffer + * APIs defined in this document are not available. APIs for this + * type of buffer are described in this document.brbr One sentence per line as below for the paragraph above, this allow diff to clearly show future updates cleanly - multiple instances This is the “basic” buffer type which simply consists of a single fixed-sized block of contiguous memory. Buffers of this type do not support user meta data and the only built-in meta data supported for this type of buffer are those that are statically computable, such as pool and size. This type of buffer is entirely under application control and most of the buffer APIs defined in this document are not available. APIs for this type of buffer are described in this document. + * + * - ODP_BUFFER_TYPE_PACKETbr + * This buffer type is suitable for receiving, + * processing, and transmitting network packet data. Included in this + * type is a rich set of primitives for manipulating buffer aggregates + * and for storing system and user meta data. APIs for this type of + * buffer are described here and in the ODP Packet Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_TIMEOUTbr + * This buffer type is suitable for + * representing timer timeout events. Does not support buffer + * aggregation but does support user meta data. APIs for this type of + * buffer are described here and in the ODP Timer Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_ANYbr + * A “universal” buffer type capable of + * storing information needed for any other buffer type. It is not + * intended to be used directly, but exists for possible + * implementation convenience. + * + * @par Meta Data + * Meta Data is additional information relating to a + * buffer that is distinct from the application data normally held in + * the buffer. Implementations MAY choose to implement meta data as + * contiguous with a buffer (e.g., in an implementation-managed prefix + * area of the buffer) or in a physically separate meta data area + * efficiently accessible by the implementation using the same + * identifier as the buffer itself. ODP applications MUST NOT make + * assumptions about the addressability relationship between a buffer + * and its associated meta data, or between meta data items. + * Application use of meta data MUST only be via accessor functions. + * + * @par Note on OPTIONAL APIs + * Every conforming ODP implementation MUST + * provide implementations for each API described here. if an API is + * designated as OPTIONAL, this means that it is acceptable for an + * implementation to do nothing except return + * ODP_FUNCTION_NOT_AVAILABLE in response to this call. Note that this + * may limit the range of ODP applications supported
Re: [lng-odp] [PATCH v2] add tests for queue
Hongbo,
I find it . And It do help me know how to add the commends.
Thanks.
yan.songm...@linaro.org
From: Hongbo Zhang
Date: 2014-11-03 17:46
To: yan.songm...@linaro.org
CC: maxim.uvarov; lng-odp
Subject: Re: Re: [lng-odp] [PATCH v2] add tests for queue
Yan,
Search this patch in you mail for example:
[PATCH] Scheduler atomic and ordered definitions
On 3 November 2014 17:15, yan.songm...@linaro.org yan.songm...@linaro.org
wrote:
Hi Maxim,
Thanks for you advice.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
like this ?
cunit queue test to test_odp_queue_base for none syn queue. --
this comments should be the same as the previouse patch ?
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
Fix spelling problem. Add term_local and term_global. Move
--add comments here when i have any changes from previouse patch ?
cunit queue test to test_odp_queue_base for none syn queue.
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
yan.songm...@linaro.org
From: Maxim Uvarov
Date: 2014-11-01 18:15
To: lng-odp
Subject: Re: [lng-odp] [PATCH v2] add tests for queue
Hello Yan,
few notes about sending patches.
1. pelase use 'git send-email' command.
2. If you have any changes from previouse patch. Just open generated
patch and add you comments after --.
In that case when I do git am that lines will be skipped.
3. git commits usually look like:
short subject
empty line
long description
sign-off.
Thanks,
Maxim.
On 11/01/2014 04:44 AM, yan.songm...@linaro.org wrote:
Fix spelling problem. Add term_local and term_global. Move
cunit queue test to test_odp_queue_base for none syn queue.
Signed-off-by: Yan Songming yan.songm...@linaro.org
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c
b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message
pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base,
MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+
Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files
That'a a reasonable suggestion. The implementation can set errno to indicate the specific reason for failure. Bill On Mon, Nov 3, 2014 at 9:30 AM, Gilad Ben Yossef gil...@ezchip.com wrote: A question regarding all the *_addr type functions – since they may require a mapping to be put in place for some platforms, shouldn't all have some way to return an error indicating lack of resource to map - e.g. odp_buffer_addr() ? Specifically, for odp_buffer_udata(), odp_buffer_udata_addr() this means NULL may be return to indicate an error and not only that there is no user data. Gilad *Gilad Ben-Yossef* Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com *Ethernet always wins.* — Andy Bechtolsheim *From:* lng-odp-boun...@lists.linaro.org [mailto: lng-odp-boun...@lists.linaro.org] *On Behalf Of *Mike Holmes *Sent:* Monday, November 03, 2014 3:59 PM *To:* Bill Fischofer *Cc:* lng-odp *Subject:* Re: [lng-odp] [[RFC PATCH]] RFC for new buffer .h files On 2 November 2014 22:06, Bill Fischofer bill.fischo...@linaro.org wrote: RFC version of patches for new buffer .h files. Includes all API changes from buffer design doc + extended notes. Do not merge until corresponding code changes are posted. Signed-off-by: Bill Fischofer bill.fischo...@linaro.org --- platform/linux-generic/include/api/odp_buffer.h| 532 - .../linux-generic/include/api/odp_buffer_pool.h| 242 +- 2 files changed, 740 insertions(+), 34 deletions(-) diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h index 289e0eb..9910d0e 100644 --- a/platform/linux-generic/include/api/odp_buffer.h +++ b/platform/linux-generic/include/api/odp_buffer.h @@ -8,7 +8,88 @@ /** * @file * - * ODP buffer descriptor + * @par Buffer + * A buffer is an element of a buffer pool used for storing + * information. Buffers are referenced by an abstract handle of type You have two spaces after the full stop -multiple instance + * odp_buffer_t. Buffers have associated buffer types that describe + * their intended use and the type of meta data that is associated + * with them. Buffers of a specific type may be referenced for + * processing by cores or by offload engines. Buffers are also + * transmitted via queues from one processing element to another. + * + * @par Buffer Types + * An ODP buffer type is identified by the + * odp_buffer_type_e enum. It defines the semantics that are to be + * attached to the buffer and defines the type of meta data that is + * associated with it. ODP implementations MUST support the following + * buffer types:brbr + * + * - ODP_BUFFER_TYPE_RAWbr Don't use raw HTML, use doxygen primitives, delete br multiple instances + * This is the “basic” buffer type + * which simply consists of a single fixed-sized block of contiguous + * memory. Buffers of this type do not support user meta data and the + * only built-in meta data supported for this type of buffer are those + * that are statically computable, such as pool and size. This type of + * buffer is entirely under application control and most of the buffer + * APIs defined in this document are not available. APIs for this + * type of buffer are described in this document.brbr One sentence per line as below for the paragraph above, this allow diff to clearly show future updates cleanly - multiple instances This is the “basic” buffer type which simply consists of a single fixed-sized block of contiguous memory. Buffers of this type do not support user meta data and the only built-in meta data supported for this type of buffer are those that are statically computable, such as pool and size. This type of buffer is entirely under application control and most of the buffer APIs defined in this document are not available. APIs for this type of buffer are described in this document. + * + * - ODP_BUFFER_TYPE_PACKETbr + * This buffer type is suitable for receiving, + * processing, and transmitting network packet data. Included in this + * type is a rich set of primitives for manipulating buffer aggregates + * and for storing system and user meta data. APIs for this type of + * buffer are described here and in the ODP Packet Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_TIMEOUTbr + * This buffer type is suitable for + * representing timer timeout events. Does not support buffer + * aggregation but does support user meta data. APIs for this type of + * buffer are described here and in the ODP Timer Management Design + * document.brbr + * + * - ODP_BUFFER_TYPE_ANYbr + * A “universal” buffer type capable of + * storing
Re: [lng-odp] [PATCH v2 00/18] Split out platform-specific values from header files
A need to split out a clean API headers is being discussed again, so pulling this thread up to remind what the previous attempt was. On 07/08/2014 05:55 PM, Mike Holmes wrote: We discussed this on a hangout, here are the results as a way forward on this 1 month old topic. Attendees: Bala Taras Maxim Santosh Marshall Mike Bill Actions required: Step one: Move odp/include to odp/platform/linux-generic/include, update the make files to suit. Step two: Pull the doxygen documentation back up to odp/doc/odp_xxx.dox out of the header files. General Rational: 1. Anecdotal evidence from previous projects suggests we will end up with per platform includes anyway 2. We are trying to accommodate splitting out the platform specifics on this thread, that is what has driven this issue so No.1 looks correct 3. Linux-generic is the reference implementation and by default it is what is built now so there is no change in observed bechavior. This includes the fact that the platform specifics show though, all that changes is that is it now clear that they are specific to that platform and no pretense that the default doc is is platform independent. 4. We reduce the directory structure complexity, no need to include odp/include for each platforms make file. 5. Other platforms already include Linux-generic to reuse its code so we are not adding any new paths to find the same headers for those cases, there is no impact if the Linux-generic is not needed. 6. The API documentation is still common, it can be stored once in odp/doc/odpx.dox, doxygen will tie this together with the headers found per platform. 7. Platforms are still free to add pages to augment the documentation with platform specifics. Negatives: 1. Documentation is no longer all kept right next to the definitions which is one reason to use doxygen in the first place. 2. There is less enforcement of the API across platforms, hopefully mitigated by the ODP-validation test suite. On 3 July 2014 13:14, Mike Holmes mike.hol...@linaro.org mailto:mike.hol...@linaro.org wrote: Let me take a look, I will ping you offline to make sure I understand and replicate the issue correctly On 3 July 2014 06:26, Taras Kondratiuk taras.kondrat...@linaro.org mailto:taras.kondrat...@linaro.org wrote: On 06/26/2014 06:24 PM, Taras Kondratiuk wrote: As we have discussed during a call, I've tried to implement option #2 for several files, but looks like Doxygen is not happy if documented variable can't be found in its input files. I couldn't find a Doxygen option that controls this behavior. Mike, do you have some ideas how to workaround it? Mike, do you have some hints? -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Addition to odp_init interface
On 11/03/2014 03:02 PM, Shmulik Ladkani wrote:
On Mon, 03 Nov 2014 14:09:02 +0200 Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
Won't it be simpler to add a new local initialization API in your
library instead of piggy-backing on ODP local init call?
Something like:
stl_odp_local_init()
{
odp_local_init();
stl_local_init(); /* Here your lib local init is done */
}
That would be one approach, yes.
But IMO it has some disadvantages over registering a hook into
'odp_init_local':
1. Users must call 'stl_odp_local_init' upon program init (and not
odp_init_local).
And IMO that's correct, because user uses your library, but not ODP
directly. I assume the library adds some more API which will be also
called directly.
2. 'odp_init_local' is currently invoked automatically from the thread
created by 'odph_linux_pthread_create()'.
(See odp_run_start_routine, which first calls 'odp_init_local' and only
then calls the user's start_routine).
Meaning, following the 'stl_odp_local_init' paradigm, I would also
need to expose a 'stl_odph_linux_pthread_create()' that properly
invokes 'stl_odp_local_init' automatically, too.
odph_linux_pthread_create() is a helper routine, so it is not a part of
normative ODP API. You can define one for your library.
Combine these two, and let's even imagine there's more than one entity
that requires per-thread initialization - following the
'stl_odp_local_init' approach might get messy.
I don't have a big picture of what you are trying to achieve, but ODP
is not a framework for thread-local initialization of 3rd party
libraries. There are several ways to solve your issue without changing
ODP API:
1. Strict hierarchy - when your library is built on top of ODP and
expose its own local init function stl_odp_local_init().
2. New ODP implementation which will provide modified odp_init_local()
to initialize your library.
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH v3] add tests for queue
From: yan.songming yan.songm...@linaro.org
Add the cunit test for none sync queue. Test the base queue function.
Signed-off-by: yan.songming yan.songm...@linaro.org
---
Fix spelling problem and commend problem. Add term_local and term_global.
Move cunit queue test to test_odp_queue_base for none syn queue.
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base, MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue, ODP_QUEUE_TYPE_POLL,
param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL, odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_SCHED_SYNC_NONE, odp_queue_sched_type(queue_creat_id));
+
+/* test odp_queue_lookup */
+queue_id = odp_queue_lookup(test_queue);
+CU_ASSERT_EQUAL(queue_creat_id, queue_id);
+
+/* test odp_queue_set_context */
+CU_ASSERT(0 == odp_queue_set_context(queue_id, Queue_Contest));
+
+/* test odp_queue_get_context*/
+pRtn = odp_queue_get_context(queue_id);
+CU_ASSERT(Queue_Contest == (int *)pRtn);
+
+/* apply for buffer */
+msg_pool = odp_buffer_pool_lookup(msg_pool);
+buf = odp_buffer_alloc(msg_pool);
+
+/* test odp_queue_enq and odp_queue_deq */
+odp_queue_enq(queue_id, buf);
+CU_ASSERT_EQUAL(buf, odp_queue_deq(queue_id));
+odp_buffer_free(buf);
+
+/* apply for mutili buffer */
+for(i=0; iMAX_BUFFER_QUEUE; i++) {
+Enbuf[i] = odp_buffer_alloc(msg_pool);
+}
+
+/* test odp_queue_enq_multi and odp_queue_enq_multi */
+odp_queue_enq_multi(queue_id, Enbuf, MAX_BUFFER_QUEUE);
+odp_queue_deq_multi(queue_id, Debuf, MAX_BUFFER_QUEUE);
+
+for(i=0; iMAX_BUFFER_QUEUE; i++) {
+/* test odp_queue_deq_multi */
+CU_ASSERT_EQUAL(Enbuf[i], Debuf[i]);
+/* buffer free */
+odp_buffer_free(Enbuf[i]);
+}
+return;
+
+}
+
+static void test_odp_queue(void)
+{
+
+int status;
+status = odp_init_global(NULL, NULL);
+CU_ASSERT_FATAL(0 == status);
+
+CU_ASSERT(0 == odp_init_local())
+
+/* initialize buffer pool */
+CU_ASSERT_FATAL(0 == test_odp_buffer_pool_init());
+
+/* test odp none syne queue */
+test_odp_queue_base();
+
+status = odp_term_local();
+CU_ASSERT(0 == status);
+
+status = odp_term_global();
+CU_ASSERT(0 == status);
+return;
+}
+
+
+
+static int init(void)
+{
+printf(\tODP version: %s\n, odp_version_api_str());
+return 0;
+}
+
+static int finalize(void)
+{
+return 0;
+}
+
+int main(void)
+{
+CU_pSuite
Re: [lng-odp] [PATCH v3] add tests for queue
mike@fedora1:~/git/odp$ git am
~/incoming/lng-odp_PATCH_v3_add_tests_for_queue.mbox
Applying: add tests for queue
/home/mike/git/odp/.git/rebase-apply/patch:81: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:85: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:101: trailing whitespace.
CU_ASSERT_EQUAL(queue_creat_id, queue_id);
/home/mike/git/odp/.git/rebase-apply/patch:152: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:155: trailing whitespace.
warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.
If scripts/checkpatch did not see these problems you need to make a branch
or new repo and apply the patch so that git am can show you the issues.
On 3 November 2014 11:31, Yan Songming yan.songm...@linaro.org wrote:
From: yan.songming yan.songm...@linaro.org
Add the cunit test for none sync queue. Test the base queue function.
Signed-off-by: yan.songming yan.songm...@linaro.org
---
Fix spelling problem and commend problem. Add term_local and term_global.
Move cunit queue test to test_odp_queue_base for none syn queue.
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num
*/
+#define MSG_POOL_SIZE (4*1024*1024) /** Message pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base, MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE,
ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue, ODP_QUEUE_TYPE_POLL,
param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL, odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_SCHED_SYNC_NONE,
odp_queue_sched_type(queue_creat_id));
+
+/* test odp_queue_lookup */
+queue_id = odp_queue_lookup(test_queue);
+CU_ASSERT_EQUAL(queue_creat_id, queue_id);
+
+/* test odp_queue_set_context */
+CU_ASSERT(0 == odp_queue_set_context(queue_id, Queue_Contest));
+
+/* test odp_queue_get_context*/
+pRtn = odp_queue_get_context(queue_id);
+CU_ASSERT(Queue_Contest == (int *)pRtn);
+
+/* apply for buffer */
+msg_pool = odp_buffer_pool_lookup(msg_pool);
+buf = odp_buffer_alloc(msg_pool);
+
+/* test odp_queue_enq and odp_queue_deq */
+odp_queue_enq(queue_id, buf);
+CU_ASSERT_EQUAL(buf, odp_queue_deq(queue_id));
+odp_buffer_free(buf);
+
+/* apply for mutili buffer */
+for(i=0; iMAX_BUFFER_QUEUE; i++) {
+Enbuf[i] = odp_buffer_alloc(msg_pool);
+}
+
+/* test odp_queue_enq_multi and odp_queue_enq_multi */
+odp_queue_enq_multi(queue_id, Enbuf, MAX_BUFFER_QUEUE);
+
Re: [lng-odp] [RFC] Addition to odp_init interface
Are you doing ODP C++ class and need proper destroy functions on this
class delete?
odph_linux_pthread_create() and other odph_ are helper functions. You
can use them, but it's not part of
ODP API. So fill free to call odp API directly (i.e. do the same but add
your stl thing there).
BR,
Maxim.
On 11/03/2014 03:09 PM, Taras Kondratiuk wrote:
On 11/03/2014 12:22 PM, Shmulik Ladkani wrote:
Hi Taras,
On Mon, 03 Nov 2014 12:00:33 +0200 Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
Could you please elaborate it? What is a usecase?
Think of a library extending the ODP library.
Specifically, I was playing around creating a C++ STL compatible
allocator template, whose implementation is based on ODP building
blocks.
(Well, I assume that most ODP apps would be written in C, and even if
written in C++, they'd probably use ODP memory allocation interfaces
directly for their specific needs. However such a library *could* allow
one to use STL data structures allocated by ODP means).
Such a library is unaware of how many threads its user will create, but
it needs to initialize some per-thread locals it has.
An 'odp_init_local_register' interface would allow one to do so, and
it's pretty harmful as it exposes none of ODP's internals.
The registered function may use any standard interfaces the ODP allows.
Won't it be simpler to add a new local initialization API in your
library instead of piggy-backing on ODP local init call?
Something like:
stl_odp_local_init()
{
odp_local_init();
stl_local_init(); /* Here your lib local init is done */
}
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [Q] Memory allocation in ODP applications
Hi, As demonstrated by odp/examples, libc memory allocation routines (malloc and friends) aren't been used by ODP apps (unless for a very tight temporary scope, usually in the control thread). Application's data structures are allocated either using odp_buffer_pool interface (e.g. odp_ipsec.c allocating its private per packet context structure using a ODP_BUFFER_TYPE_RAW pool), or directly using odp_shm_reserve and managing it internally (e.g. odp_ipsec_fwd_db.c, odp_ipsec_sp_db.c etc). Questions: Must the application use ODP memory allocation interfaces at all times? Or only for data structures accessed at data-path routines? Or only when allocating them from within data-path routines? Any preference for when to use a ODP_BUFFER_TYPE_RAW pool vs. allocating a shared memory and managing data structures internally? Thanks, Shmulik ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH NETMAP 1/2] odp_pktio_netmap: add option to disable loopback
Signed-off-by: Ciprian Barbu ciprian.ba...@linaro.org
---
example/packet_netmap/odp_pktio_netmap.c | 12 --
platform/linux-netmap/README | 40 ++--
2 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/example/packet_netmap/odp_pktio_netmap.c
b/example/packet_netmap/odp_pktio_netmap.c
index a2756ee..b789064 100644
--- a/example/packet_netmap/odp_pktio_netmap.c
+++ b/example/packet_netmap/odp_pktio_netmap.c
@@ -119,6 +119,9 @@ typedef struct {
/** Global pointer to args */
static args_t *args;
+/** By default act as loopback and bridge */
+static int loopback = 1;
+
/* helper funcs */
static int drop_err_pkts(odp_packet_t pkt_tbl[], unsigned len);
static void swap_pkt_addrs(odp_packet_t pkt_tbl[], unsigned len);
@@ -187,7 +190,7 @@ static void *pktio_queue_thread(void *arg)
pktio_info = args-pktio_lt[pktio_tmp];
/* Send back packets arrived on physical interface */
- if (pktio_info-netmap_mode == ODP_NETMAP_RING_HW) {
+ if (pktio_info-netmap_mode == ODP_NETMAP_RING_HW loopback) {
odp_packet_t pkt_copy;
pkt_copy = odph_packet_alloc(pkt_pool);
@@ -460,11 +463,12 @@ static void parse_args(int argc, char *argv[],
appl_args_t *appl_args)
static struct option longopts[] = {
{interface, required_argument, NULL, 'i'},/* return 'i' */
{help, no_argument, NULL, 'h'}, /* return 'h' */
+ {bridge, no_argument, NULL, 'b'}, /* return 'b' */
{NULL, 0, NULL, 0}
};
while (1) {
- opt = getopt_long(argc, argv, +i:h, longopts, long_index);
+ opt = getopt_long(argc, argv, +i:h:b, longopts, long_index);
if (opt == -1)
break; /* No more options */
@@ -521,6 +525,9 @@ static void parse_args(int argc, char *argv[], appl_args_t
*appl_args)
exit(EXIT_SUCCESS);
break;
+ case 'b':
+ loopback = 0;
+
default:
break;
}
@@ -582,6 +589,7 @@ static void usage(char *progname)
\n
Optional OPTIONS\n
-h, --help Display help and exit.\n
+-b, --bridge Bridge only, disable loopback.\n
\n, NO_PATH(progname), NO_PATH(progname)
);
}
diff --git a/platform/linux-netmap/README b/platform/linux-netmap/README
index 42b7595..64ee3bd 100644
--- a/platform/linux-netmap/README
+++ b/platform/linux-netmap/README
@@ -85,18 +85,44 @@ To configure ODP for linux-generic:
3. Running the example application
==
-The example application for netmap-linux is odp_pktio_netmap. The main purpose
-of the example application is to show how to implement a simple packet loopback
-application using ODP. The example also implements a bridge between the Linux
-IP stack and the physical interfaces since netmap disrupts the communication
-between the two. The bridging is achieved by passing packets between the
-software ring attached to the host stack and the physical rings of the NIC.
+The example application for netmap-linux is odp_pktio_netmap.
+
+The main feature of this application is that it can bridge the interfaces with
+the netmap software rings attached to the host stack. There is one such
software
+ring for each interface in the system that runs in netmap mode.
+
+Another feature of the example application is to run as a basic loopback app,
+similar to the packet example from linux-generic. In this mode bridging is
still
+active.
+
More information on netmap architecture and software rings can be found in the
netmap: a novel framework for fast packet I/O paper by Luigi Rizzo on his
research page: http://info.iet.unipi.it/~luigi/research.html
-sudo ./odp_pktio_netmap -i eth0 -m 1
+3.1 Running with loopback on
+
+This is the default mode, you can pass more than one interfaces, sepparated by
+comma.
+
+sudo ./odp_pktio_netmap -i eth0,eth1
From another machine you can simply run ping and observe the duplicate ICMP
replies. Also the host running the example application should still have
network
connectivity due to the bridging performed as explained above.
+
+3.2 Running with loopback off
+-
+This mode of operation is very similar to the netmap bridge example, with the
+difference that the bridging will only be performed between the NICs and the
+corresponding software rings attached to the host stack.
+
+One use of this application is iperf.
+
+From the 'server':
+
+iperf -s
+
+From the 'client':
+
+iperf -c server_ip
+
--
1.8.3.2
___
lng-odp mailing list
lng-odp@lists.linaro.org
[lng-odp] [PATCH NETMAP 2/2] Update to netmap v11.1
Signed-off-by: Ciprian Barbu ciprian.ba...@linaro.org
---
platform/linux-netmap/README | 22 +-
platform/linux-netmap/odp_packet_netmap.c | 7 +--
platform/linux-netmap/odp_packet_netmap.h | 4 ++--
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/platform/linux-netmap/README b/platform/linux-netmap/README
index 64ee3bd..5148091 100644
--- a/platform/linux-netmap/README
+++ b/platform/linux-netmap/README
@@ -25,20 +25,18 @@ at runtime.
2.1 Building netmap
-Netmap is currently hosted on https://code.google.com/p/netmap/ but
-ODP only works at this point with netmap API version 10 so you will need
-a specific revision of netmap.
+Netmap is currently hosted on https://code.google.com/p/netmap/
git clone https://code.google.com/p/netmap/
cd netmap
-git reset --hard 1f462ef
+git co v11.1
Netmap consists of a core kernel module (netmap_lin.ko) and optional modified
device drivers.
Netmap builds as an out-of-tree kernel module, you need matching kernel sources
to compile it. General build instructions can be found in the packet README:
-http://code.google.com/p/netmap/source/browse/README
+https://code.google.com/p/netmap/source/browse/LINUX/README
2.1.1 Building netmap on Ubuntu with stock kernel
@@ -56,12 +54,14 @@ You will need to locate it and extract it to a convenient
place.
Now compile netmap:
cd LINUX
-make SRC=path_to_kernel_source
+./configure --kernel-sources=path_to_kernel_src
+make
2.1.2 Building netmap for kernel built from sources
cd LINUX
-make KSRC=path_to_kernel_source
+./configure --kernel-dir=path_to_kernel_tree
+make
2.2 Building ODP
@@ -69,13 +69,17 @@ Now compile netmap:
The default platform is linux-netmap, if you want linux-generic you need to
specify it to configure --with-platform.
+ODP works with the latest release version of netmap, which is currently at API
+version 11.1. There is one problem though, the default CFLAGS that ODP is built
+with contains -Werror=cast-qual. A temporary fix would be to disable this flag.
+
The --with-sdk-install-path can be used to point to the netmap sources.
./bootstrap
-./configure
+./configure CFLAGS='-Wno-cast-qual'
or
-./configure --with-sdk-install-path=netmap
+./configure --with-sdk-install-path=netmap CFLAGS='-Wno-cast-qual'
To configure ODP for linux-generic:
./configure --with-platform=linux-generic
diff --git a/platform/linux-netmap/odp_packet_netmap.c
b/platform/linux-netmap/odp_packet_netmap.c
index 6b9b120..2e35aec 100644
--- a/platform/linux-netmap/odp_packet_netmap.c
+++ b/platform/linux-netmap/odp_packet_netmap.c
@@ -142,8 +142,11 @@ int setup_pkt_netmap(pkt_netmap_t * const pkt_nm, const
char *netdev,
else
ringid = nm_params-ringid;
- strncpy(pkt_nm-ifname, netdev, sizeof(pkt_nm-ifname));
- snprintf(ifname, sizeof(ifname), netmap:%s, netdev);
+ snprintf(pkt_nm-ifname, sizeof(pkt_nm-ifname), %s, netdev);
+ if (nm_params-netmap_mode == ODP_NETMAP_RING_SW)
+ snprintf(ifname, sizeof(ifname), netmap:%s^, netdev);
+ else
+ snprintf(ifname, sizeof(ifname), netmap:%s, netdev);
pkt_nm-nm_desc = nm_open(ifname, NULL, ringid, 0);
if (pkt_nm-nm_desc == NULL) {
diff --git a/platform/linux-netmap/odp_packet_netmap.h
b/platform/linux-netmap/odp_packet_netmap.h
index 4b66d3d..4334b9e 100644
--- a/platform/linux-netmap/odp_packet_netmap.h
+++ b/platform/linux-netmap/odp_packet_netmap.h
@@ -32,14 +32,14 @@ typedef struct {
size_t frame_offset; /** frame start offset from start of pkt buf */
size_t buf_size; /** size of buffer payload in 'pool' */
int netmap_mode;
- struct nm_desc_t *nm_desc;
+ struct nm_desc *nm_desc;
uint32_t begin;
uint32_t end;
struct netmap_ring *rxring;
struct netmap_ring *txring;
odp_queue_t tx_access; /* Used for exclusive access to send packets */
uint32_t if_flags;
- char ifname[32];
+ char ifname[IFNAMSIZ];
} pkt_netmap_t;
/**
--
1.8.3.2
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH NETMAP 0/2] Update to netmap v11.1
This patch series updates the netmap support to the freshly released netmap v11.1. It also tweakes the test application a bit, to be able to run etwork performance tests, such as iperf. With the loopback mode TCP connections fail, due to duplicate SYN packets. Ciprian Barbu (2): odp_pktio_netmap: add option to disable loopback Update to netmap v11.1 example/packet_netmap/odp_pktio_netmap.c | 12 +- platform/linux-netmap/README | 62 +++ platform/linux-netmap/odp_packet_netmap.c | 7 +++- platform/linux-netmap/odp_packet_netmap.h | 4 +- 4 files changed, 63 insertions(+), 22 deletions(-) -- 1.8.3.2 ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [PATCH v3] add tests for queue
http://people.linaro.org/~mike.holmes/linux-generic-gcov-html/linux-generic/index.html
Yan it looks like there odp_buffer_t queue_sched_buf(odp_queue_t handle)
was not called in the test suite.
Also the internal void queue_lock(queue_entry_t *queue) was not called but
maybe odp_packet_io tests may cover that, I believe it is used there.
Mike
On 3 November 2014 11:45, Mike Holmes mike.hol...@linaro.org wrote:
mike@fedora1:~/git/odp$ git am
~/incoming/lng-odp_PATCH_v3_add_tests_for_queue.mbox
Applying: add tests for queue
/home/mike/git/odp/.git/rebase-apply/patch:81: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:85: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:101: trailing whitespace.
CU_ASSERT_EQUAL(queue_creat_id, queue_id);
/home/mike/git/odp/.git/rebase-apply/patch:152: trailing whitespace.
/home/mike/git/odp/.git/rebase-apply/patch:155: trailing whitespace.
warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.
If scripts/checkpatch did not see these problems you need to make a
branch or new repo and apply the patch so that git am can show you the
issues.
On 3 November 2014 11:31, Yan Songming yan.songm...@linaro.org wrote:
From: yan.songming yan.songm...@linaro.org
Add the cunit test for none sync queue. Test the base queue function.
Signed-off-by: yan.songming yan.songm...@linaro.org
---
Fix spelling problem and commend problem. Add term_local and term_global.
Move cunit queue test to test_odp_queue_base for none syn queue.
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num
*/
+#define MSG_POOL_SIZE (4*1024*1024) /** Message pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base, MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE,
ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue, ODP_QUEUE_TYPE_POLL,
param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL, odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_SCHED_SYNC_NONE,
odp_queue_sched_type(queue_creat_id));
+
+/* test odp_queue_lookup */
+queue_id = odp_queue_lookup(test_queue);
+CU_ASSERT_EQUAL(queue_creat_id, queue_id);
+
+/* test odp_queue_set_context */
+CU_ASSERT(0 == odp_queue_set_context(queue_id, Queue_Contest));
+
+/* test odp_queue_get_context*/
+pRtn = odp_queue_get_context(queue_id);
+CU_ASSERT(Queue_Contest == (int *)pRtn);
+
+/* apply for buffer */
+msg_pool = odp_buffer_pool_lookup(msg_pool);
+buf = odp_buffer_alloc(msg_pool);
+
+/* test odp_queue_enq
Re: [lng-odp] [PATCH] odp_ring_test.c: free buffer on fail
ping
On 24 October 2014 15:46, Mike Holmes mike.hol...@linaro.org wrote:
On data mismatch free the recently mallocked buffer.
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
test/api_test/odp_ring_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
index 1da5845..eb1f301 100644
--- a/test/api_test/odp_ring_test.c
+++ b/test/api_test/odp_ring_test.c
@@ -286,6 +286,7 @@ static int consumer_fn(void)
if (i == 0) {
for (i = 0; i MAX_BULK; i++) {
if (src[i] != (void *)(unsigned long)i) {
+ free(src);
printf(data mismatch.. lockless
ops fail\n);
return -1;
}
--
2.1.0
--
*Mike Holmes*
Linaro Sr Technical Manager
LNG - ODP
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [Q] Memory allocation in ODP applications
On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer bill.fischo...@linaro.org wrote: ODP APIs are designed to be used *a la carte* by applications, as ODP is a framework, not a platform. So feel free to mix malloc() or your own memory management or other API calls in as needed. What ODP requires is the types specified in its APIs, so for example the only way to get an odp_buffer_t is via the odp_buffer_alloc() call. odp_buffer_alloc() in turn requires an odp_buffer_pool_t and that in turn requires an odp_buffer_pool_create() call. ODP_BUFFER_TYPE_RAW simply exposes the basic block manager functions of the ODP buffer APIs. Again, you're free to use them for whatever purpose the application wants. Obviously one reason for doing so is to gain portability across potentially different memory management implementations. Thanks Bill. This leads me to few additional questions: Are all memory-related ODP APIs mandatory (must be implemented by the platform)? Are they required to provide any other benefit over standard (or custom) allocation routines besides the portability guarantee? Regards, Shmulik ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [Q] Memory allocation in ODP applications
ODP APIs are divided into two classes: Mandatory, which all conforming ODP implementations are expected to provide, and Optional. The convention is that Optional APIs must be present but calling them may simply result in an ODP_FUNCTION_NOT_AVAILABLE return code. These are documented in the associated header files (currently under revision) and are part of the doxygen. Basically, unless an API calls itself out as OPTIONAL you should assume that all ODP implementations will provide functional implementations of it, though performance of individual APIs may vary between platforms and within platforms over time. It's expected that each platform will provide implementations of the ODP APIs that are optimized for that particular platform. ODP itself does not specify how implementations do that or how they might improve performance over time with subsequent releases of the implementation. This was the reason for decoupling the APIs from the implementations and supporting multiple repositories. It's expected that, over time, implementations will evolve and improve their performance as the implementations become better tuned to refinements in their underlying platform. Hope that helps. Bill On Mon, Nov 3, 2014 at 2:18 PM, Shmulik Ladkani shmulik.ladk...@gmail.com wrote: On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer bill.fischo...@linaro.org wrote: ODP APIs are designed to be used *a la carte* by applications, as ODP is a framework, not a platform. So feel free to mix malloc() or your own memory management or other API calls in as needed. What ODP requires is the types specified in its APIs, so for example the only way to get an odp_buffer_t is via the odp_buffer_alloc() call. odp_buffer_alloc() in turn requires an odp_buffer_pool_t and that in turn requires an odp_buffer_pool_create() call. ODP_BUFFER_TYPE_RAW simply exposes the basic block manager functions of the ODP buffer APIs. Again, you're free to use them for whatever purpose the application wants. Obviously one reason for doing so is to gain portability across potentially different memory management implementations. Thanks Bill. This leads me to few additional questions: Are all memory-related ODP APIs mandatory (must be implemented by the platform)? Are they required to provide any other benefit over standard (or custom) allocation routines besides the portability guarantee? Regards, Shmulik ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH v2] fix including odp_std_types.h
API headers should not include C std lib headers directly
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
v2:
remove endian.h it should be cleaned up during configuration / build
platform/linux-generic/include/api/odp_debug.h | 3 +--
platform/linux-generic/include/api/odp_std_types.h | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/platform/linux-generic/include/api/odp_debug.h
b/platform/linux-generic/include/api/odp_debug.h
index c9b2edd..99f4574 100644
--- a/platform/linux-generic/include/api/odp_debug.h
+++ b/platform/linux-generic/include/api/odp_debug.h
@@ -12,8 +12,7 @@
#ifndef ODP_DEBUG_H_
#define ODP_DEBUG_H_
-#include stdio.h
-#include stdlib.h
+#include odp_std_types.h
#ifdef __cplusplus
extern C {
diff --git a/platform/linux-generic/include/api/odp_std_types.h
b/platform/linux-generic/include/api/odp_std_types.h
index b12a2f3..e3aa5ab 100644
--- a/platform/linux-generic/include/api/odp_std_types.h
+++ b/platform/linux-generic/include/api/odp_std_types.h
@@ -26,6 +26,8 @@ extern C {
#include stdint.h
#include inttypes.h
#include limits.h
+#include stdio.h
+#include stdlib.h
--
2.1.0
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH] exception_handling.dox: remove redundant text
Signed-off-by: Mike Holmes mike.hol...@linaro.org --- exception_handling.dox | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exception_handling.dox b/exception_handling.dox index fe693bc..03a9bbd 100644 --- a/exception_handling.dox +++ b/exception_handling.dox @@ -5,7 +5,7 @@ */ /** -@page exception_handling Exception handling in the ODP API +@page exception_handling Exception handling @tableofcontents For the implimentation of the exception handling please see @ref odp_debug.h -- 2.1.0 ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [PATCH v3] add tests for queue
On 2014-11-04 00:31, Yan Songming wrote:
From: yan.songming yan.songm...@linaro.org
Say in subject something like this:
cunit/odp_queue: add queue test
Run checkpatch and fix the problems I will point out some of them and
other review comments.
In the C file change 4 space to 1 tab.
Be consistent either line varables up or don't do not mix.
Example:
odp_buffer_pool_t pool;
void *pool_base;
odp_shm_t shm;
or
odp_buffer_pool_t pool;
void *pool_base;
odp_shm_t shm;
Be consistent with you if-statements don't mix:
Example:
if (NULL == pool_base) {
or
if (pool_base == NULL) {
See more comments inline.
Add the cunit test for none sync queue. Test the base queue function.
Signed-off-by: yan.songming yan.songm...@linaro.org
---
Fix spelling problem and commend problem. Add term_local and term_global.
Move cunit queue test to test_odp_queue_base for none syn queue.
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
From both of the above *_LDFLAGS remove:
-static -lcunit and add that to line 6
AM_LDFLAGS += -L$(CUNIT_PATH)/lib -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
This should be below odp_init_test.c for alphabetic order
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message pool size */
+
+static int Queue_Contest = 0xff;
Remove CamelCase and I think you mean queue_context
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base, MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
Squash to two lines
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
Remove CamelCase
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
Remove CamelCase
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
Trailing whitespace
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
Remove CamelCase and should you remove a space before * to get the
variables to line up? =)
+
Trailing whitespace
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue, ODP_QUEUE_TYPE_POLL,
param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL, odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_SCHED_SYNC_NONE,
odp_queue_sched_type(queue_creat_id));
+
+/* test odp_queue_lookup */
+queue_id = odp_queue_lookup(test_queue);
+CU_ASSERT_EQUAL(queue_creat_id, queue_id);
Trailing whitespace
Cheers,
Anders
+
+/* test odp_queue_set_context */
+CU_ASSERT(0 == odp_queue_set_context(queue_id, Queue_Contest));
+
+/* test odp_queue_get_context*/
+pRtn = odp_queue_get_context(queue_id);
+CU_ASSERT(Queue_Contest == (int *)pRtn);
+
+/* apply for buffer */
+msg_pool = odp_buffer_pool_lookup(msg_pool);
+buf = odp_buffer_alloc(msg_pool);
+
+/* test odp_queue_enq and odp_queue_deq */
+odp_queue_enq(queue_id, buf);
+CU_ASSERT_EQUAL(buf, odp_queue_deq(queue_id));
+odp_buffer_free(buf);
+
+/*
Re: [lng-odp] [PATCH v3] add tests for queue
On Tue, Nov 04, 2014 at 12:31:03AM +0800, Yan Songming wrote:
From: yan.songming yan.songm...@linaro.org
Add the cunit test for none sync queue. Test the base queue function.
Signed-off-by: yan.songming yan.songm...@linaro.org
---
Fix spelling problem and commend problem. Add term_local and term_global.
Move cunit queue test to test_odp_queue_base for none syn queue.
---
test/cunit/Makefile.am | 4 +-
test/cunit/odp_queue_test.c | 168
2 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 test/cunit/odp_queue_test.c
diff --git a/test/cunit/Makefile.am b/test/cunit/Makefile.am
index 927a5a5..46f46c9 100644
--- a/test/cunit/Makefile.am
+++ b/test/cunit/Makefile.am
@@ -6,8 +6,10 @@ AM_LDFLAGS += -L$(CUNIT_PATH)/lib
if ODP_CUNIT_ENABLED
TESTS = ${bin_PROGRAMS}
check_PROGRAMS = ${bin_PROGRAMS}
-bin_PROGRAMS = odp_init
+bin_PROGRAMS = odp_init odp_queue
odp_init_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
+odp_queue_LDFLAGS = $(AM_LDFLAGS) -static -lcunit
endif
+dist_odp_queue_SOURCES = odp_queue_test.c
dist_odp_init_SOURCES = odp_init_test.c
diff --git a/test/cunit/odp_queue_test.c b/test/cunit/odp_queue_test.c
new file mode 100644
index 000..04342a6
--- /dev/null
+++ b/test/cunit/odp_queue_test.c
@@ -0,0 +1,168 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include odp.h
+#include CUnit/Basic.h
+
+#define MAX_BUFFER_QUEUE(8) /** Max enqueue buf num */
+#define MSG_POOL_SIZE (4*1024*1024) /** Message pool size */
+
+static int Queue_Contest = 0xff;
+
+static int test_odp_buffer_pool_init(void)
+{
+odp_buffer_pool_t pool;
+void *pool_base;
+odp_shm_t shm;
+
+shm = odp_shm_reserve(msg_pool,
+ MSG_POOL_SIZE, ODP_CACHE_LINE_SIZE, 0);
+
+pool_base = odp_shm_addr(shm);
+
+if (pool_base == NULL) {
+printf(Shared memory reserve failed.\n);
+return -1;
+}
+
+pool = odp_buffer_pool_create(msg_pool, pool_base, MSG_POOL_SIZE,
+ 0,
+ ODP_CACHE_LINE_SIZE, ODP_BUFFER_TYPE_RAW);
+
+if (pool == ODP_BUFFER_POOL_INVALID) {
+printf(Pool create failed.\n);
+return -1;
+}
+return 0;
+}
+
+static void test_odp_queue_base(void)
+{
+odp_queue_t queue_creat_id;
+odp_queue_t queue_id;
+odp_buffer_t Enbuf[MAX_BUFFER_QUEUE];
+odp_buffer_t Debuf[MAX_BUFFER_QUEUE];
+odp_buffer_pool_t msg_pool;
+odp_queue_param_t param;
+
+int i;
+odp_buffer_t buf;
+void *pRtn = NULL;
+
+/* test odp_queue_create */
+memset(param, 0, sizeof(param));
+param.sched.sync = ODP_SCHED_SYNC_NONE;
+
+queue_creat_id = odp_queue_create(test_queue, ODP_QUEUE_TYPE_POLL,
param);
+CU_ASSERT(ODP_QUEUE_INVALID != queue_creat_id);
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_QUEUE_TYPE_POLL, odp_queue_type(queue_creat_id));
+
+/* test odp_queue_type */
+CU_ASSERT_EQUAL(ODP_SCHED_SYNC_NONE,
odp_queue_sched_type(queue_creat_id));
+
+/* test odp_queue_lookup */
+queue_id = odp_queue_lookup(test_queue);
+CU_ASSERT_EQUAL(queue_creat_id, queue_id);
+
+/* test odp_queue_set_context */
+CU_ASSERT(0 == odp_queue_set_context(queue_id, Queue_Contest));
+
+/* test odp_queue_get_context*/
+pRtn = odp_queue_get_context(queue_id);
+CU_ASSERT(Queue_Contest == (int *)pRtn);
+
+/* apply for buffer */
+msg_pool = odp_buffer_pool_lookup(msg_pool);
+buf = odp_buffer_alloc(msg_pool);
+
+/* test odp_queue_enq and odp_queue_deq */
+odp_queue_enq(queue_id, buf);
+CU_ASSERT_EQUAL(buf, odp_queue_deq(queue_id));
+odp_buffer_free(buf);
+
+/* apply for mutili buffer */
+for(i=0; iMAX_BUFFER_QUEUE; i++) {
+Enbuf[i] = odp_buffer_alloc(msg_pool);
+}
+
+/* test odp_queue_enq_multi and odp_queue_enq_multi */
+odp_queue_enq_multi(queue_id, Enbuf, MAX_BUFFER_QUEUE);
+odp_queue_deq_multi(queue_id, Debuf, MAX_BUFFER_QUEUE);
odp_queue_*_multi should return number of buffers
enqueued/dequeued(which is inline with existing queue management design
document).
IMO we should add multi queue operation test when
the prototype finalizes in the design document.
+
+for(i=0; iMAX_BUFFER_QUEUE; i++) {
+/* test odp_queue_deq_multi */
+CU_ASSERT_EQUAL(Enbuf[i], Debuf[i]);
+/* buffer free */
+odp_buffer_free(Enbuf[i]);
+}
+return;
+
+}
+
+static void test_odp_queue(void)
+{
+
+int status;
+status = odp_init_global(NULL, NULL);
+CU_ASSERT_FATAL(0 == status);
+
+CU_ASSERT(0 == odp_init_local())
+
+/* initialize buffer pool */
+
Re: [lng-odp] [PATCH] odp_ring_test.c: free buffer on fail
On 24 October 2014 15:46, Mike Holmes mike.hol...@linaro.org wrote:
On data mismatch free the recently mallocked buffer.
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
test/api_test/odp_ring_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/api_test/odp_ring_test.c b/test/api_test/odp_ring_test.c
index 1da5845..eb1f301 100644
--- a/test/api_test/odp_ring_test.c
+++ b/test/api_test/odp_ring_test.c
@@ -286,6 +286,7 @@ static int consumer_fn(void)
if (i == 0) {
for (i = 0; i MAX_BULK; i++) {
if (src[i] != (void *)(unsigned long)i) {
+ free(src);
printf(data mismatch.. lockless
ops fail\n);
return -1;
}
+1,
Reviewed-by: Santosh Shukla santosh.shu...@linaro.org
--
2.1.0
--
*Mike Holmes*
Linaro Sr Technical Manager
LNG - ODP
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
