Re: [lng-odp] How to run ODP on Fedora?
On 05/19/2015 00:30, Ola Liljedahl wrote: On 18 May 2015 at 20:36, Li, Charlie charlie...@amd.com mailto:charlie...@amd.com wrote: Hi Maxim, I have tried linux-generic and odp_l2fwd worked. But when I tried netmap (https://git.linaro.org/lng/odp-netmap.git), I got the following compuler error. Did I missed anything? amd@amd-desktop:~/odp-netmap$ make Making all in doc make[1]: Entering directory `/home/amd/odp-netmap/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/amd/odp-netmap/doc' Making all in platform make[1]: Entering directory `/home/amd/odp-netmap/platform' Making all in linux-netmap make[2]: Entering directory `/home/amd/odp-netmap/platform/linux-netmap' Making all in test make[3]: Entering directory `/home/amd/odp-netmap/platform/linux-netmap/test' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/amd/odp-netmap/platform/linux-netmap/test' make[3]: Entering directory `/home/amd/odp-netmap/platform/linux-netmap' CC ../linux-generic/odp_barrier.lo CC ../linux-generic/odp_buffer.lo CC ../linux-generic/odp_classification.lo CC ../linux-generic/odp_cpumask.lo CC ../linux-generic/odp_crypto.lo CC ../linux-generic/odp_errno.lo CC ../linux-generic/odp_event.lo CC odp_init.lo CC ../linux-generic/odp_impl.lo CC ../../helper/linux.lo CC ../linux-generic/odp_packet.lo CC ../linux-generic/odp_packet_flags.lo CC odp_packet_io.lo CC ../linux-generic/odp_packet_socket.lo CC ../linux-generic/odp_pool.lo CC ../linux-generic/odp_queue.lo CC ../../helper/ring.lo CC ../linux-generic/odp_rwlock.lo CC ../linux-generic/odp_schedule.lo CC ../linux-generic/odp_shared_memory.lo CC ../linux-generic/odp_spinlock.lo CC ../linux-generic/odp_system_info.lo CC ../linux-generic/odp_thread.lo CC ../linux-generic/odp_ticketlock.lo CC ../linux-generic/odp_time.lo CC ../linux-generic/odp_timer.lo CC ../linux-generic/odp_version.lo CC ../linux-generic/odp_weak.lo CC arch/x86/odp_time.lo CC odp_packet_netmap.lo odp_packet_netmap.c:42:29: fatal error: net/netmap_user.h: No such file or directory #include net/netmap_user.h ^ Is netmap installed on your system? -- Ola You just need to follow steps described in platform/linux-netmap/README file: https://git.linaro.org/lng/odp-netmap.git/blob/HEAD:/platform/linux-netmap/README In your case looks like you did not provide --with-sdk-install-path= to netmap directory. Maxim. compilation terminated. make[3]: *** [odp_packet_netmap.lo] Error 1 make[3]: Leaving directory `/home/amd/odp-netmap/platform/linux-netmap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/amd/odp-netmap/platform/linux-netmap' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/amd/odp-netmap/platform' make: *** [all-recursive] Error 1 amd@amd-desktop:~/odp-netmap$ /Regards,/ /Charlie Li/ *From:* Li, Charlie *Sent:* Thursday, May 14, 2015 9:26 AM *To:* Maxim Uvarov *Cc:* LNG ODP Mailman List *Subject:* RE: How to run ODP on Fedora? Thanks Maxim, I will start with linux-generic then move to netmap. /Regards,/ /Charlie Li/ *From:*Maxim Uvarov [mailto:maxim.uva...@linaro.org mailto:maxim.uva...@linaro.org] *Sent:* Thursday, May 14, 2015 4:04 AM *To:* Li, Charlie *Cc:* LNG ODP Mailman List *Subject:* Re: How to run ODP on Fedora? Hello Charlie, To run ODP functionality refer to README file in the root of linux-generic odp repo: https://git.linaro.org/lng/odp.git it has to be very simple. Compile it and build. Then run ./test/performance/odp_l2fwd application and specify required network cards. But linux-generic works with raw sockets and it's more functional then performance. In you case you have ARM and intel nics. To accelerate packet i/o you can use netmap or dpdk. Netmap is most fresh and dpdk is under development to match odp 1.0.4 specification. And we support dpdk only for x86. So some development will be needed to fully support dpdk as back end to odp. So for now to get good number in your case netmap is only option. Please find it in separate repo under Downoads link on ODP web page. Best regards, Maxim. On 13 May 2015 at 22:21, Li, Charlie charlie...@amd.com mailto:charlie...@amd.com wrote: Hi Maxim, I’d
Re: [lng-odp] [PATCH 1/2] examples: ipsec: tunnel mode support
Hi Steve,
please find comments inline.
Alex
On 19 May 2015 at 04:13, Steve Kordus (skordus) skor...@cisco.com wrote:
Sorry it took so long.
I just have a couple of questions/comments (see the SRK imbedded in
the diffs below), otherwise it looked fine to me.
Steve
-Original Message-
From: Robbie King (robking)
Sent: Monday, May 18, 2015 1:47 PM
To: Maxim Uvarov; lng-odp@lists.linaro.org
Cc: Steve Kordus (skordus)
Subject: RE: [lng-odp] [PATCH 1/2] examples: ipsec: tunnel mode support
Hi Maxim, Steve Kordus is going to handle this one.
Thanks Steve!
-Original Message-
From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
Sent: Monday, May 18, 2015 12:56 PM
To: lng-odp@lists.linaro.org; Robbie King (robking)
Subject: Re: [lng-odp] [PATCH 1/2] examples: ipsec: tunnel mode support
Hello Robbie,
can you please review that patch and next 2/2 patch.
Thanks,
Maxim.
On 05/11/2015 14:48, alexandru.badici...@linaro.org wrote:
From: Alexandru Badicioiu alexandru.badici...@linaro.org
Tunnel mode is enabled from the command line using -t argument with
the following format: SrcIP:DstIP:TunnelSrcIP:TunnelDstIP.
SrcIP - cleartext packet source IP
DstIP - cleartext packet destination IP TunnelSrcIP - tunnel source IP
TunnelDstIP - tunnel destination IP
The outbound packets matching SrcIP:DstIP will be encapsulated in a
TunnelSrcIP:TunnelDstIP IPSec tunnel (AH/ESP/AH+ESP) if a matching
outbound SA is determined (as for transport mode).
For inbound packets each entry in the IPSec cache is matched for the
cleartext addresses, as in the transport mode (SrcIP:DstIP) and then
for the tunnel addresses (TunnelSrcIP:TunnelDstIP) in case cleartext
addresses didn't match. After authentication and decryption tunneled
packets are verified against the tunnel entry (packets came in from
the expected tunnel).
Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
---
example/ipsec/odp_ipsec.c| 105 +++---
example/ipsec/odp_ipsec_cache.c | 31 +-
example/ipsec/odp_ipsec_cache.h |5 ++
example/ipsec/odp_ipsec_sa_db.c | 133
+-
example/ipsec/odp_ipsec_sa_db.h | 57
example/ipsec/odp_ipsec_stream.c | 101
6 files changed, 402 insertions(+), 30 deletions(-)
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index cb8f535..e325347 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -135,13 +135,20 @@ typedef struct {
uint8_t ip_ttl; /** Saved IP TTL value */
int hdr_len;/** Length of IPsec headers */
int trl_len;/** Length of IPsec trailers */
+ uint16_t tun_hdr_offset; /** Offset of tunnel header from
+ buffer start */
uint16_t ah_offset; /** Offset of AH header from buffer
start */
uint16_t esp_offset; /** Offset of ESP header from buffer
start */
+ /* Input only */
+ uint32_t src_ip; /** SA source IP address */
+ uint32_t dst_ip; /** SA dest IP address */
+
/* Output only */
odp_crypto_op_params_t params; /** Parameters for crypto call */
uint32_t *ah_seq; /** AH sequence number location */
uint32_t *esp_seq; /** ESP sequence number location
*/
+ uint16_t *tun_hdr_id; /** Tunnel header ID */
} ipsec_ctx_t;
/**
@@ -357,6 +364,7 @@ void ipsec_init_pre(void)
/* Initialize our data bases */
init_sp_db();
init_sa_db();
+ init_tun_db();
init_ipsec_cache();
}
@@ -376,19 +384,27 @@ void ipsec_init_post(crypto_api_mode_e api_mode)
for (entry = sp_db-list; NULL != entry; entry = entry-next) {
sa_db_entry_t *cipher_sa = NULL;
sa_db_entry_t *auth_sa = NULL;
+ tun_db_entry_t *tun;
- if (entry-esp)
+ if (entry-esp) {
cipher_sa = find_sa_db_entry(entry-src_subnet,
entry-dst_subnet,
1);
- if (entry-ah)
+ tun = find_tun_db_entry(cipher_sa-src_ip,
+ cipher_sa-dst_ip);
+ }
+ if (entry-ah) {
auth_sa = find_sa_db_entry(entry-src_subnet,
entry-dst_subnet,
0);
+ tun = find_tun_db_entry(auth_sa-src_ip,
+ auth_sa-dst_ip);
+ }
if (cipher_sa || auth_sa) {
if
[lng-odp] [PATCH] platform: Makefile.inc: use `` instead of != for compatibility with older versions of Make
Suggested-by: Maxim Uvarov maxim.uva...@linaro.org
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu
---
platform/Makefile.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index f232daa..f64e37c 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -12,6 +12,6 @@ lib_LTLIBRARIES = $(LIB)/libodp.la
AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
-GIT_DESC !=$(top_srcdir)/scripts/git_hash.sh
+GIT_DESC = `$(top_srcdir)/scripts/git_hash.sh`
AM_CFLAGS += -DGIT_HASH=$(GIT_DESC)
AM_CFLAGS += -DPLATFORM=${with_platform}
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Add ipc.h
On 19 May 2015 at 03:53, Bill Fischofer bill.fischo...@linaro.org wrote:
See comments inline. In general I like this, as it does seem clean and
minimal.
On Mon, May 18, 2015 at 5:03 PM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
As promised, here is my first attempt at a standalone API for IPC - inter
process communication in a shared nothing architecture (message passing
between processes which do not share memory).
Currently all definitions are in the file ipc.h but it is possible to
break out some message/event related definitions (everything from
odp_ipc_sender) in a separate file message.h. This would mimic the
packet_io.h/packet.h separation.
The semantics of message passing is that sending a message to an endpoint
will always look like it succeeds. The appearance of endpoints is
explicitly
notified through user-defined messages specified in the odp_ipc_resolve()
call. Similarly, the disappearance (e.g. death or otherwise lost
connection)
is also explicitly notified through user-defined messages specified in the
odp_ipc_monitor() call. The send call does not fail because the addressed
endpoints has disappeared.
Messages (from endpoint A to endpoint B) are delivered in order. If
message
N sent to an endpoint is delivered, then all messages N have also been
delivered. Message delivery does not guarantee actual processing by the
recipient. End-to-end acknowledgements (using messages) should be used if
this guarantee is important to the user.
IPC endpoints can be seen as interfaces (taps) to an internal reliable
multidrop network where each endpoint has a unique address which is only
valid for the lifetime of the endpoint. I.e. if an endpoint is destroyed
and then recreated (with the same name), the new endpoint will have a
new address (eventually endpoints addresses will have to be recycled but
not for a very long time). Endpoints names do not necessarily have to be
unique.
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
include/odp/api/ipc.h | 261
++
1 file changed, 261 insertions(+)
create mode 100644 include/odp/api/ipc.h
diff --git a/include/odp/api/ipc.h b/include/odp/api/ipc.h
new file mode 100644
index 000..3395a34
--- /dev/null
+++ b/include/odp/api/ipc.h
@@ -0,0 +1,261 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+
+/**
+ * @file
+ *
+ * ODP IPC API
+ */
+
+#ifndef ODP_API_IPC_H_
+#define ODP_API_IPC_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/** @defgroup odp_ipc ODP IPC
+ * @{
+ */
+
+/**
+ * @typedef odp_ipc_t
+ * ODP IPC handle
+ */
+
+/**
+ * @typedef odp_ipc_msg_t
+ * ODP IPC message handle
+ */
+
+
+/**
+ * @def ODP_IPC_ADDR_SIZE
+ * Size of the address of an IPC endpoint
+ */
+
+/**
+ * Create IPC endpoint
+ *
+ * @param name Name of local IPC endpoint
+ * @param pool Pool for incoming messages
Should document the type of the pool being used. Since the object type for
IPC channels is odp_ipc_msg_t, that would imply that this should be a new
pool type (ODP_POOL_IPC or ODP_POOL_IPC_MSG) to buffer these objects.
OK. A message is basically a buffer with some extra metadata (source and
possibly destination addresses and size of message data).
+ *
+ * @return IPC handle on success
+ * @retval ODP_IPC_INVALID on failure and errno set
+ */
+odp_ipc_t odp_ipc_create(const char *name, odp_pool_t pool);
+
+/**
+ * Destroy IPC endpoint
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_destroy(odp_ipc_t ipc);
+
+/**
+ * Set the default input queue for an IPC endpoint
+ *
+ * @param ipc IPC handle
+ * @param queue Queue handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_setdef(odp_ipc_t ipc, odp_queue_t queue);
+
+/**
+ * Remove the default input queue
+ *
+ * Remove (disassociate) the default input queue from an IPC endpoint.
+ * The queue itself is not touched.
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_remdef(odp_ipc_t ipc);
I don't know why this call can return an error. I copied it from
packet_io.h. I think it is reasonable that the ipc handle is valid or
behaviour is undefined (e.g. crash or abort or terminate but not return).
Then there is nothing that can go wrong.
+
+/**
+ * Resolve endpoint by name
+ *
+ * Look up an existing or future endpoint by name.
+ * When the endpoint exists, return the specified message with the
endpoint
+ * as the sender.
+ *
+ * @param ipc IPC handle
+ * @param name Name to resolve
+ * @param msg Message to return
+ */
+void odp_ipc_resolve(odp_ipc_t ipc,
+const char *name,
+
[lng-odp] [PATCH] validation: packet: use PRIu32 instead of %d
Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu --- Note: the new checkpatch does not seem to be happy with PRIu32 put this way (CamelCase and no space in concatenated strings) but I kept it homogeneous with the other printfs test/validation/odp_packet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/test/validation/odp_packet.c b/test/validation/odp_packet.c index a363438..63493ec 100644 --- a/test/validation/odp_packet.c +++ b/test/validation/odp_packet.c @@ -62,7 +62,8 @@ static int packet_testsuite_init(void) if (udat == NULL || udat_size != sizeof(struct udata_struct)) return -1; odp_pool_print(packet_pool); - printf(about to init udata at addr %p size %d\n, udat, udat_size); + printf(about to init udata at addr %p size %PRIu32\n, + udat, udat_size); memcpy(udat, test_packet_udata, sizeof(struct udata_struct)); printf(udata set in test_packet\n); ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCH 1/2 v1] examples: ipsec: tunnel mode support
From: Alexandru Badicioiu alexandru.badici...@linaro.org
v1 - added comment for tunnel DB entry use
Tunnel mode is enabled from the command line using -t argument with
the following format: SrcIP:DstIP:TunnelSrcIP:TunnelDstIP.
SrcIP - cleartext packet source IP
DstIP - cleartext packet destination IP
TunnelSrcIP - tunnel source IP
TunnelDstIP - tunnel destination IP
The outbound packets matching SrcIP:DstIP will be encapsulated
in a TunnelSrcIP:TunnelDstIP IPSec tunnel (AH/ESP/AH+ESP)
if a matching outbound SA is determined (as for transport mode).
For inbound packets each entry in the IPSec cache is matched
for the cleartext addresses, as in the transport mode (SrcIP:DstIP)
and then for the tunnel addresses (TunnelSrcIP:TunnelDstIP)
in case cleartext addresses didn't match. After authentication and
decryption tunneled packets are verified against the tunnel entry
(packets came in from the expected tunnel).
Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
---
example/ipsec/odp_ipsec.c| 105 +++---
example/ipsec/odp_ipsec_cache.c | 31 +-
example/ipsec/odp_ipsec_cache.h |6 ++
example/ipsec/odp_ipsec_sa_db.c | 133 +-
example/ipsec/odp_ipsec_sa_db.h | 57
example/ipsec/odp_ipsec_stream.c | 101
6 files changed, 403 insertions(+), 30 deletions(-)
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index 82ed0cb..3931fef 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -135,13 +135,20 @@ typedef struct {
uint8_t ip_ttl; /** Saved IP TTL value */
int hdr_len;/** Length of IPsec headers */
int trl_len;/** Length of IPsec trailers */
+ uint16_t tun_hdr_offset; /** Offset of tunnel header from
+ buffer start */
uint16_t ah_offset; /** Offset of AH header from buffer start */
uint16_t esp_offset; /** Offset of ESP header from buffer start */
+ /* Input only */
+ uint32_t src_ip; /** SA source IP address */
+ uint32_t dst_ip; /** SA dest IP address */
+
/* Output only */
odp_crypto_op_params_t params; /** Parameters for crypto call */
uint32_t *ah_seq; /** AH sequence number location */
uint32_t *esp_seq; /** ESP sequence number location */
+ uint16_t *tun_hdr_id; /** Tunnel header ID */
} ipsec_ctx_t;
/**
@@ -368,6 +375,7 @@ void ipsec_init_pre(void)
/* Initialize our data bases */
init_sp_db();
init_sa_db();
+ init_tun_db();
init_ipsec_cache();
}
@@ -387,19 +395,27 @@ void ipsec_init_post(crypto_api_mode_e api_mode)
for (entry = sp_db-list; NULL != entry; entry = entry-next) {
sa_db_entry_t *cipher_sa = NULL;
sa_db_entry_t *auth_sa = NULL;
+ tun_db_entry_t *tun;
- if (entry-esp)
+ if (entry-esp) {
cipher_sa = find_sa_db_entry(entry-src_subnet,
entry-dst_subnet,
1);
- if (entry-ah)
+ tun = find_tun_db_entry(cipher_sa-src_ip,
+ cipher_sa-dst_ip);
+ }
+ if (entry-ah) {
auth_sa = find_sa_db_entry(entry-src_subnet,
entry-dst_subnet,
0);
+ tun = find_tun_db_entry(auth_sa-src_ip,
+ auth_sa-dst_ip);
+ }
if (cipher_sa || auth_sa) {
if (create_ipsec_cache_entry(cipher_sa,
auth_sa,
+tun,
api_mode,
entry-input,
completionq,
@@ -672,6 +688,8 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t pkt,
ctx-ipsec.esp_offset = esp ? ((uint8_t *)esp) - buf : 0;
ctx-ipsec.hdr_len = hdr_len;
ctx-ipsec.trl_len = 0;
+ ctx-ipsec.src_ip = entry-src_ip;
+ ctx-ipsec.dst_ip = entry-dst_ip;
/*If authenticating, zero the mutable fields build the request */
if (ah) {
@@ -752,6 +770,23 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt,
trl_len += esp_t-pad_len + sizeof(*esp_t);
}
+ /* We have a tunneled IPv4 packet */
+ if (ip-proto == ODPH_IPV4) {
+ odp_packet_pull_head(pkt, sizeof(*ip) + hdr_len);
+
Re: [lng-odp] [Bug 1449] New: odp_timer_test core dump
I ran into the same issue on our side and after a quick look, this is kind of expected. By setting a period to a time duration smaller than the resolution, the probability is very high that this would happen Example: Get tick = N Time out = Tick + Period = N + 0 = N == New tick == set_abs_timeout = Timeout Tick = Error On a regular Workstation without any specific configuration? I get this issue with period = 5 * resolution but it seems OK afterward. I guess with the right Kernel settings, it shouldn't happen, as long as period = resolution. Nicolas On 04/09/2015 07:17 PM, bugzilla-dae...@bugs.linaro.org wrote: Bug ID1449 https://bugs.linaro.org/show_bug.cgi?id=1449 Summary odp_timer_test core dump Product OpenDataPlane Version 1.0.2 Hardware Other OSLinux StatusUNCONFIRMED Severity normal Priority --- Component Timers Assignee ola.liljed...@linaro.org Reporter mike.hol...@linaro.org CClng-odp@lists.linaro.org ./odp_timer_test -p 5 ... odp_timer_test.c:93:test_abs_timeouts(): [4] period 0 ticks, 5000 ns odp_timer_test.c:96:test_abs_timeouts(): [4] current tick 0 odp_timer_test.c:93:test_abs_timeouts(): [3] period 0 ticks, 5000 ns odp_timer_test.c:96:test_abs_timeouts(): [3] current tick 0 odp_timer_test.c:156:test_abs_timeouts(): [6] timeout, tick 0 odp_timer_test.c:121:test_abs_timeouts(): odp_timer_set_abs() failed: too early odp_timer_test.c:156:test_abs_timeouts(): [4] timeout, tick 0 Aborted (core dumped) -- You are receiving this mail because: * You are on the CC list for the bug. ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [Bug 1449] New: odp_timer_test core dump
On 19 May 2015 at 11:43, Nicolas Morey-Chaisemartin nmo...@kalray.eu wrote: I ran into the same issue on our side and after a quick look, this is kind of expected. By setting a period to a time duration smaller than the resolution, the probability is very high that this would happen Yes period should not be smaller than the resolution, this does not make sense. I misunderstood the problem description earlier (well I didn't study it too carefully). The timer example should have a check that the period is at least one tick. Example: Get tick = N Time out = Tick + Period = N + 0 = N == New tick == set_abs_timeout = Timeout Tick = Error On a regular Workstation without any specific configuration? I get this issue with period = 5 * resolution but it seems OK afterward. I guess with the right Kernel settings, it shouldn't happen, as long as period = resolution. Nicolas On 04/09/2015 07:17 PM, bugzilla-dae...@bugs.linaro.org wrote: Bug ID 1449 https://bugs.linaro.org/show_bug.cgi?id=1449 Summary odp_timer_test core dump Product OpenDataPlane Version 1.0.2 Hardware Other OS Linux Status UNCONFIRMED Severity normal Priority --- Component Timers Assignee ola.liljed...@linaro.org Reporter mike.hol...@linaro.org CC lng-odp@lists.linaro.org ./odp_timer_test -p 5 ... odp_timer_test.c:93:test_abs_timeouts(): [4] period 0 ticks, 5000 ns odp_timer_test.c:96:test_abs_timeouts(): [4] current tick 0 odp_timer_test.c:93:test_abs_timeouts(): [3] period 0 ticks, 5000 ns odp_timer_test.c:96:test_abs_timeouts(): [3] current tick 0 odp_timer_test.c:156:test_abs_timeouts(): [6] timeout, tick 0 odp_timer_test.c:121:test_abs_timeouts(): odp_timer_set_abs() failed: too early odp_timer_test.c:156:test_abs_timeouts(): [4] timeout, tick 0 Aborted (core dumped) -- You are receiving this mail because: - You are on the CC list for the bug. ___ lng-odp mailing listlng-odp@lists.linaro.orghttps://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [Bug 1449] odp_timer_test core dump
https://bugs.linaro.org/show_bug.cgi?id=1449 --- Comment #4 from Ola Liljedahl ola.liljed...@linaro.org --- I see now that the reason for the abort and core dump is that the timeout period is smaller than the tick (the resolution of the timer). This does not make sense and is also not supported by the timer example which aborts when the timer API returns timeout too early. The solution is to add a check to the timer example to ensure that the user-specified configuration is correct. However I don't know if we can know all the restrictions in advance, I suspect we might detect more invalid configurations in the future. -- You are receiving this mail because: You are on the CC list for the bug.___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [Bug 1449] odp_timer_test core dump
https://bugs.linaro.org/show_bug.cgi?id=1449 --- Comment #5 from Ola Liljedahl ola.liljed...@linaro.org --- I am testing with periods 1x-2x the length of the timer resolution and still get intermittent too early failures. I assume this is caused by the non-determinism of Linux, the ODP threads may not execute immediately (e.g. the threads are swapped out and Linux running something else on the CPU's). This means that the timer example needs to be more robust. It cannot expect that it will have full control over the CPU and run immediately a timer expired and the timeout is delivered. Too early errors from odp_timer_set() should be handled gracefully and not cause an abort. -- You are receiving this mail because: You are on the CC list for the bug.___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] [PATCHv2] helpers: fix udp checksum computation
From: Alexandru Badicioiu alexandru.badici...@linaro.org
Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
---
v2: fix csum in odp generatior.
example/generator/odp_generator.c | 2 +-
helper/include/odp/helper/udp.h | 37 +
2 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/example/generator/odp_generator.c
b/example/generator/odp_generator.c
index 8ae5b29..8c224f3 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -238,7 +238,7 @@ static odp_packet_t pack_udp_pkt(odp_pool_t pool)
udp-dst_port = 0;
udp-length = odp_cpu_to_be_16(args-appl.payload + ODPH_UDPHDR_LEN);
udp-chksum = 0;
- udp-chksum = odp_cpu_to_be_16(odph_ipv4_udp_chksum(pkt));
+ udp-chksum = odph_ipv4_udp_chksum(pkt);
return pkt;
}
diff --git a/helper/include/odp/helper/udp.h b/helper/include/odp/helper/udp.h
index 866145a..06c439b 100644
--- a/helper/include/odp/helper/udp.h
+++ b/helper/include/odp/helper/udp.h
@@ -38,15 +38,6 @@ typedef struct ODP_PACKED {
uint16be_t chksum; /** UDP header and data checksum (0 if not used)*/
} odph_udphdr_t;
-/** UDP pseudo header */
-typedef struct ODPH_PACKET {
- uint32be_t src_addr; /** Source addr */
- uint32be_t dst_addr; /** Destination addr */
- uint8_t pad; /** pad byte */
- uint8_t proto; /** UDP protocol */
- uint16be_t length; /** data length */
-} odph_udpphdr_t;
-
/**
* UDP checksum
*
@@ -58,10 +49,10 @@ typedef struct ODPH_PACKET {
static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
{
uint32_t sum = 0;
- odph_udpphdr_t phdr;
odph_udphdr_t *udph;
odph_ipv4hdr_t *iph;
uint16_t udplen;
+ uint8_t *buf;
if (!odp_packet_l3_offset(pkt))
return 0;
@@ -73,24 +64,22 @@ static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t
pkt)
udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
udplen = odp_be_to_cpu_16(udph-length);
- /* the source ip */
- phdr.src_addr = iph-src_addr;
- /* the dest ip */
- phdr.dst_addr = iph-dst_addr;
- /* proto */
- phdr.pad = 0;
- phdr.proto = ODPH_IPPROTO_UDP;
- /* the length */
- phdr.length = udph-length;
-
- /* calc UDP pseudo header chksum */
- sum = (__odp_force uint32_t) odp_chksum(phdr, sizeof(odph_udpphdr_t));
- /* calc udp header and data chksum */
- sum += (__odp_force uint32_t) odp_chksum(udph, udplen);
+ /* 32-bit sum of all 16-bit words covered by UDP chksum */
+ sum = (iph-src_addr 0x) + (iph-src_addr 16) +
+ (iph-dst_addr 0x) + (iph-dst_addr 16) +
+ (uint16_t)iph-proto + udplen;
+ for (buf = (uint8_t *)udph; udplen 1; udplen -= 2) {
+ sum += ((*buf 8) + *(buf + 1));
+ buf += 2;
+ }
/* Fold sum to 16 bits: add carrier to result */
while (sum 16)
sum = (sum 0x) + (sum 16);
+
+ /* 1's complement */
+ sum = ~sum;
+
/* set computation result */
sum = (sum == 0x0) ? 0x : sum;
--
1.9.1
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [PATCH] validation: packet: use PRIu32 instead of %d
Actually those printf() calls are vestigial from debugging and should be removed. They were not intended to be part of the final tests. On Tue, May 19, 2015 at 3:32 AM, Nicolas Morey-Chaisemartin nmo...@kalray.eu wrote: Signed-off-by: Nicolas Morey-Chaisemartin nmo...@kalray.eu --- Note: the new checkpatch does not seem to be happy with PRIu32 put this way (CamelCase and no space in concatenated strings) but I kept it homogeneous with the other printfs test/validation/odp_packet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/test/validation/odp_packet.c b/test/validation/odp_packet.c index a363438..63493ec 100644 --- a/test/validation/odp_packet.c +++ b/test/validation/odp_packet.c @@ -62,7 +62,8 @@ static int packet_testsuite_init(void) if (udat == NULL || udat_size != sizeof(struct udata_struct)) return -1; odp_pool_print(packet_pool); - printf(about to init udata at addr %p size %d\n, udat, udat_size); + printf(about to init udata at addr %p size %PRIu32\n, + udat, udat_size); memcpy(udat, test_packet_udata, sizeof(struct udata_struct)); printf(udata set in test_packet\n); ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] odp timer unit test case question
On Wed, May 20, 2015 at 12:25:12AM +0200, Ola Liljedahl wrote:
On 19 May 2015 at 15:34, Jacob, Jerin jerin.ja...@caviumnetworks.com wrote:
Ola,
Is there any specific reason for following check in timer validation test ?
pa
diff --git a/test/validation/odp_timer.c b/test/validation/odp_timer.c
index 554b353..724026e 100644
--- a/test/validation/odp_timer.c
+++ b/test/validation/odp_timer.c
@@ -260,7 +260,7 @@ static void handle_tmo(odp_event_t ev, bool stale,
uint64_t prev_tick)
if (ttp != NULL) {
/* Internal error */
- CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
+--CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
ttp-ev = ev;
}
}
AFAIU, I should be CU_ASSERT_FATAL(ttp-ev != ODP_EVENT_INVALID) as
tt[i].ev = odp_timeout_to_event(odp_timeout_alloc(tbp)) specified while
preparing all timers.
Yes the timers are still inactive and the timeout event is stored in
the 'ev' member.
handle_timeout() is called for received timeouts (timer has expired).
In that case, the corresponding 'ev' member should not contain any
timeout event.
Am I missing something in the timer specification ?
Or the timer specification is missing something?
odp_timer_set_abs(tt[i].tim, tck, tt[i].ev); (line 309) is supposed
to grab the timeout event (on success) and clear the variable (write
ODP_TIMEOUT_INVALID), that's why the timeout is passed by reference
(tt[i].ev).
Possibly this is not specified clearly enough in timer.h:
* @param[in,out] tmo_ev Reference to an event variable that points to
* timeout event or NULL to reuse the existing timeout event. Any existing
* timeout event that is replaced by a successful set operation will be
* returned here.
The new timeout event is read from *tmo_ev. The old timeout event (if
timer was active) or ODP_TIMEOUT_INVALID (if timer was inactive) is
stored in *tmo_ev. I hope this is at least clear in the reference
implementation.
We are on same page, except the last notes
IMO, linux generic timer implementation details leaked into creating the test
case.
AFAIU, *tmo_ev should have the event that used for _arming_ the timer so
that application can do some look up after receiving event through queue or
something similar..
What is the point of providing ODP_TIMEOUT_INVALID to application back, What
the
use of it for the application.
IMO, two way we can come to a conclusion for this issue.
1) Remove CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID) in handle_tmo function
in unit testcase
2) Or some reason, If application wants ODP_TIMEOUT_INVALID(for inactive case)
in *tmo_ev
lets update the specification so that it will clear for odp implementer
any thought from application perspective ?
Thanks,
Jerin.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] odp timer unit test case question
Ola,
Is there any specific reason for following check in timer validation test ?
diff --git a/test/validation/odp_timer.c b/test/validation/odp_timer.c
index 554b353..724026e 100644
--- a/test/validation/odp_timer.c
+++ b/test/validation/odp_timer.c
@@ -260,7 +260,7 @@ static void handle_tmo(odp_event_t ev, bool stale, uint64_t
prev_tick)
if (ttp != NULL) {
/* Internal error */
- CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
+--CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
ttp-ev = ev;
}
}
AFAIU, I should be CU_ASSERT_FATAL(ttp-ev != ODP_EVENT_INVALID) as
tt[i].ev = odp_timeout_to_event(odp_timeout_alloc(tbp)) specified while
preparing all timers.
Am I missing something in the timer specification ?
Thanks,
Jerin.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Add ipc.h
On Tue, May 19, 2015 at 1:03 AM, Ola Liljedahl ola.liljed...@linaro.org wrote:
As promised, here is my first attempt at a standalone API for IPC - inter
process communication in a shared nothing architecture (message passing
between processes which do not share memory).
Currently all definitions are in the file ipc.h but it is possible to
break out some message/event related definitions (everything from
odp_ipc_sender) in a separate file message.h. This would mimic the
packet_io.h/packet.h separation.
The semantics of message passing is that sending a message to an endpoint
will always look like it succeeds. The appearance of endpoints is explicitly
notified through user-defined messages specified in the odp_ipc_resolve()
call. Similarly, the disappearance (e.g. death or otherwise lost connection)
is also explicitly notified through user-defined messages specified in the
odp_ipc_monitor() call. The send call does not fail because the addressed
endpoints has disappeared.
Messages (from endpoint A to endpoint B) are delivered in order. If message
N sent to an endpoint is delivered, then all messages N have also been
delivered. Message delivery does not guarantee actual processing by the
recipient. End-to-end acknowledgements (using messages) should be used if
this guarantee is important to the user.
IPC endpoints can be seen as interfaces (taps) to an internal reliable
multidrop network where each endpoint has a unique address which is only
valid for the lifetime of the endpoint. I.e. if an endpoint is destroyed
and then recreated (with the same name), the new endpoint will have a
new address (eventually endpoints addresses will have to be recycled but
not for a very long time). Endpoints names do not necessarily have to be
unique.
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
include/odp/api/ipc.h | 261
++
1 file changed, 261 insertions(+)
create mode 100644 include/odp/api/ipc.h
diff --git a/include/odp/api/ipc.h b/include/odp/api/ipc.h
new file mode 100644
index 000..3395a34
--- /dev/null
+++ b/include/odp/api/ipc.h
@@ -0,0 +1,261 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+
+/**
+ * @file
+ *
+ * ODP IPC API
+ */
+
+#ifndef ODP_API_IPC_H_
+#define ODP_API_IPC_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/** @defgroup odp_ipc ODP IPC
+ * @{
+ */
+
+/**
+ * @typedef odp_ipc_t
+ * ODP IPC handle
+ */
+
+/**
+ * @typedef odp_ipc_msg_t
+ * ODP IPC message handle
+ */
+
+
+/**
+ * @def ODP_IPC_ADDR_SIZE
+ * Size of the address of an IPC endpoint
+ */
+
+/**
+ * Create IPC endpoint
+ *
+ * @param name Name of local IPC endpoint
+ * @param pool Pool for incoming messages
+ *
+ * @return IPC handle on success
+ * @retval ODP_IPC_INVALID on failure and errno set
+ */
+odp_ipc_t odp_ipc_create(const char *name, odp_pool_t pool);
+
+/**
+ * Destroy IPC endpoint
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_destroy(odp_ipc_t ipc);
+
+/**
+ * Set the default input queue for an IPC endpoint
+ *
+ * @param ipc IPC handle
+ * @param queue Queue handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_setdef(odp_ipc_t ipc, odp_queue_t queue);
+
+/**
+ * Remove the default input queue
+ *
+ * Remove (disassociate) the default input queue from an IPC endpoint.
+ * The queue itself is not touched.
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_remdef(odp_ipc_t ipc);
+
+/**
+ * Resolve endpoint by name
+ *
+ * Look up an existing or future endpoint by name.
+ * When the endpoint exists, return the specified message with the endpoint
+ * as the sender.
+ *
+ * @param ipc IPC handle
+ * @param name Name to resolve
+ * @param msg Message to return
+ */
+void odp_ipc_resolve(odp_ipc_t ipc,
+const char *name,
+odp_ipc_msg_t msg);
How does this take into account the 'address' of the endpoint? Will
the name include the search path, something like
domain_name/endpoint_name? If so, should there be an API for
creating a communication channel with domain_X?
+
+/**
+ * Monitor endpoint
+ *
+ * Monitor an existing (potentially already dead) endpoint.
+ * When the endpoint is dead, return the specified message with the endpoint
+ * as the sender.
+ *
+ * Unrecognized or invalid endpoint addresses are treated as dead endpoints.
+ *
+ * @param ipc IPC handle
+ * @param addr Address of monitored endpoint
+ * @param msg Message to return
+ */
+void odp_ipc_monitor(odp_ipc_t ipc,
+const uint8_t addr[ODP_IPC_ADDR_SIZE],
+
Re: [lng-odp] [RFC] Add ipc.h
On 19 May 2015 at 16:19, Ciprian Barbu ciprian.ba...@linaro.org wrote:
On Tue, May 19, 2015 at 1:03 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
As promised, here is my first attempt at a standalone API for IPC - inter
process communication in a shared nothing architecture (message passing
between processes which do not share memory).
Currently all definitions are in the file ipc.h but it is possible to
break out some message/event related definitions (everything from
odp_ipc_sender) in a separate file message.h. This would mimic the
packet_io.h/packet.h separation.
The semantics of message passing is that sending a message to an endpoint
will always look like it succeeds. The appearance of endpoints is explicitly
notified through user-defined messages specified in the odp_ipc_resolve()
call. Similarly, the disappearance (e.g. death or otherwise lost connection)
is also explicitly notified through user-defined messages specified in the
odp_ipc_monitor() call. The send call does not fail because the addressed
endpoints has disappeared.
Messages (from endpoint A to endpoint B) are delivered in order. If message
N sent to an endpoint is delivered, then all messages N have also been
delivered. Message delivery does not guarantee actual processing by the
recipient. End-to-end acknowledgements (using messages) should be used if
this guarantee is important to the user.
IPC endpoints can be seen as interfaces (taps) to an internal reliable
multidrop network where each endpoint has a unique address which is only
valid for the lifetime of the endpoint. I.e. if an endpoint is destroyed
and then recreated (with the same name), the new endpoint will have a
new address (eventually endpoints addresses will have to be recycled but
not for a very long time). Endpoints names do not necessarily have to be
unique.
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
include/odp/api/ipc.h | 261
++
1 file changed, 261 insertions(+)
create mode 100644 include/odp/api/ipc.h
diff --git a/include/odp/api/ipc.h b/include/odp/api/ipc.h
new file mode 100644
index 000..3395a34
--- /dev/null
+++ b/include/odp/api/ipc.h
@@ -0,0 +1,261 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+
+/**
+ * @file
+ *
+ * ODP IPC API
+ */
+
+#ifndef ODP_API_IPC_H_
+#define ODP_API_IPC_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/** @defgroup odp_ipc ODP IPC
+ * @{
+ */
+
+/**
+ * @typedef odp_ipc_t
+ * ODP IPC handle
+ */
+
+/**
+ * @typedef odp_ipc_msg_t
+ * ODP IPC message handle
+ */
+
+
+/**
+ * @def ODP_IPC_ADDR_SIZE
+ * Size of the address of an IPC endpoint
+ */
+
+/**
+ * Create IPC endpoint
+ *
+ * @param name Name of local IPC endpoint
+ * @param pool Pool for incoming messages
+ *
+ * @return IPC handle on success
+ * @retval ODP_IPC_INVALID on failure and errno set
+ */
+odp_ipc_t odp_ipc_create(const char *name, odp_pool_t pool);
+
+/**
+ * Destroy IPC endpoint
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_destroy(odp_ipc_t ipc);
+
+/**
+ * Set the default input queue for an IPC endpoint
+ *
+ * @param ipc IPC handle
+ * @param queue Queue handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_setdef(odp_ipc_t ipc, odp_queue_t queue);
+
+/**
+ * Remove the default input queue
+ *
+ * Remove (disassociate) the default input queue from an IPC endpoint.
+ * The queue itself is not touched.
+ *
+ * @param ipc IPC handle
+ *
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_ipc_inq_remdef(odp_ipc_t ipc);
+
+/**
+ * Resolve endpoint by name
+ *
+ * Look up an existing or future endpoint by name.
+ * When the endpoint exists, return the specified message with the endpoint
+ * as the sender.
+ *
+ * @param ipc IPC handle
+ * @param name Name to resolve
+ * @param msg Message to return
+ */
+void odp_ipc_resolve(odp_ipc_t ipc,
+const char *name,
+odp_ipc_msg_t msg);
How does this take into account the 'address' of the endpoint? Will
the name include the search path, something like
domain_name/endpoint_name? If so, should there be an API for
creating a communication channel with domain_X?
The semantics of names and any network topology is not defined and not
really important to the endpoints themselves (the applications).
A specific IPC implementation can support some form of structured or
partitioned network topology without changes to the IPC client-side
API (I think). To compare, in OSE, adding support for link handlers
and distributed systems did not change the original API designed for
local communication.
+
[lng-odp] UberConference Reminder
UberConference Reminder___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] UberConference Reminder
Hi all, Your conference is about to begin! Weekly ODP Design Discussion Call May 19, 2015 at 8:00AM MST Just to be sure, the conference is canceled this week, right? Thanks, ben ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [PATCHv5 0/4] IPC
It seems like there is still a discussion floating on patch 2, about including helper code in the linux-generic implementation. I will have a look at the other patches, but I think you need to solve the issue with the ring code before marking the patchset as ready to be merged. On Mon, May 18, 2015 at 3:55 PM, Maxim Uvarov maxim.uva...@linaro.org wrote: If no more comments here can all reviewers add their review-by to that patchset? So that I can merge that patches. Thank you, Maxim. On 05/08/2015 12:57, Maxim Uvarov wrote: v5: - accounted all comments for previous v4 review. - do not modify any api function, everything is done inside linux-generic. Please review that version. Thank you, Maxim. Maxim Uvarov (4): linux-generic: zero params for pool create api ipc: update ring with shm proc argument linux-generic: add ipc pktio support ipc: example app configure.ac | 1 + example/Makefile.am| 2 +- example/ipc/.gitignore | 1 + example/ipc/Makefile.am| 7 + example/ipc/odp_ipc.c | 427 +++ helper/include/odp/helper/ring.h | 7 +- helper/ring.c | 12 +- platform/linux-generic/Makefile.am | 3 + .../linux-generic/include/odp_buffer_internal.h| 3 + .../linux-generic/include/odp_packet_io_internal.h | 16 + .../include/odp_packet_io_ipc_internal.h | 48 ++ platform/linux-generic/include/odp_shm_internal.h | 22 + platform/linux-generic/odp_packet_io.c | 19 +- platform/linux-generic/odp_packet_io_ipc.c | 603 + platform/linux-generic/odp_pool.c | 23 +- platform/linux-generic/odp_schedule.c | 1 + platform/linux-generic/odp_shared_memory.c | 10 +- test/validation/odp_queue.c| 1 + 18 files changed, 1193 insertions(+), 13 deletions(-) create mode 100644 example/ipc/.gitignore create mode 100644 example/ipc/Makefile.am create mode 100644 example/ipc/odp_ipc.c create mode 100644 platform/linux-generic/include/odp_packet_io_ipc_internal.h create mode 100644 platform/linux-generic/include/odp_shm_internal.h create mode 100644 platform/linux-generic/odp_packet_io_ipc.c ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp ___ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [PATCHv2 2/2] validation: init tests using common main
On 2015-05-07 18:09, Mike Holmes wrote:
On 5 May 2015 at 12:31, Christophe Milard christophe.mil...@linaro.org
wrote:
This is the one I'd like to be reviewed... (v2) sorry for the confusion.
On 27 April 2015 at 17:54, Christophe Milard christophe.mil...@linaro.org
wrote:
The 3 init tests (init, abort,log) now links with
common/odp_cunit_common,
as other tests. In main, ODP init is now performed via weak functions
which are overloaded (to do nothing) by the 3 init tests.
Signed-off-by: Christophe Milard christophe.mil...@linaro.org
Reviewed-by: Mike Holmes mike.hol...@linaro.org
the review was not sent to the lng-odp list.
Can this be applied now?
Cheers,
Christophe
---
test/validation/Makefile.am | 6 ++---
test/validation/common/odp_cunit_common.c | 45
+++
test/validation/init/odp_init.c | 34 +--
test/validation/init/odp_init_abort.c | 35 ++--
test/validation/init/odp_init_log.c | 35 ++--
test/validation/odp_crypto.c | 20 ++
test/validation/odp_synchronizers.c | 9 +++
7 files changed, 95 insertions(+), 89 deletions(-)
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index 7ea86c4..ba622c3 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -48,9 +48,9 @@ dist_odp_classification_SOURCES =
classification/odp_classification_tests.c \
odp_crypto_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/crypto
dist_odp_crypto_SOURCES = crypto/odp_crypto_test_inp.c \
odp_crypto.c $(ODP_CU_COMMON)
-dist_odp_init_SOURCES = init/odp_init.c
-dist_odp_init_abort_SOURCES = init/odp_init_abort.c
-dist_odp_init_log_SOURCES = init/odp_init_log.c
+dist_odp_init_SOURCES = init/odp_init.c $(ODP_CU_COMMON)
+dist_odp_init_abort_SOURCES = init/odp_init_abort.c $(ODP_CU_COMMON)
+dist_odp_init_log_SOURCES = init/odp_init_log.c $(ODP_CU_COMMON)
dist_odp_queue_SOURCES = odp_queue.c $(ODP_CU_COMMON)
dist_odp_random_SOURCES = odp_random.c $(ODP_CU_COMMON)
dist_odp_schedule_SOURCES = odp_schedule.c $(ODP_CU_COMMON)
diff --git a/test/validation/common/odp_cunit_common.c
b/test/validation/common/odp_cunit_common.c
index 2af4410..eac2d81 100644
--- a/test/validation/common/odp_cunit_common.c
+++ b/test/validation/common/odp_cunit_common.c
@@ -39,13 +39,32 @@ int odp_cunit_thread_exit(pthrd_arg *arg)
return 0;
}
-__attribute__((__weak__)) int tests_global_init(void)
+ODP_WEAK_SYMBOL int tests_global_init(void)
{
+ if (0 != odp_init_global(NULL, NULL)) {
+ fprintf(stderr, error: odp_init_global() failed.\n);
+ return -1;
+ }
+ if (0 != odp_init_local()) {
+ fprintf(stderr, error: odp_init_local() failed.\n);
+ return -1;
+ }
+
return 0;
}
-__attribute__((__weak__)) int tests_global_term(void)
+ODP_WEAK_SYMBOL int tests_global_term(void)
{
+ if (0 != odp_term_local()) {
+ fprintf(stderr, error: odp_term_local() failed.\n);
+ return -1;
+ }
+
+ if (0 != odp_term_global()) {
+ fprintf(stderr, error: odp_term_global() failed.\n);
+ return -1;
+ }
+
return 0;
}
@@ -56,18 +75,8 @@ int main(void)
printf(\tODP API version: %s\n, odp_version_api_str());
printf(\tODP implementation version: %s\n,
odp_version_impl_str());
- if (0 != odp_init_global(NULL, NULL)) {
- fprintf(stderr, error: odp_init_global() failed.\n);
+ if (0 != tests_global_init())
return -1;
- }
- if (0 != odp_init_local()) {
- fprintf(stderr, error: odp_init_local() failed.\n);
- return -1;
- }
-
- ret = tests_global_init();
- if (ret)
- return ret;
CU_set_error_action(CUEA_ABORT);
@@ -83,15 +92,5 @@ int main(void)
if (0 != tests_global_term())
return -1;
- if (0 != odp_term_local()) {
- fprintf(stderr, error: odp_term_local() failed.\n);
- return -1;
- }
-
- if (0 != odp_term_global()) {
- fprintf(stderr, error: odp_term_global() failed.\n);
- return -1;
- }
-
return (ret) ? -1 : 0;
}
diff --git a/test/validation/init/odp_init.c
b/test/validation/init/odp_init.c
index 82f8849..3bbec11 100644
--- a/test/validation/init/odp_init.c
+++ b/test/validation/init/odp_init.c
@@ -7,10 +7,23 @@
#include stdarg.h
#include odp.h
#include CUnit/Basic.h
+#include odp_cunit_common.h
#define DEFAULT_MSG_POOL_SIZE (4*1024*1024)
#define DEFAULT_MSG_SIZE
Re: [lng-odp] [RFC] Add ipc.h
Hi Ola,
Thanks for sharing this. We are also looking at IPC at Kalray, where our
ODP model is multi-process, shared-nothing, architecture.
From our point of view, the main requirements for IPC would be:
- use it to communicate between different address spaces (AS), and as
such our messages should be bigger than just a pointer to a shared mem area
- use it for control/data planes signaling but also to exchange
packets to be allowed to build packets processing pipelines
- IPC ops should be mapped to our NoC HW as much as possible,
especially for send/recv operations
From your proposal, it seems to me that what you proposed is more like
an application messaging bus such as d-bus (especially the deferred
lookup() and monitor()), with a centralized rendez-vous point for
resource management. It is certainly useful, especially for control/data
plane signaling, but I would like to have a more low-level IPC
mechanism, on top of which we could build this sort of messaging bus.
For this kind of lower-level mechanism I think pktio might be a good
match. But in that case you need to be able to identify the endpoints.
What I proposed in precedent thread, was to use a hierarchical device
naming:
- /dev/device for real devices
- /ipc/identifier for IPC
What I had in mind so far for our platform was to used {AS identifier +
pool name in the AS} as IPC identifier, which would avoid the need of a
centralized rendez-vous point.
Another slightly different subject is that we would like to extend pktio
(but it is a common requirement for IPC) to be able to open pktio for
read-only, write-only or read-write operations. This is because opening
communications on our HW allocate HW resources for each configured RX
(you need DMA endpoints to be configured). Being able to open write-only
pktio help to save those resources, and would make sense even in the
standard pktio.
How could it look like? Here are some examples:
- to open a read-only pktio in AS0:
odp_pool_t local_pool = odp_pool_create(AS0_pool, ...);
odp_pktio_open(/ipc/local, local_pool);
Notes: /ipc/local identifies a local, read-only ipc endpoints.
- to open a write-only pktio in AS1 to send data to AS0:
odp_pktio_open(/ipc/AS0/AS0_pool, NULL);
Notes: /ipc/AS0/AS0_pool identifies a remote endpoints for
writing: AS0 identifies the address space, whereas AS0_pool
identifies the packet pool in AS0 address space. The fact that we do not
associate any default pool with pktio means it is write-only.
- to open a read-write pktio between AS0 and AS1 in AS1:
odp_pool_t local_pool = odp_pool_create(AS1_pool, ...);
odp_pktio_open(/AS0/AS0_pool, local_pool);
Thanks,
ben
On 05/19/2015 12:03 AM, Ola Liljedahl wrote:
As promised, here is my first attempt at a standalone API for IPC - inter
process communication in a shared nothing architecture (message passing
between processes which do not share memory).
Currently all definitions are in the file ipc.h but it is possible to
break out some message/event related definitions (everything from
odp_ipc_sender) in a separate file message.h. This would mimic the
packet_io.h/packet.h separation.
The semantics of message passing is that sending a message to an endpoint
will always look like it succeeds. The appearance of endpoints is explicitly
notified through user-defined messages specified in the odp_ipc_resolve()
call. Similarly, the disappearance (e.g. death or otherwise lost connection)
is also explicitly notified through user-defined messages specified in the
odp_ipc_monitor() call. The send call does not fail because the addressed
endpoints has disappeared.
Messages (from endpoint A to endpoint B) are delivered in order. If message
N sent to an endpoint is delivered, then all messages N have also been
delivered. Message delivery does not guarantee actual processing by the
recipient. End-to-end acknowledgements (using messages) should be used if
this guarantee is important to the user.
IPC endpoints can be seen as interfaces (taps) to an internal reliable
multidrop network where each endpoint has a unique address which is only
valid for the lifetime of the endpoint. I.e. if an endpoint is destroyed
and then recreated (with the same name), the new endpoint will have a
new address (eventually endpoints addresses will have to be recycled but
not for a very long time). Endpoints names do not necessarily have to be
unique.
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
include/odp/api/ipc.h | 261 ++
1 file changed, 261 insertions(+)
create mode 100644 include/odp/api/ipc.h
diff --git a/include/odp/api/ipc.h b/include/odp/api/ipc.h
new file mode 100644
index 000..3395a34
--- /dev/null
+++ b/include/odp/api/ipc.h
@@ -0,0 +1,261 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ *
Re: [lng-odp] odp timer unit test case question
On 19 May 2015 at 15:34, Jacob, Jerin jerin.ja...@caviumnetworks.com wrote:
Ola,
Is there any specific reason for following check in timer validation test ?
pa
diff --git a/test/validation/odp_timer.c b/test/validation/odp_timer.c
index 554b353..724026e 100644
--- a/test/validation/odp_timer.c
+++ b/test/validation/odp_timer.c
@@ -260,7 +260,7 @@ static void handle_tmo(odp_event_t ev, bool stale,
uint64_t prev_tick)
if (ttp != NULL) {
/* Internal error */
- CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
+--CU_ASSERT_FATAL(ttp-ev == ODP_EVENT_INVALID);
ttp-ev = ev;
}
}
AFAIU, I should be CU_ASSERT_FATAL(ttp-ev != ODP_EVENT_INVALID) as
tt[i].ev = odp_timeout_to_event(odp_timeout_alloc(tbp)) specified while
preparing all timers.
Yes the timers are still inactive and the timeout event is stored in
the 'ev' member.
handle_timeout() is called for received timeouts (timer has expired).
In that case, the corresponding 'ev' member should not contain any
timeout event.
Am I missing something in the timer specification ?
Or the timer specification is missing something?
odp_timer_set_abs(tt[i].tim, tck, tt[i].ev); (line 309) is supposed
to grab the timeout event (on success) and clear the variable (write
ODP_TIMEOUT_INVALID), that's why the timeout is passed by reference
(tt[i].ev).
Possibly this is not specified clearly enough in timer.h:
* @param[in,out] tmo_ev Reference to an event variable that points to
* timeout event or NULL to reuse the existing timeout event. Any existing
* timeout event that is replaced by a successful set operation will be
* returned here.
The new timeout event is read from *tmo_ev. The old timeout event (if
timer was active) or ODP_TIMEOUT_INVALID (if timer was inactive) is
stored in *tmo_ev. I hope this is at least clear in the reference
implementation.
Thanks,
Jerin.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] [RFC] Add ipc.h
On 19 May 2015 at 19:04, Benoît Ganne bga...@kalray.eu wrote:
Hi Ola,
Thanks for sharing this. We are also looking at IPC at Kalray, where our ODP
model is multi-process, shared-nothing, architecture.
From our point of view, the main requirements for IPC would be:
- use it to communicate between different address spaces (AS), and as such
our messages should be bigger than just a pointer to a shared mem area
I agree. The data must be contained in the message.
- use it for control/data planes signaling but also to exchange packets to
be allowed to build packets processing pipelines
Control/data plane signaling must be reliable (per the definition in
my RFC). But do you have the same requirements for packet transfer
between pipeline stages (on different cores)? Or it just happens to be
reliable on your hardware? Is reliability (guaranteed delivery) an
inherent requirement for pipelined packet processing? (this would be
contrary to my experience).
Also couldn't you use ODP queues as the abstraction for transferring
packets between cores/pipeline stages? Per your pktio proposal below,
if you connect input and output queues to your ipc pktio instances,
applications can just enqueue and dequeue packets from these queues
and that will cause packets to be transferred between pipeline stages
(on different cores/AS's). This use case does not want or need the
ability to specify the destination address for each individual send
operation and this would likely just add overhead to a performance
critical operation.
Queues also support enqueueing of all types of events while my
proposed IPC mechanism only supports a new message event type.
- IPC ops should be mapped to our NoC HW as much as possible, especially
for send/recv operations
Is there anything in the proposed API that would limit your
implementation freedom?
From your proposal, it seems to me that what you proposed is more like an
application messaging bus such as d-bus (especially the deferred lookup()
and monitor()),
Perhaps d-bus can be used as the implementation, that could save me
some work. But the IPC mechanism is extremely inspired by the OSE
(application) message passing mechanism (there was a borked attempt to
adapt OSE message passing to passing packets between pipeline stages
which showed why message passing and packet passing should not be
mixed).
with a centralized rendez-vous point for resource
management. It is certainly useful, especially for control/data plane
signaling, but I would like to have a more low-level IPC mechanism, on top
of which we could build this sort of messaging bus.
I proposed an API for the functionality I need. How each platform
implements it is up to them. Why would you want to expose a lower
level API? How would such an API look like and how would you implement
the functionality in my proposal? Would the low level API be
independent of the underlying platform?
For this kind of lower-level mechanism I think pktio might be a good match.
My prototyping started out by tweaking the linux-generic packet_io
implementation. By specifying a special pktio interface name, the IPC
endpoint would be created. An Ethernet-like packet format (48-bit
destination and source address, 32 bit message type) was be used for
messages. The packet.h API would be used for accessing and
manipulating messages (which are of the packet event type). This is
still a potential implementation for Linux generic but a little bit
too close the packet semantics (unreliable transfer, segmented buffers
etc) for my intended use case. But messages are not packets and
reliable transfer is important.
But in that case you need to be able to identify the endpoints. What I
proposed in precedent thread, was to use a hierarchical device naming:
- /dev/device for real devices
- /ipc/identifier for IPC
What I had in mind so far for our platform was to used {AS identifier + pool
name in the AS} as IPC identifier, which would avoid the need of a
centralized rendez-vous point.
The semantics of the IPC endpoint names are not defined in my
proposal. I think it is a mistake to impose meaning on the names. I
expect names to identify applications but an IPC name can identify
anything. Example and real applications will likely impose some kind
of structure on and meaning to names. But it is probably not a good
idea that the platform imposes meaning to IPC names (e.g. names
represent SoC topology), I can imagine how this will complicate
portability. pktio names however are already platform specific.
Also I don't envision any (active) rendez-vous point, it's just a
global shared table in my implementation for linux-generic. This is
needed since names are user-defined and arbitrary.
Another slightly different subject is that we would like to extend pktio
(but it is a common requirement for IPC) to be able to open pktio for
read-only, write-only or read-write operations. This is because opening
communications on our HW allocate HW
