date:20160417

Re: [lng-odp] [API-NEXT PATCH v2 1/2] helper: table: add impl of cuckoo hash table

2016-04-17 Thread Jia Ru

According to the comments, I modified the following aspects:
1) replaced ring with odp_queue,
2) moved cuckoo hash table into helper, and implememted odph_table api
(helper/table.h)

> -Original Message-
> From: Ru Jia [mailto:ji...@ict.ac.cn]
> Sent: Monday, April 18, 2016 12:53 PM
> To: lng-odp@lists.linaro.org
> Cc: xnhp0...@icloud.com; Ru Jia
> Subject: [API-NEXT PATCH v2 1/2] helper: table: add impl of cuckoo hash
table
> 
> Signed-off-by: Ru Jia 
> ---
>  helper/Makefile.am|   6 +-
>  helper/cuckootable.c  | 746
> ++
>  helper/odph_cuckootable.h |  82 +
>  3 files changed, 832 insertions(+), 2 deletions(-)  create mode 100644
> helper/cuckootable.c  create mode 100644 helper/odph_cuckootable.h
> 
> diff --git a/helper/Makefile.am b/helper/Makefile.am index
8a86eb7..1763b99
> 100644
> --- a/helper/Makefile.am
> +++ b/helper/Makefile.am
> @@ -27,13 +27,15 @@ noinst_HEADERS = \
>$(srcdir)/odph_debug.h \
>$(srcdir)/odph_hashtable.h \
>$(srcdir)/odph_lineartable.h \
> -  $(srcdir)/odph_list_internal.h
> +  $(srcdir)/odph_list_internal.h \
> +  $(srcdir)/odph_cuckootable.h
> 
>  __LIB__libodphelper_linux_la_SOURCES = \
>   eth.c \
>   ip.c \
>   linux.c \
>   hashtable.c \
> - lineartable.c
> + lineartable.c \
> + cuckootable.c
> 
>  lib_LTLIBRARIES = $(LIB)/libodphelper-linux.la diff --git
a/helper/cuckootable.c
> b/helper/cuckootable.c new file mode 100644 index 000..f607fa0
> --- /dev/null
> +++ b/helper/cuckootable.c
> @@ -0,0 +1,746 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +/*-
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *   All rights reserved.
> + *
> + *   Redistribution and use in source and binary forms, with or without
> + *   modification, are permitted provided that the following conditions
> + *   are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above
copyright
> + *   notice, this list of conditions and the following disclaimer in
> + *   the documentation and/or other materials provided with the
> + *   distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products derived
> + *   from this software without specific prior written permission.
> + *
> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "odph_cuckootable.h"
> +#include "odph_debug.h"
> +#include 
> +
> +/* Macro to enable/disable run-time checking of function parameters */
> +#define RETURN_IF_TRUE(cond, retval) do { \
> + if (cond) \
> + return retval; \
> +} while (0)
> +
> +/* More efficient access to a map of single ullong */
> +#define ULLONG_FOR_EACH_1(IDX, MAP)  \
> + for (; MAP && (((IDX) = __builtin_ctzll(MAP)), true); \
> +  MAP = (MAP & (MAP - 1)))
> +
> +/** @magic word, write to the first byte of the memory block
> + *   to indicate this block is used by a cuckoo hash table
> + */
> +#define ODPH_CUCKOO_TABLE_MAGIC_WORD 0xDFDFFDFD
> +
> +/** Number of items per bucket. */
> +#define HASH_BUCKET_ENTRIES  4
> +
> +#define NULL_SIGNATURE   0
> +#define KEY_ALIGNMENT16
> +
> +/** Maximum size of hash table that can be created. */
> +#define HASH_ENTRIES_MAX1048576
> +
> +/** @internal signature struct
> + *   Structure storing both primary and secondary hashes
> + */
> +struct cuckoo_table_signatures {
> + union {
> +

[lng-odp] [API-NEXT PATCH v2 1/2] helper: table: add impl of cuckoo hash table

2016-04-17 Thread Ru Jia

Signed-off-by: Ru Jia 
---
 helper/Makefile.am|   6 +-
 helper/cuckootable.c  | 746 ++
 helper/odph_cuckootable.h |  82 +
 3 files changed, 832 insertions(+), 2 deletions(-)
 create mode 100644 helper/cuckootable.c
 create mode 100644 helper/odph_cuckootable.h

diff --git a/helper/Makefile.am b/helper/Makefile.am
index 8a86eb7..1763b99 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -27,13 +27,15 @@ noinst_HEADERS = \
 $(srcdir)/odph_debug.h \
 $(srcdir)/odph_hashtable.h \
 $(srcdir)/odph_lineartable.h \
-$(srcdir)/odph_list_internal.h
+$(srcdir)/odph_list_internal.h \
+$(srcdir)/odph_cuckootable.h
 
 __LIB__libodphelper_linux_la_SOURCES = \
eth.c \
ip.c \
linux.c \
hashtable.c \
-   lineartable.c
+   lineartable.c \
+   cuckootable.c
 
 lib_LTLIBRARIES = $(LIB)/libodphelper-linux.la
diff --git a/helper/cuckootable.c b/helper/cuckootable.c
new file mode 100644
index 000..f607fa0
--- /dev/null
+++ b/helper/cuckootable.c
@@ -0,0 +1,746 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "odph_cuckootable.h"
+#include "odph_debug.h"
+#include 
+
+/* Macro to enable/disable run-time checking of function parameters */
+#define RETURN_IF_TRUE(cond, retval) do { \
+   if (cond) \
+   return retval; \
+} while (0)
+
+/* More efficient access to a map of single ullong */
+#define ULLONG_FOR_EACH_1(IDX, MAP)\
+   for (; MAP && (((IDX) = __builtin_ctzll(MAP)), true); \
+MAP = (MAP & (MAP - 1)))
+
+/** @magic word, write to the first byte of the memory block
+ *   to indicate this block is used by a cuckoo hash table
+ */
+#define ODPH_CUCKOO_TABLE_MAGIC_WORD 0xDFDFFDFD
+
+/** Number of items per bucket. */
+#define HASH_BUCKET_ENTRIES4
+
+#define NULL_SIGNATURE 0
+#define KEY_ALIGNMENT  16
+
+/** Maximum size of hash table that can be created. */
+#define HASH_ENTRIES_MAX1048576
+
+/** @internal signature struct
+ *   Structure storing both primary and secondary hashes
+ */
+struct cuckoo_table_signatures {
+   union {
+   struct {
+   uint32_t current;
+   uint32_t alt;
+   };
+   uint64_t sig;
+   };
+};
+
+/** @internal kay-value struct
+ *   Structure that stores key-value pair
+ */
+struct cuckoo_table_key_value {
+   uint8_t *key;
+   uint8_t *value;
+};
+
+/** @internal bucket structure
+ *  Put the elements with defferent keys but a same signature
+ *  into a bucket, and each bucket has at most HASH_BUCKET_ENTRIES
+ *  elements.
+ */
+struct cuckoo_table_bucket {
+   struct cuckoo_table_signatures signatures[HASH_BUCKET_ENTRIES];
+   /* Includes dummy key index that alwa

[lng-odp] [API-NEXT PATCH v2 2/2] helper: test: add test of cuckoo hash table

2016-04-17 Thread Ru Jia

This test program consists of basic validation tests and
performance tests.

Signed-off-by: Ru Jia 
---
 helper/test/Makefile.am   |   4 +-
 helper/test/cuckootable.c | 514 ++
 2 files changed, 517 insertions(+), 1 deletion(-)
 create mode 100644 helper/test/cuckootable.c

diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
index 7f0b67d..e44beb6 100644
--- a/helper/test/Makefile.am
+++ b/helper/test/Makefile.am
@@ -9,7 +9,8 @@ EXECUTABLES = chksum$(EXEEXT) \
   thread$(EXEEXT) \
   parse$(EXEEXT)\
   process$(EXEEXT)\
-  table$(EXEEXT)
+  table$(EXEEXT)\
+  cuckootable$(EXEEXT)
 
 COMPILE_ONLY =
 
@@ -31,3 +32,4 @@ dist_process_SOURCES = process.c
 dist_parse_SOURCES = parse.c
 process_LDADD = $(LIB)/libodphelper-linux.la $(LIB)/libodp-linux.la
 dist_table_SOURCES = table.c
+dist_cuckootable_SOURCES = cuckootable.c
diff --git a/helper/test/cuckootable.c b/helper/test/cuckootable.c
new file mode 100644
index 000..efc65ee
--- /dev/null
+++ b/helper/test/cuckootable.c
@@ -0,0 +1,514 @@
+/* Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include <../odph_cuckootable.h>
+
+/***
+ * Hash function performance test configuration section.
+ *
+ * The five arrays below control what tests are performed. Every combination
+ * from the array entries is tested.
+ */
+/**/
+
+/*
+ * Check condition and return an error if true. Assumes that "table" is the
+ * name of the hash structure pointer to be freed.
+ */
+#define RETURN_IF_ERROR(cond, str, ...) do {   \
+   if (cond) { \
+   printf("ERROR line %d: " str "\n", __LINE__, ##__VA_ARGS__); \
+   if (table) \
+   odph_cuckoo_table_destroy(table);   \
+   return -1;  \
+   }   \
+} while (0)
+
+/* 5-tuple key type */
+struct flow_key {
+   uint32_t ip_src;
+   uint32_t ip_dst;
+   uint16_t port_src;
+   uint16_t port_dst;
+   uint8_t proto;
+} __packed;
+
+/*
+ * Print out result of unit test hash operation.
+ */
+static void print_key_info(
+   const char *msg, const struct flow_key *key)
+{
+   const uint8_t *p = (const uint8_t *)key;
+   unsigned i;
+
+   printf("%s key:0x", msg);
+   for (i = 0; i < sizeof(struct flow_key); i++)
+   printf("%02X", p[i]);
+   printf("\n");
+}
+
+static double get_time_diff(struct timeval *start, struct timeval *end)
+{
+   int sec = end->tv_sec - start->tv_sec;
+   int usec = end->tv_usec - start->tv_usec;
+
+   if (usec < 0) {
+   sec--;
+   usec += 100;
+   }
+   double diff = sec + (double)usec / 100;
+
+

Re: [lng-odp] LPM Algorithm APIs in ODP

2016-04-17 Thread P Gyanesh Kumar Patra

Hi,
Thank you for the details.
Do we have any time frame for the LPM code submission? 
Is it possible to do some trial on the LPM code now?

Is there a list of names of Algorithms in the pipeline to be developed for ODP?

Thank You
P Gyanesh K. Patra
University of Campinas (Unicamp)




> On Apr 17, 2016, at 22:55, HePeng  wrote:
> 
> Hi, 
>We are in the progress of releasing the LPM code, but currently we are 
> busy submitting the cuckoo hash code into ODP helper.
> 
>About the LPM code we have already a 16-8-8 implementation. Now we are 
> working on the code to fit it into ODP architecture. But we have not
> submitted any code for LPM yet. 
>
>If there is a requirement, we can switch to focus on LPM code. 
>
>> 在 2016年4月18日，上午9:03，gyanesh patra > > 写道：
>> 
>> I encountered an old email chain about the different LPM algorithm for ODP. 
>> I am curious if anyone has released or working on something for l3 
>> forwarding/routing.
>> Here is the link to the mail chain:
>> https://lists.linaro.org/pipermail/lng-odp/2015-August/014717.html 
>> 
>> 
>> If any work is going on, then point me in the correct direction. Also do we 
>> have any example code for l3 forwarding in ODP available now?
>> 
>> Thank you
>> P Gyanesh K. Patra
>> University of Campinas (Unicamp)
>> 
>> 
>> ___
>> 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] LPM Algorithm APIs in ODP

2016-04-17 Thread HePeng

Hi, 
   We are in the progress of releasing the LPM code, but currently we are 
busy submitting the cuckoo hash code into ODP helper.

   About the LPM code we have already a 16-8-8 implementation. Now we are 
working on the code to fit it into ODP architecture. But we have not
submitted any code for LPM yet. 
   
   If there is a requirement, we can switch to focus on LPM code. 
   
> 在 2016年4月18日，上午9:03，gyanesh patra  写道：
> 
> I encountered an old email chain about the different LPM algorithm for ODP. I 
> am curious if anyone has released or working on something for l3 
> forwarding/routing.
> Here is the link to the mail chain:
> https://lists.linaro.org/pipermail/lng-odp/2015-August/014717.html 
> 
> 
> If any work is going on, then point me in the correct direction. Also do we 
> have any example code for l3 forwarding in ODP available now?
> 
> Thank you
> P Gyanesh K. Patra
> University of Campinas (Unicamp)
> 
> 
> ___
> 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] [API-NEXT PATCH 2/2] doc: userguide: split packet section to own file and add extend/trunc doc

2016-04-17 Thread Bill Fischofer

To improve modularity, move the packet documentation to its own sub-file
and add additional information about the new APIs for extending and
truncating packet head/tail.

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/users-guide-pkt.adoc | 131 +++
 doc/users-guide/users-guide.adoc | 121 +---
 2 files changed, 132 insertions(+), 120 deletions(-)
 create mode 100644 doc/users-guide/users-guide-pkt.adoc

diff --git a/doc/users-guide/users-guide-pkt.adoc 
b/doc/users-guide/users-guide-pkt.adoc
new file mode 100644
index 000..1bb0793
--- /dev/null
+++ b/doc/users-guide/users-guide-pkt.adoc
@@ -0,0 +1,131 @@
+== Packet Processing
+ODP applications are designed to process packets, which are the basic unit of
+data of interest in the data plane. To assist in processing packets, ODP
+provides a set of APIs that enable applications to examine and manipulate
+packet data and metadata. Packets are referenced by an abstract *odp_packet_t*
+handle defined by each implementation.
+
+Packet objects are normally created at ingress when they arrive at a source
+*odp_pktio_t* and are received by an application either directly or (more
+typically) for a scheduled receive queue. They MAY be implicitly freed when
+they are transmitted to an output *odp_pktio_t* via an associated transmit
+queue, or freed directly via the +odp_packet_free()+ API.
+
+Occasionally an application may originate a packet itself, either _de novo_ or
+by deriving it from an existing packet, and APIs are provided to assist in
+these cases as well. Application-created packets can be recycled back through
+a _loopback interface_ to reparse and reclassify them, or the application can
+do its own parsing as desired.
+
+Various attributes associated with a packet, such as parse results, are
+stored as metadata and APIs are provided to permit applications to examine
+and/or modify this information.
+
+=== Packet Structure and Concepts
+A _packet_ consists of a sequence of octets conforming to an architected
+format, such as Ethernet, that can be received and transmitted via the ODP
+*pktio* abstraction. Packets of a _length_, which is the number of bytes in
+the packet. Packet data in ODP is referenced via _offsets_ since these reflect
+the logical contents and structure of a packet independent of how particular
+ODP implementations store that data.
+
+These concepts are shown in the following diagram:
+
+.ODP Packet Structure
+image::packet.svg[align="center"]
+
+Packet data consists of zero or more _headers_ followed by 0 or more bytes of
+_payload_, followed by zero or more _trailers_.  Shown here are various APIs
+that permit applications to examine and navigate various parts of a packet and
+to manipulate its structure.
+
+To support packet manipulation, predefined _headroom_ and _tailroom_
+areas are logically associated with a packet. Packets can be adjusted by
+_pulling_ and _pushing_ these areas. Typical packet processing might consist
+of stripping headers from a packet via +odp_pull_head()+ calls as part of
+receive processing and then replacing them with new headers via
++odp_push_head()+ calls as the packet is being prepared for transmit.
+
+=== Packet Segments and Addressing
+ODP platforms use various methods and techniques to store and process packets
+efficiently. These vary considerably from platform to platform, so to ensure
+portability across them ODP adopts certain conventions for referencing
+packets.
+
+ODP APIs use a handle of type *odp_packet_t* to refer to packet objects.
+Associated with packets are various bits of system metadata that describe the
+packet. By referring to the metadata, ODP applications accelerate packet
+processing by minimizing the need to examine packet data. This is because the
+metadata is populated by parsing and classification functions that are coupled
+to ingress processing that occur prior to a packet being presented to the
+application via the ODP scheduler.
+
+When an ODP application needs to examine the contents of a packet, it requests
+addressability to it via an API call that makes the packet (or a contiguously
+addressable _segment_ of it) available for coherent access by the application.
+To ensure portability, ODP applications assume that the underlying
+implementation stores packets in _segments_ of implementation-defined
+and managed size. These represent the contiguously addressable portions of a
+packet that the application may refer to via normal memory accesses. ODP
+provides APIs that allow applications to operate on packet segments in an
+efficient and portable manner as needed. By combining these with the metadata
+provided by packets, ODP applications can operate in a fully
+platform-independent manner while still achieving optimal performance across
+the range of platforms that support ODP.
+
+The use of segments for packet addressing and their relationship to metadata
+is shown in this diagram:
+
+.ODP Packet Seg

[lng-odp] LPM Algorithm APIs in ODP

2016-04-17 Thread gyanesh patra

I encountered an old email chain about the different LPM algorithm for ODP.
I am curious if anyone has released or working on something for l3
forwarding/routing.
Here is the link to the mail chain:
https://lists.linaro.org/pipermail/lng-odp/2015-August/014717.html

If any work is going on, then point me in the correct direction. Also do we
have any example code for l3 forwarding in ODP available now?

Thank you
*P Gyanesh K. Patra*
*University of Campinas (Unicamp)*
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] doc/users-quide: correct timer API section

2016-04-17 Thread Bill Fischofer

General comment: This explanation could benefit considerably from the
inclusion of a state diagram like that used for the pktio documentation.
Here's the suggested timer_fsm.gv file:

digraph timer_state_machine {
rankdir=LR;
size="10,12";
node [fontsize=28];
edge [fontsize=28];
node [shape=doublecircle]; Timer_Unalloc
  Timeout_Unalloc
  Timeout_Delivered;
node [shape=circle];
Timer_Unalloc -> Timer_Alloc [label="odp_timer_alloc()"];
Timer_Alloc -> Timer_Unalloc [label="odp_timer_free()"];
Timer_Alloc -> Timer_Set [label="odp_timer_set_abs()"];
Timer_Alloc -> Timer_Set [label="odp_timer_set_rel()"];
Timer_Set -> Timer_Alloc [label="odp_timer_cancel()"];
Timer_Set -> Timeout_Alloc
[label="odp_timer_cancel()" constraint=false];
Timer_Set -> Timer_Fired [label="(timer expires)"];
Timer_Fired -> Timeout_Delivered [label="odp_schedule()"];
Timeout_Unalloc -> Timeout_Alloc
[label="odp_timeout_alloc()" constraint=false];
Timeout_Alloc -> Timeout_Unalloc
  [label="odp_timeout_free()" constraint=false];
Timeout_Alloc -> Timer_Set
  [label="odp_timer_set_abs()" constraint=false];
Timeout_Alloc -> Timer_Set
  [label="odp_timer_set_rel()"];
Timeout_Delivered -> Timer_Unalloc [label="odp_timer_free()"];
Timeout_Delivered -> Timer_Set [label="odp_timer_set_abs()"];
Timeout_Delivered -> Timer_Set [label="odp_timer_set_rel()"];
Timeout_Delivered -> Timeout_Delivered
 [label="odp_timeout_from_event()"];
Timeout_Delivered -> Timeout_Delivered
 [label="odp_timeout_timer()"];
Timeout_Delivered -> Timeout_Unalloc
 [label="odp_event_free() / odp_timeout_freee()"
 constraint=false];
}

This should be added to doc/images and the .svg file referenced from there
and should help clarify the text in explaining the relationship between
timers and timeouts.

Additional suggestions/corrections inline:

On Thu, Apr 14, 2016 at 8:31 AM, Ivan Khoronzhuk  wrote:

> Signed-off-by: Ivan Khoronzhuk 
> ---
> v2..v1:
> - just rebased with several not important corrections
>
>  doc/users-guide/users-guide.adoc | 50
> 
>  1 file changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index a2e5058..69b1930 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -335,11 +335,51 @@ The +odp_time_t+ opaque type represents local or
> global timestamps.
>
>  === Timer
>  Timers are how ODP applications measure and respond to the passage of
> time.
> -Timers are drawn from specialized pools called timer pools that have their
> -own abstract type (+odp_timer_pool_t+). Applications may have many timers
> -active at the same time and can set them to use either relative or
> absolute
> -time. When timers expire they create events of type +odp_timeout_t+, which
> -serve as notifications of timer expiration.
> +The timer API is supposed to be used when time synchronization with
> events is
>

delete 'supposed to be' (extraneous)


> +needed and has different nature than time API has. Usually, timers
> require a
>

rephrase (simplify): ...and is different than the time API.
Delete next sentence ("Usually, timers require...") as that's not relevant
to the API or its usage.


> +separate h/w module to be used for generating timeouts. Timers are drawn
> from
> +specialized pools called timer pools that have their own abstract type
> +(+odp_timer_pool_t+). Applications may have many timers active at the same
> +time and can set them to use either relative or absolute time. When timers
> +expire they create events of type +odp_timeout_t+, which serve as
> notifications
> +of timer expiration. The event is placed on a queue pointed while timer
>

rephrase (clarify): "...placed on a queue specified at timer allocation."


> +allocation.
> +
> +Each timer pool can be set with it's own resolution in ns and number of
>

grammar: its, not it's


> +supported timers. So, timer pool can be considered as a time source with
>

grammar: So, a timer pool can be considered a time source...


> +it's own resolution and defined number of timers. All timers in timer pool
> +are handled with same time source with same resolution. If user needs two
> types
> +of timers with different requirements for resolution then better to create
> +two pools with it's own resolution, it can decrease load on hardware.
>

grammar and rephrase: All timers in a timer pool have the same time source
and resolution.
If two types of timers with different resolutions are needed, then
applications should create two
timer pools, each with its own resolution.


> +
> +An expiration time for the timer is set in it's own ticks, so nanoseconds
> have
> +to be converted first with conversation function
> +odp_timer_ns_to_tick()+, to
> +convert it back to ns use +odp_timer_tick_to_ns()+. Both functions require
> +to pass a timer pool used, as it can be sourced with it's own time source
> that
> +can have specific resolution and thus differen

Re: [lng-odp] [API-NEXT PATCH v2 1/2] helper: table: add impl of cuckoo hash table

[lng-odp] [API-NEXT PATCH v2 1/2] helper: table: add impl of cuckoo hash table

[lng-odp] [API-NEXT PATCH v2 2/2] helper: test: add test of cuckoo hash table

Re: [lng-odp] LPM Algorithm APIs in ODP

Re: [lng-odp] LPM Algorithm APIs in ODP

[lng-odp] [API-NEXT PATCH 2/2] doc: userguide: split packet section to own file and add extend/trunc doc

[lng-odp] LPM Algorithm APIs in ODP

Re: [lng-odp] [API-NEXT PATCH v2] doc/users-quide: correct timer API section

8 matches

Site Navigation

Mail list logo

Footer information