[lng-odp] ODP crypto API

[Bogdan Pricope]

Hi,

I have some questions on ODP crypto API:

1.   Where can I find an ODP crypto API manual/document?

2.   Some crypto APIs have a way to associate a crypto session with a 
"device": create a crypto session in the context of that "device". Is that 
possible with ODP crypto API?

3.   Some crypto APIs have asynchronous crypto session creation/deletion. 
Is that possible with ODP crypto API?
I know that ODP API provides completion queue with the session creation API 
(odp_crypto_session_create()) but it (ODP implementation) is supposed to 
generate a completion notification of special type when session creation is 
completed or... ?

Bogdan Pricope
Software Engineer
Engineering Office

Email  bogdan.pric...@enea.com
Phone  +4 074.20.20.475

Enea Global Services

www.enea.com

[cid:image002.png@01D0B99B.6F4867F0]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Maxim Uvarov]

On 12/08/2015 10:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Bill,

hash_tbl_entry is now uintptr_t, which is 64 bits on a 64 bit build and 32 bits 
on a 32 bit build. These shifts and all other lines  that expect that 
hash_tbl_entry (pointer size) is 64 bits should be updated also.

-Petri



Yes, that is what I said before.  For now we can go with simple using 64 
bit hash entries for 32 bit case also.
Where 6 upper bits will be for defining first or secondary hash and it's 
size. And all lower 32 for address pointer.

I.e. 26 bits will be lost.

#define PRIMARY_HASH_TBL_SIZE(16 * 1024)
26 * PRIMARY_HASH_TBL_SIZE = 425984 = 53248 bytes = 13 pages;

#define SECONDARY_HASH_TBL_SIZE  128
26 * SECONDARY_HASH_TBL_SIZE = 3328 = 416 bytes

So we lost for 32 bits some memory but code has to work in the same way 
as for 64 bits.
After that if memory efficient fix will be needed for somebody than he 
can fix it.

Or we will reuse some odp hash table api instead of odp_name_table.c.

So for now I would do quick fix with some comment that there is unused 
memory for 32 bit case.


--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -93,7 +93,7 @@ typedef struct {
  * NOT zero then this values points to a (linked list of) 
name_table_entry_t

  * records AND the bottom 6 bits are the length of this list.
  */
-typedef uintptr_t hash_tbl_entry_t;
+typedef uint64_t hash_tbl_entry_t;


BR,
Maxim.


-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Maxim Uvarov
Sent: Monday, December 07, 2015 5:01 PM
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use
odp_hash_crc32c() api to avoid arch issues

shift still is not fixed:

odp_name_table.c:186:4: error: right shift count >= width of type [-
Werror]
  if ((hash_tbl_entry >> 48) == 0x7FFF)
  ^
odp_name_table.c:188:4: error: right shift count >= width of type [-
Werror]
  else if ((hash_tbl_entry >> 48) == 0)


On 12/07/2015 14:09, Bill Fischofer wrote:

Change the internal hash_name_and_kind() function to eliminate the use
of architecture-specific hash instructions. This eliminates build issues
surrounding ARM variants. Future optimizations will use the arch

directory

consistent with other ODP modules.

Signed-off-by: Bill Fischofer 
---
   platform/linux-generic/odp_name_table.c | 184 +---



   1 file changed, 2 insertions(+), 182 deletions(-)

diff --git a/platform/linux-generic/odp_name_table.c b/platform/linux-

generic/odp_name_table.c

index 10a760e..b4a9081 100644
--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -48,140 +48,6 @@

   #define SECONDARY_HASH_HISTO_PRINT  1

- /* #define USE_AES */
-
-#if defined __x86_64__ || defined __i386__
-
-#ifdef USE_AES
-
-typedef long long int v2di __attribute__((vector_size(16)));
-
-static const v2di HASH_CONST1 = { 0x123456, 0xFEBCDA383   };
-static const v2di HASH_CONST2 = { 0x493BA3F689, 0x102F5D73A8C };
-
-#define PLATFORM_HASH_STATE v2di
-
-#define PLATFORM_HASH32_INIT(hash_state, name_len)  \
-   ({  \
-   hash_state = HASH_CONST1;   \
-   hash_state[0] ^= name_len;  \
-   })
-
-#define PLATFORM_HASH32(hash_state, name_word) \
-   ({ \
-   v2di data; \
-  \
-   data[0]= name_word;\
-   data[1]= name_word << 1;  \
-   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
-   })
-
-#define PLATFORM_HASH32_FINISH(hash_state, kind)

\

-   ({  \
-   uint64_t result;\
-   v2di data;  \
-   \
-   data[0]= name_kind; \
-   data[1]= name_kind << 7;\
-   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
-   hash_state = __builtin_ia32_aesenc128(hash_state,   \
- HASH_CONST2); \
-   hash_state = __builtin_ia32_aesenc128(hash_state,   \
- HASH_CONST1); \
-   result = (uint64_t)hash_state[0] ^ hash_state[1];   \
-   result = result ^ result >> 32; \
-   (uint32_t)result;

Re: [lng-odp] [API-NEXT PATCH v5 0/7] Multi-queue packet io APIs

[Savolainen, Petri (Nokia - FI/Espoo)]

ping.

I have a flow on scheduler integration patch set which improves l2fwd scheduler 
mode packet rate ~25x (8 cores, 2x10GE interfaces).


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Petri Savolainen
> Sent: Thursday, November 26, 2015 10:35 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v5 0/7] Multi-queue packet io APIs
> 
> This patch set adds APIs for multi-queue packet IO. It does not remove or
> modify
> existing API calls, so that multi-queue can be verified first with couple
> of
> apps and implementations. Single queue APIs (e.g. odp_pktio_inq_setdef())
> and
> potentially plain _recv() and _send() should be removed once everything is
> ported to use the new API (potentially with num_queues == 1).
> 
> Configuration of multiple packet input and output queues fit better into
> pktio
> API than classification and TM APIs. Multi-queue is more generally needed
> (and
> provided) than classification or TM. Classification (and potentially TM)
> API
> spec should be aligned to use the new default input/output queue setup.
> 
> v5:
>  * rebased
>  * fixed bug in l2fwd bind_workers()
> 
> v4:
>  * added additional cast to avoid build error
> 
> v3:
>  * added dummy implementations (6/7)
>  * modified l2fwd to use multi-queue API in direct mode (7/7)
>  * use term single_user instead of single_thr
>  * use term hash_enable instead of hash_ena
> 
> v2:
>  * changed hash proto to bit field to allow selection of multiple
> protocols
>  * added IPv4 and IPv6 protocols
>  * defined odp_pktin_queue_t and pktout_queue_t handle types instead
>of using indexes
>  * use term single_thr instead of lock_free
>  * added hash_ena to control if hashing (or classification) is used for
>spreading flows to multiple queues
> 
> Petri Savolainen (7):
>   api: pktio: added pktio capability struct
>   api: pktio: added multiple pktio input queues
>   api: pktio: added direct queue receive
>   api: pktio: added multiple pktio output queues
>   api: pktio: added direct send to pktio output queue
>   linux-generic: pktio: dummy multi-queue pktio
>   test: l2fwd: use multi-queue pktio in direct mode
> 
>  include/odp/api/packet_io.h| 302 ++-
>  .../include/odp/plat/packet_io_types.h |  14 +-
>  .../linux-generic/include/odp_packet_io_internal.h |  46 +++
>  platform/linux-generic/odp_packet_io.c | 280 ++
>  platform/linux-generic/pktio/loop.c|  10 +-
>  platform/linux-generic/pktio/netmap.c  |  10 +-
>  platform/linux-generic/pktio/pcap.c|  10 +-
>  platform/linux-generic/pktio/socket.c  |  10 +-
>  platform/linux-generic/pktio/socket_mmap.c |  10 +-
>  test/performance/odp_l2fwd.c   | 413
> +
>  10 files changed, 1024 insertions(+), 81 deletions(-)
> 
> --
> 2.6.3
> 
> ___
> 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] [API-NEXT PATCH v2 0/5] netmap pktio multi queue support

[Savolainen, Petri (Nokia - FI/Espoo)]

Ping.

Applies on top of [API-NEXT PATCH v5 0/7] Multi-queue packet io APIs.


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Matias Elo
> Sent: Wednesday, November 25, 2015 3:16 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v2 0/5] netmap pktio multi queue
> support
> 
> This patch set adds initial multi queue support to netmap pktio.
> 
> Applies on top of the '[API-NEXT PATCH v3 0/7] Multi-queue packet io APIs'
> patch set.
> 
> v2:
> + Configure mode ODP_PKTIN_MODE_POLL/ODP_PKTIN_MODE_SCHED input queues
> correctly
>   in netmap_input_queues_config()
> + Fix queue lock false sharing by rearranging netmap data structures
> + Set odp_packet_hdr.input in netmap_pkt_to_odp()
> 
> Matias Elo (5):
>   linux-generic: pktio: add RSS helper functions
>   linux-generic: netmap: add odp_pktio_start()
>   linux-generic: netmap: add odp_pktio_capability()
>   linux-generic: netmap: add multi queue support
>   linux-generic: netmap: odp_pktio_recv() from all pktin queues
> 
>  platform/linux-generic/include/odp_packet_netmap.h |  39 +-
>  platform/linux-generic/include/odp_packet_socket.h |  18 +
>  platform/linux-generic/pktio/netmap.c  | 492
> ++---
>  platform/linux-generic/pktio/socket.c  | 164 +++
>  4 files changed, 644 insertions(+), 69 deletions(-)
> 
> --
> 1.9.1
> 
> ___
> 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] [API-NEXT PATCH v5 0/7] Multi-queue packet io APIs

[Bill Fischofer]

We can discuss this during today's ODP public call and hopefully wrap it
up.  Thanks.

On Tue, Dec 8, 2015 at 2:00 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> ping.
>
> I have a flow on scheduler integration patch set which improves l2fwd
> scheduler mode packet rate ~25x (8 cores, 2x10GE interfaces).
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Petri Savolainen
> > Sent: Thursday, November 26, 2015 10:35 AM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [API-NEXT PATCH v5 0/7] Multi-queue packet io APIs
> >
> > This patch set adds APIs for multi-queue packet IO. It does not remove or
> > modify
> > existing API calls, so that multi-queue can be verified first with couple
> > of
> > apps and implementations. Single queue APIs (e.g. odp_pktio_inq_setdef())
> > and
> > potentially plain _recv() and _send() should be removed once everything
> is
> > ported to use the new API (potentially with num_queues == 1).
> >
> > Configuration of multiple packet input and output queues fit better into
> > pktio
> > API than classification and TM APIs. Multi-queue is more generally needed
> > (and
> > provided) than classification or TM. Classification (and potentially TM)
> > API
> > spec should be aligned to use the new default input/output queue setup.
> >
> > v5:
> >  * rebased
> >  * fixed bug in l2fwd bind_workers()
> >
> > v4:
> >  * added additional cast to avoid build error
> >
> > v3:
> >  * added dummy implementations (6/7)
> >  * modified l2fwd to use multi-queue API in direct mode (7/7)
> >  * use term single_user instead of single_thr
> >  * use term hash_enable instead of hash_ena
> >
> > v2:
> >  * changed hash proto to bit field to allow selection of multiple
> > protocols
> >  * added IPv4 and IPv6 protocols
> >  * defined odp_pktin_queue_t and pktout_queue_t handle types instead
> >of using indexes
> >  * use term single_thr instead of lock_free
> >  * added hash_ena to control if hashing (or classification) is used for
> >spreading flows to multiple queues
> >
> > Petri Savolainen (7):
> >   api: pktio: added pktio capability struct
> >   api: pktio: added multiple pktio input queues
> >   api: pktio: added direct queue receive
> >   api: pktio: added multiple pktio output queues
> >   api: pktio: added direct send to pktio output queue
> >   linux-generic: pktio: dummy multi-queue pktio
> >   test: l2fwd: use multi-queue pktio in direct mode
> >
> >  include/odp/api/packet_io.h| 302 ++-
> >  .../include/odp/plat/packet_io_types.h |  14 +-
> >  .../linux-generic/include/odp_packet_io_internal.h |  46 +++
> >  platform/linux-generic/odp_packet_io.c | 280 ++
> >  platform/linux-generic/pktio/loop.c|  10 +-
> >  platform/linux-generic/pktio/netmap.c  |  10 +-
> >  platform/linux-generic/pktio/pcap.c|  10 +-
> >  platform/linux-generic/pktio/socket.c  |  10 +-
> >  platform/linux-generic/pktio/socket_mmap.c |  10 +-
> >  test/performance/odp_l2fwd.c   | 413
> > +
> >  10 files changed, 1024 insertions(+), 81 deletions(-)
> >
> > --
> > 2.6.3
> >
> > ___
> > 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Elo, Matias (Nokia - FI/Espoo)]

Hi Ilya,

I had completely missed your previous patch. You could also remove the two 
errno value checks in pktio_test_send_failure(). They are not defined in the 
API, so they should not be tested.

-Matias

> -Original Message-
> From: EXT Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Tuesday, December 08, 2015 12:44 PM
> To: Elo, Matias (Nokia - FI/Espoo) ; lng-
> o...@lists.linaro.org
> Subject: Re: validation: pktio: fix start_stop and send_failure tests
> 
> Matias,
> please check out my patch ( https://lists.linaro.org/pipermail/lng-odp/2015-
> December/018057.html )
> from my 'TAP pktio' patch set.
> 
> Best regards, Ilya Maximets.
> 
> On 08.12.2015 13:36, Elo, Matias (Nokia - FI/Espoo) wrote:
> > In both tests set MAC addresses to test packets to enable
> > testing with real pktio interfaces.
> >
> > In pktio_test_send_failure() don't check for errno values
> > as they are not defined in the API.
> >
> > Signed-off-by: Matias Elo 
> > ---
> >  test/validation/pktio/pktio.c | 26 +-
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
> > index 50a6d8a..4ded924 100644
> > --- a/test/validation/pktio/pktio.c
> > +++ b/test/validation/pktio/pktio.c
> > @@ -695,6 +695,7 @@ void pktio_test_inq(void)
> >  static void pktio_test_start_stop(void)
> >  {
> > odp_pktio_t pktio[MAX_NUM_IFACES];
> > +   pktio_info_t pktio_info[MAX_NUM_IFACES];
> > odp_packet_t pkt;
> > odp_event_t tx_ev[1000];
> > odp_event_t ev;
> > @@ -705,6 +706,7 @@ static void pktio_test_start_stop(void)
> > for (i = 0; i < num_ifaces; i++) {
> > pktio[i] = create_pktio(i, ODP_PKTIN_MODE_SCHED);
> > CU_ASSERT_FATAL(pktio[i] != ODP_PKTIO_INVALID);
> > +   pktio_info[i].id = pktio[i];
> > create_inq(pktio[i],  ODP_QUEUE_TYPE_SCHED);
> > }
> >
> > @@ -724,6 +726,8 @@ static void pktio_test_start_stop(void)
> > if (pkt == ODP_PACKET_INVALID)
> > break;
> > pktio_init_packet(pkt);
> > +   pktio_pkt_set_macs(pkt, _info[0],
> > +  _info[1]);
> > tx_ev[alloc] = odp_packet_to_event(pkt);
> > }
> >
> > @@ -775,6 +779,9 @@ static void pktio_test_start_stop(void)
> > if (pkt == ODP_PACKET_INVALID)
> > break;
> > pktio_init_packet(pkt);
> > +   if (num_ifaces > 1)
> > +   pktio_pkt_set_macs(pkt, _info[0],
> > +  _info[1]);
> > tx_ev[alloc] = odp_packet_to_event(pkt);
> > }
> >
> > @@ -849,13 +856,14 @@ static void pktio_test_send_failure(void)
> > odp_pool_param_t pool_params;
> > odp_pool_t pkt_pool;
> > int long_pkt_idx = TX_BATCH_LEN / 2;
> > -   pktio_info_t info_rx;
> > +   pktio_info_t info_tx, info_rx;
> >
> > pktio_tx = create_pktio(0, ODP_PKTIN_MODE_RECV);
> > if (pktio_tx == ODP_PKTIO_INVALID) {
> > CU_FAIL("failed to open pktio");
> > return;
> > }
> > +   info_tx.id   = pktio_tx;
> >
> > /* read the MTU from the transmit interface */
> > mtu = odp_pktio_mtu(pktio_tx);
> > @@ -880,6 +888,10 @@ static void pktio_test_send_failure(void)
> > } else {
> > pktio_rx = pktio_tx;
> > }
> > +   info_rx.id   = pktio_rx;
> > +   info_rx.outq = ODP_QUEUE_INVALID;
> > +   info_rx.inq  = ODP_QUEUE_INVALID;
> > +   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
> >
> > /* generate a batch of packets with a single overly long packet
> >  * in the middle */
> > @@ -898,6 +910,8 @@ static void pktio_test_send_failure(void)
> > pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
> > if (pkt_seq[i] == TEST_SEQ_INVALID)
> > break;
> > +
> > +   pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
> > }
> > alloc_pkts = i;
> >
> > @@ -907,12 +921,6 @@ static void pktio_test_send_failure(void)
> > odp_errno_zero();
> > ret = odp_pktio_send(pktio_tx, pkt_tbl, TX_BATCH_LEN);
> > CU_ASSERT(ret == long_pkt_idx);
> > -   CU_ASSERT(odp_errno() == 0);
> > -
> > -   info_rx.id   = pktio_rx;
> > -   info_rx.outq = ODP_QUEUE_INVALID;
> > -   info_rx.inq  = ODP_QUEUE_INVALID;
> > -   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
> >
> > for (i = 0; i < ret; ++i) {
> > pkt_tbl[i] = wait_for_packet(_rx, pkt_seq[i],
> > @@ -929,9 +937,8 @@ static void pktio_test_send_failure(void)
> >  _tbl[long_pkt_idx],
> >  TX_BATCH_LEN - long_pkt_idx);
> > CU_ASSERT(ret == -1);
> > -   CU_ASSERT(odp_errno() != 0);
> > } else {
> > -   

[lng-odp] [API-NEXT/PATCHv1 3/4] validation: classification: add class of service create api

[Balasubramanian Manoharan]

Replaces odp_cos_create() function with odp_cls_cos_create() function

Signed-off-by: Balasubramanian Manoharan 
---
 test/validation/classification/classification.h|   1 +
 .../classification/odp_classification_basic.c  | 137 +++-
 .../classification/odp_classification_common.c |  15 +-
 .../classification/odp_classification_test_pmr.c   | 386 +
 .../classification/odp_classification_tests.c  | 207 ---
 .../classification/odp_classification_testsuites.h |   3 +-
 6 files changed, 453 insertions(+), 296 deletions(-)

diff --git a/test/validation/classification/classification.h 
b/test/validation/classification/classification.h
index 6a7e8a5..e3fc081 100644
--- a/test/validation/classification/classification.h
+++ b/test/validation/classification/classification.h
@@ -59,6 +59,7 @@ void classification_test_destroy_cos(void);
 void classification_test_create_pmr_match(void);
 void classification_test_destroy_pmr(void);
 void classification_test_cos_set_queue(void);
+void classification_test_cos_set_pool(void);
 void classification_test_cos_set_drop(void);
 void classification_test_pmr_match_set_create(void);
 void classification_test_pmr_match_set_destroy(void);
diff --git a/test/validation/classification/odp_classification_basic.c 
b/test/validation/classification/odp_classification_basic.c
index 20c157f..f0b7a42 100644
--- a/test/validation/classification/odp_classification_basic.c
+++ b/test/validation/classification/odp_classification_basic.c
@@ -13,26 +13,60 @@
 void classification_test_create_cos(void)
 {
odp_cos_t cos;
-   char name[ODP_COS_NAME_LEN];
-   sprintf(name, "ClassOfService");
-   cos = odp_cos_create(name);
-   CU_ASSERT_FATAL(cos != ODP_COS_INVALID);
+   odp_cls_cos_param_t cls_param;
+   odp_pool_t pool;
+   odp_queue_t queue;
+   char cosname[ODP_COS_NAME_LEN];
+
+   pool = pool_create("cls_basic_pool");
+   CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
+
+   queue = queue_create("cls_basic_queue", true);
+   CU_ASSERT_FATAL(queue != ODP_QUEUE_INVALID);
+
+   sprintf(cosname, "ClassOfService");
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = pool;
+   cls_param.queue = queue;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+
+   cos = odp_cls_cos_create(cosname, _param);
CU_ASSERT(odp_cos_to_u64(cos) != odp_cos_to_u64(ODP_COS_INVALID));
odp_cos_destroy(cos);
+   odp_pool_destroy(pool);
+   odp_queue_destroy(queue);
 }
 
 void classification_test_destroy_cos(void)
 {
odp_cos_t cos;
char name[ODP_COS_NAME_LEN];
+   odp_pool_t pool;
+   odp_queue_t queue;
+   odp_cls_cos_param_t cls_param;
int retval;
+
+   pool = pool_create("cls_basic_pool");
+   CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
+
+   queue = queue_create("cls_basic_queue", true);
+   CU_ASSERT_FATAL(queue != ODP_QUEUE_INVALID);
+
sprintf(name, "ClassOfService");
-   cos = odp_cos_create(name);
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = pool;
+   cls_param.queue = queue;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+
+   cos = odp_cls_cos_create(name, _param);
CU_ASSERT_FATAL(cos != ODP_COS_INVALID);
retval = odp_cos_destroy(cos);
CU_ASSERT(retval == 0);
retval = odp_cos_destroy(ODP_COS_INVALID);
CU_ASSERT(retval < 0);
+
+   odp_pool_destroy(pool);
+   odp_queue_destroy(queue);
 }
 
 void classification_test_create_pmr_match(void)
@@ -82,35 +116,101 @@ void classification_test_cos_set_queue(void)
 {
int retval;
char cosname[ODP_COS_NAME_LEN];
-   char queuename[ODP_QUEUE_NAME_LEN];
-   odp_queue_param_t qparam;
+   odp_cls_cos_param_t cls_param;
+   odp_pool_t pool;
+   odp_queue_t queue;
odp_queue_t queue_cos;
odp_cos_t cos_queue;
+   odp_queue_t recvqueue;
+
+   pool = pool_create("cls_basic_pool");
+   CU_ASSERT_FATAL(pool != ODP_POOL_INVALID);
+
+   queue = queue_create("cls_basic_queue", true);
+   CU_ASSERT_FATAL(queue != ODP_QUEUE_INVALID);
+
sprintf(cosname, "CoSQueue");
-   cos_queue = odp_cos_create(cosname);
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = pool;
+   cls_param.queue = queue;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+   cos_queue = odp_cls_cos_create(cosname, _param);
CU_ASSERT_FATAL(cos_queue != ODP_COS_INVALID);
 
-   odp_queue_param_init();
-   qparam.sched.prio = ODP_SCHED_PRIO_HIGHEST;
-   qparam.sched.sync = ODP_SCHED_SYNC_NONE;
-   qparam.sched.group = ODP_SCHED_GROUP_ALL;
-   sprintf(queuename, "%s", "QueueCoS");
+   queue_cos = queue_create("QueueCoS", true);
+   CU_ASSERT_FATAL(queue_cos != ODP_QUEUE_INVALID);
 
-   queue_cos = odp_queue_create(queuename,
-

Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local time to be monotonic

[Maxim Uvarov]

That patch serries looks ok, instead of one overrun of 32 bit counter.
I can fix it just in place.

Petri, agree?

time.c: In function 'time_test_monotony':
time.c:60:15: error: comparison is always true due to limited range of 
data type [-Werror=type-limits]

  while (count < BUSY_LOOP_CNT_LONG) {

--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -45,7 +45,7 @@ void time_test_odp_conversion(void)

 void time_test_monotony(void)
 {
-   volatile unsigned long count = 0;
+   volatile uint64_t count = 0;
odp_time_t t1, t2, t3;
uint64_t ns1, ns2, ns3;

Maxim.


On 12/04/2015 20:51, Ivan Khoronzhuk wrote:

This series is intended to modify time API to be used as monotonic wall
time in order to simplify time API usage and create prerequisites for
adding global time API.

Since v6:
- changed patch order a little to pass validation tests
- fixed issue with pktio perf test
- no functional changes

Since v5:
   linux-generic: align with new wall time API
- deleted _odp prefix for local functions
- avoided modulo operation
- used common global var for start time

Since v3:
- "api: time: make odp_local_time to be monotonic wall time"
   splitted on;
   "linux-generic: align with new wall time API"
   "test/example: use local time API as wall time"
- increased BUSY_LOOP_CNT to fit in resolution and 4+ sec

Since v2:
- removed patch changing type of ODP_TIME_*
- added new patch:
   test: performance: pktio: don't use direct arithmetic operations with
 odp_time_t
- added new patch:
   performance: sched: use ODP time API instead of clock_gettime
- combined monotonic and wall time patches
- removed odp_time_local_val() and odp_time_val_to_ns()
- replaced terms monotonic and wall in API desc

Since v1:
- corrected name of the series to be api-next
- use thread local for holding start time

Ivan Khoronzhuk (9):
   validation: time: don't assign int directly to odp_time_t
   test: performance: pktio: don't use direct arithmetic operations with
 odp_time_t
   linux-generic: schedule: use schedule time in ns
   linux-generic: odp_time: don't use cpu cycle API to get time
   performance: sched: use ODP time API instead of clock_gettime
   api: time: make odp_local_time to be monotonic wall time
   validation: time: align tests with current time API
   linux-generic: align with new wall time API
   test/example: use local time API as wall time

  example/generator/odp_generator.c  |  10 +-
  include/odp/api/time.h |   3 +-
  platform/linux-generic/Makefile.am |   1 -
  .../linux-generic/include/odp/plat/time_types.h|   6 +-
  platform/linux-generic/include/odp_cpu_internal.h  |  29 ---
  platform/linux-generic/include/odp_internal.h  |   2 +
  platform/linux-generic/odp_cpu.c   |   6 +-
  platform/linux-generic/odp_init.c  |   4 +
  platform/linux-generic/odp_schedule.c  |  18 +-
  platform/linux-generic/odp_time.c  | 112 +++---
  test/performance/odp_pktio_perf.c  |  24 +--
  test/performance/odp_scheduling.c  |  37 +---
  test/validation/pktio/pktio.c  |  21 +-
  test/validation/time/time.c| 228 ++---
  test/validation/time/time.h|   7 +-
  15 files changed, 346 insertions(+), 162 deletions(-)
  delete mode 100644 platform/linux-generic/include/odp_cpu_internal.h



___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[Maxim Uvarov]

Peng, can you please send version with buffers pool to the list. Might 
be something wrong in implementation.


Maxim.

On 12/08/2015 14:42, Bill Fischofer wrote:
This is an interesting topic.  I'd like to discuss this a bit during 
today's ODP public call.


I think the issue is that while a ring is a very useful implementation 
construct its semantics are very SW centric. Perhaps there's 
opportunity here for a new Queue type that would permit an 
implementation to implement the queue API as a ring for additional 
performance?  The scheduler itself could use this since its use of 
queues is subject to the same issues.


On Mon, Dec 7, 2015 at 11:39 PM, HePeng > wrote:


Hi Maxim,
I implement a new version of cuckoo hash based on the ODP
buffer/pool.

As I’ve mentioned earlier, the use of ring in cuckoo hash
is like to the use of
a container, e.g. a queue in C++ STL.  In current ODP
implementation, I found that
the ODP queue is implemented more likely a facility for
transmitting objects, not
a container to store objects. Look at the ODP queue enqueue interface:

int odp_queue_enq(odp_queue_t queue, odp_event_t ev);

the *odp_event_t* is related to the events, but I only want to use
odp_queue to
storing and retrieving objects, any objects.


So I use ODP buffer/pool interfaces instead of ODP queue
for the new cuckoo hash implementation.

However, compared to the previous implementation based on
ring, this version
suffers a serious performance degradation. The evaluation is
carried out on a Intel
servers. I test lookup time for 1000 lookups on a table storing 1
million items.
The ODP buffer/pool version suffers at least a 2x performance
degradation.

This is the buffer/pool version, for 1M insert, and 1000 lookup time:

Average insert time = 2.383836, lookup time = 0.000353,

This is the ring version.

Average insert time = 1.629115, lookup time = 0.98

This performance degradation stems from the heavy
implementation of
 ODP buffer/pool. In the ring based one, all the key is stored in
a big array, and
the ring only stores the array indexes of each key. Keys are
retrieved using array indexes.
In the new one, I use ODP buffer to store the key content. Keys
are retrieved by
dereferencing a *odp_buffer_t*  handle.

With this high performance degradation, I suggest moving
ring into the odp/api
as a container implementation, and use the previous implementation
of cuckoo hash.






___
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] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Stuart Haslam]

On Tue, Dec 08, 2015 at 02:51:40PM +0300, Ilya Maximets wrote:
> On 08.12.2015 14:24, Stuart Haslam wrote:
> > On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
> >> Creates a new pktio type that allows for creating and
> >> sending/receiving packets through TAP interface.
> >> It is intended for use as a simple conventional communication
> >> method between applications that use kernel network stack
> >> (ping, ssh, iperf, etc.) and ODP applications for the purpose
> >> of functional testing and can be used as it is with some
> >> of the existing example applications.
> >>
> >> To use this interface the name passed to odp_pktio_open() must
> >> begin with "tap:" and be in the format:
> >>
> >>  tap:iface
> >>
> >>iface   the name of TAP device to be created.
> >>
> >> TUN/TAP kernel module should be loaded to use this pktio.
> >> There should be no device named 'iface' in the system.
> >> The total length of the 'iface' is limited by IF_NAMESIZE.
> >>
> >> Signed-off-by: Ilya Maximets 
> >> ---
> >>  platform/linux-generic/Makefile.am |   2 +
> >>  .../linux-generic/include/odp_packet_io_internal.h |   3 +
> >>  platform/linux-generic/include/odp_packet_tap.h|  21 ++
> >>  platform/linux-generic/pktio/io_ops.c  |   1 +
> >>  platform/linux-generic/pktio/tap.c | 317 
> >> +
> >>  5 files changed, 344 insertions(+)
> >>  create mode 100644 platform/linux-generic/include/odp_packet_tap.h
> >>  create mode 100644 platform/linux-generic/pktio/tap.c
> >>
> >> diff --git a/platform/linux-generic/Makefile.am 
> >> b/platform/linux-generic/Makefile.am
> >> index 70bd8fe..4639ebc 100644
> >> --- a/platform/linux-generic/Makefile.am
> >> +++ b/platform/linux-generic/Makefile.am
> >> @@ -92,6 +92,7 @@ noinst_HEADERS = \
> >>  ${srcdir}/include/odp_packet_io_queue.h \
> >>  ${srcdir}/include/odp_packet_netmap.h \
> >>  ${srcdir}/include/odp_packet_socket.h \
> >> +${srcdir}/include/odp_packet_tap.h \
> >>  ${srcdir}/include/odp_pool_internal.h \
> >>  ${srcdir}/include/odp_queue_internal.h \
> >>  ${srcdir}/include/odp_schedule_internal.h \
> >> @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
> >>   pktio/netmap.c \
> >>   pktio/socket.c \
> >>   pktio/socket_mmap.c \
> >> + pktio/tap.c \
> >>   odp_pool.c \
> >>   odp_queue.c \
> >>   odp_rwlock.c \
> >> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
> >> b/platform/linux-generic/include/odp_packet_io_internal.h
> >> index 1a1118c..de29557 100644
> >> --- a/platform/linux-generic/include/odp_packet_io_internal.h
> >> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
> >> @@ -22,6 +22,7 @@ extern "C" {
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -78,6 +79,7 @@ struct pktio_entry {
> >>  #ifdef HAVE_PCAP
> >>pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
> >>  #endif
> >> +  pkt_tap_t pkt_tap;  /**< using TAP for IO */
> >>};
> >>enum {
> >>STATE_START = 0,
> >> @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
> >>  #ifdef HAVE_PCAP
> >>  extern const pktio_if_ops_t pcap_pktio_ops;
> >>  #endif
> >> +extern const pktio_if_ops_t tap_pktio_ops;
> >>  extern const pktio_if_ops_t * const pktio_if_ops[];
> >>  
> >>  #ifdef __cplusplus
> >> diff --git a/platform/linux-generic/include/odp_packet_tap.h 
> >> b/platform/linux-generic/include/odp_packet_tap.h
> >> new file mode 100644
> >> index 000..7877586
> >> --- /dev/null
> >> +++ b/platform/linux-generic/include/odp_packet_tap.h
> >> @@ -0,0 +1,21 @@
> >> +/* Copyright (c) 2015, Ilya Maximets 
> >> + * All rights reserved.
> >> + *
> >> + * SPDX-License-Identifier: BSD-3-Clause
> >> + */
> >> +
> >> +#ifndef ODP_PACKET_TAP_H_
> >> +#define ODP_PACKET_TAP_H_
> >> +
> >> +#include 
> >> +
> >> +typedef struct {
> >> +  int fd; /**< file descriptor for tap interface*/
> >> +  int skfd;   /**< socket descriptor */
> >> +  uint32_t mtu;   /**< cached mtu */
> >> +  unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side (not a
> >> +   MAC address of kernel interface)*/
> >> +  odp_pool_t pool;/**< pool to alloc packets from */
> >> +} pkt_tap_t;
> >> +
> >> +#endif
> >> diff --git a/platform/linux-generic/pktio/io_ops.c 
> >> b/platform/linux-generic/pktio/io_ops.c
> >> index 3b344e6..1933abc 100644
> >> --- a/platform/linux-generic/pktio/io_ops.c
> >> +++ b/platform/linux-generic/pktio/io_ops.c
> >> @@ -18,6 +18,7 @@ const pktio_if_ops_t * const 

Re: [lng-odp] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Ilya Maximets]

On 08.12.2015 14:24, Stuart Haslam wrote:
> On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
>> Creates a new pktio type that allows for creating and
>> sending/receiving packets through TAP interface.
>> It is intended for use as a simple conventional communication
>> method between applications that use kernel network stack
>> (ping, ssh, iperf, etc.) and ODP applications for the purpose
>> of functional testing and can be used as it is with some
>> of the existing example applications.
>>
>> To use this interface the name passed to odp_pktio_open() must
>> begin with "tap:" and be in the format:
>>
>>  tap:iface
>>
>>iface   the name of TAP device to be created.
>>
>> TUN/TAP kernel module should be loaded to use this pktio.
>> There should be no device named 'iface' in the system.
>> The total length of the 'iface' is limited by IF_NAMESIZE.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>  platform/linux-generic/Makefile.am |   2 +
>>  .../linux-generic/include/odp_packet_io_internal.h |   3 +
>>  platform/linux-generic/include/odp_packet_tap.h|  21 ++
>>  platform/linux-generic/pktio/io_ops.c  |   1 +
>>  platform/linux-generic/pktio/tap.c | 317 
>> +
>>  5 files changed, 344 insertions(+)
>>  create mode 100644 platform/linux-generic/include/odp_packet_tap.h
>>  create mode 100644 platform/linux-generic/pktio/tap.c
>>
>> diff --git a/platform/linux-generic/Makefile.am 
>> b/platform/linux-generic/Makefile.am
>> index 70bd8fe..4639ebc 100644
>> --- a/platform/linux-generic/Makefile.am
>> +++ b/platform/linux-generic/Makefile.am
>> @@ -92,6 +92,7 @@ noinst_HEADERS = \
>>${srcdir}/include/odp_packet_io_queue.h \
>>${srcdir}/include/odp_packet_netmap.h \
>>${srcdir}/include/odp_packet_socket.h \
>> +  ${srcdir}/include/odp_packet_tap.h \
>>${srcdir}/include/odp_pool_internal.h \
>>${srcdir}/include/odp_queue_internal.h \
>>${srcdir}/include/odp_schedule_internal.h \
>> @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
>> pktio/netmap.c \
>> pktio/socket.c \
>> pktio/socket_mmap.c \
>> +   pktio/tap.c \
>> odp_pool.c \
>> odp_queue.c \
>> odp_rwlock.c \
>> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
>> b/platform/linux-generic/include/odp_packet_io_internal.h
>> index 1a1118c..de29557 100644
>> --- a/platform/linux-generic/include/odp_packet_io_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
>> @@ -22,6 +22,7 @@ extern "C" {
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -78,6 +79,7 @@ struct pktio_entry {
>>  #ifdef HAVE_PCAP
>>  pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
>>  #endif
>> +pkt_tap_t pkt_tap;  /**< using TAP for IO */
>>  };
>>  enum {
>>  STATE_START = 0,
>> @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
>>  #ifdef HAVE_PCAP
>>  extern const pktio_if_ops_t pcap_pktio_ops;
>>  #endif
>> +extern const pktio_if_ops_t tap_pktio_ops;
>>  extern const pktio_if_ops_t * const pktio_if_ops[];
>>  
>>  #ifdef __cplusplus
>> diff --git a/platform/linux-generic/include/odp_packet_tap.h 
>> b/platform/linux-generic/include/odp_packet_tap.h
>> new file mode 100644
>> index 000..7877586
>> --- /dev/null
>> +++ b/platform/linux-generic/include/odp_packet_tap.h
>> @@ -0,0 +1,21 @@
>> +/* Copyright (c) 2015, Ilya Maximets 
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#ifndef ODP_PACKET_TAP_H_
>> +#define ODP_PACKET_TAP_H_
>> +
>> +#include 
>> +
>> +typedef struct {
>> +int fd; /**< file descriptor for tap interface*/
>> +int skfd;   /**< socket descriptor */
>> +uint32_t mtu;   /**< cached mtu */
>> +unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side (not a
>> + MAC address of kernel interface)*/
>> +odp_pool_t pool;/**< pool to alloc packets from */
>> +} pkt_tap_t;
>> +
>> +#endif
>> diff --git a/platform/linux-generic/pktio/io_ops.c 
>> b/platform/linux-generic/pktio/io_ops.c
>> index 3b344e6..1933abc 100644
>> --- a/platform/linux-generic/pktio/io_ops.c
>> +++ b/platform/linux-generic/pktio/io_ops.c
>> @@ -18,6 +18,7 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
>>  #ifdef HAVE_PCAP
>>  _pktio_ops,
>>  #endif
>> +_pktio_ops,
>>  _mmap_pktio_ops,
>>  _mmsg_pktio_ops,
>>  NULL
>> diff --git a/platform/linux-generic/pktio/tap.c 
>> b/platform/linux-generic/pktio/tap.c
>> new file 

Re: [lng-odp] [PATCH 00/10] Pktio checks

[Stuart Haslam]

On Tue, Nov 10, 2015 at 04:49:39PM +0100, Nicolas Morey-Chaisemartin wrote:
> This series add several tests for pktios and fixes the issue they raised.
> The main features checked are:
> * RONLY pktio cannot be sent to
> * WONLY pktio cannot be read from
> * stopped pktio cannot be stopped
> * started pktio cannot be started
> * started pktio cannot be configured
> 
> Nicolas Morey-Chaisemartin (10):
>   linux-generic: pktio: check interface mode is compatible before
> receiving or sending
>   validation: pktio: add customizable out mode for pktios
>   validation: pktio: add tests for rrecv() on WONLY, and send on RONLY
> pktios
>   validation: pktio: stop interfaces before removing the default inq
>   validation: pktio: remove unneeded stop as interface is stopped after
> open()
>   validation: classification: start pktio after setting inq and stop it
> before removing it
>   validation: classification: stronger checks to avoid SEGV on pktio
> failure
>   linux-generic: pktio: check for pktio_start when started and
> pktio_stop when stopped
>   linux-generic: pktio: configuration functions check that interface is
> stopped
>   validation: pktio: add test for start when started and stop when
> stopped()
> 
>  platform/linux-generic/odp_packet_io.c |  25 -
>  .../classification/odp_classification_common.c |   2 +
>  .../classification/odp_classification_test_pmr.c   |  25 +++--
>  test/validation/pktio/pktio.c  | 116 
> ++---
>  4 files changed, 140 insertions(+), 28 deletions(-)
> 

For the series:

Reviewed-by: Stuart Haslam 

-- 
Stuart.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] ODP crypto API

[Bill Fischofer]

You can find the current crypto API documentation at
http://docs.opendataplane.org/master/linux-generic-doxygen-html/group__odp__crypto.html

We are working on updating the ODP User Guide (see
http://docs.opendataplane.org/master/linux-generic/output/users-guide.html)
 but the crypto section of that document doesn't exist yet.

odp_crypto_session_create() is currently defined to be synchronous.

On Tue, Dec 8, 2015 at 2:53 AM, Bogdan Pricope 
wrote:

> Hi,
>
>
>
> I have some questions on ODP crypto API:
>
> 1.   Where can I find an ODP crypto API manual/document?
>
> 2.   Some crypto APIs have a way to associate a crypto session with a
> „device”: create a crypto session in the context of that „device”. Is that
> possible with ODP crypto API?
>
> 3.   Some crypto APIs have asynchronous crypto session
> creation/deletion. Is that possible with ODP crypto API?
>
> I know that ODP API provides completion queue with the session creation
> API (odp_crypto_session_create()) but it (ODP implementation) is supposed
> to generate a completion notification of special type when session creation
> is completed or… ?
>
>
>
> *Bogdan Pricope*
>
> Software Engineer
>
> Engineering Office
>
>
>
> *Email*  *bogdan.pric...@enea.com *
>
> *Phone*  +4 074.20.20.475
>
>
>
> *Enea Global Services*
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D0B99B.6F4867F0]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
>
> ___
> 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] [API-NEXT PATCHv2] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Maxim Uvarov]

On 12/08/2015 14:27, Bill Fischofer wrote:
The cast plus the uint64_t typedef is the v1 patch.  So is that one 
now good?


For me v1 was good if I remember. And v2 with that fix also is good. 
Petri do you have any notes?



Maxim.



On Tue, Dec 8, 2015 at 4:45 AM, Maxim Uvarov > wrote:


On 12/08/2015 13:09, Savolainen, Petri (Nokia - FI/Espoo) wrote:


-Original Message-
From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org
]
Sent: Tuesday, December 08, 2015 10:44 AM
To: Savolainen, Petri (Nokia - FI/Espoo);
lng-odp@lists.linaro.org 
Subject: Re: [lng-odp] [API-NEXT PATCHv2] linux-generic:
tm: use
odp_hash_crc32c() api to avoid arch issues

On 12/08/2015 10:50, Savolainen, Petri (Nokia - FI/Espoo)
wrote:

Bill,

hash_tbl_entry is now uintptr_t, which is 64 bits on a
64 bit build and

32 bits on a 32 bit build. These shifts and all other
lines  that expect
that hash_tbl_entry (pointer size) is 64 bits should be
updated also.

-Petri

Yes, that is what I said before.  For now we can go with
simple using 64
bit hash entries for 32 bit case also.
Where 6 upper bits will be for defining first or secondary
hash and it's
size. And all lower 32 for address pointer.
I.e. 26 bits will be lost.

#define PRIMARY_HASH_TBL_SIZE(16 * 1024)
26 * PRIMARY_HASH_TBL_SIZE = 425984 = 53248 bytes = 13 pages;

#define SECONDARY_HASH_TBL_SIZE  128
26 * SECONDARY_HASH_TBL_SIZE = 3328 = 416 bytes

So we lost for 32 bits some memory but code has to work in
the same way
as for 64 bits.
After that if memory efficient fix will be needed for
somebody than he
can fix it.
Or we will reuse some odp hash table api instead of
odp_name_table.c.

So for now I would do quick fix with some comment that
there is unused
memory for 32 bit case.

--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -93,7 +93,7 @@ typedef struct {
* NOT zero then this values points to a (linked list of)
name_table_entry_t
* records AND the bottom 6 bits are the length of this
list.
*/
-typedef uintptr_t hash_tbl_entry_t;
+typedef uint64_t hash_tbl_entry_t;


BR,
Maxim.


odp_name_table.c: In function 'make_hash_tbl_entry':
odp_name_table.c:570:20: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
   hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;


static hash_tbl_entry_t make_hash_tbl_entry(name_tbl_entry_t
*name_tbl_entry,
uint32_t
entry_cnt)

{
hash_tbl_entry_t hash_tbl_entry;
uint32_t new_entry_cnt;

new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
hash_tbl_entry  =
(hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
hash_tbl_entry &= ~0x3F;
hash_tbl_entry |= new_entry_cnt;
return hash_tbl_entry;
}


And compiler is still happy with the casts? Maybe the casting
issue was actually caused by removal of the uintptr_t cast above.

-Petri

Petri, Looks like you did not apply that patch. If you apply it
and do change to uint64_t everything compiles.

Maxim.

___
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] [PATCH] linux-generic: socket: set up __odp_errno on ioctl failures

[Stuart Haslam]

On Mon, Dec 07, 2015 at 05:25:03PM +0300, Ilya Maximets wrote:
> Also debug output enhanced.
> 
> Signed-off-by: Ilya Maximets 

Reviewed-by: Stuart Haslam 

> ---
>  platform/linux-generic/pktio/socket.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/platform/linux-generic/pktio/socket.c 
> b/platform/linux-generic/pktio/socket.c
> index 5f5e0ae..ef2e031 100644
> --- a/platform/linux-generic/pktio/socket.c
> +++ b/platform/linux-generic/pktio/socket.c
> @@ -126,7 +126,9 @@ int mtu_get_fd(int fd, const char *name)
>   snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
>   ret = ioctl(fd, SIOCGIFMTU, );
>   if (ret < 0) {
> - ODP_DBG("ioctl SIOCGIFMTU error\n");
> + __odp_errno = errno;
> + ODP_DBG("ioctl(SIOCGIFMTU): %s: \"%s\".\n", strerror(errno),
> + ifr.ifr_name);
>   return -1;
>   }
>   return ifr.ifr_mtu;
> @@ -145,7 +147,9 @@ int promisc_mode_set_fd(int fd, const char *name, int 
> enable)
>   snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
>   ret = ioctl(fd, SIOCGIFFLAGS, );
>   if (ret < 0) {
> - ODP_DBG("ioctl SIOCGIFFLAGS error\n");
> + __odp_errno = errno;
> + ODP_DBG("ioctl(SIOCGIFFLAGS): %s: \"%s\".\n", strerror(errno),
> + ifr.ifr_name);
>   return -1;
>   }
>  
> @@ -156,7 +160,9 @@ int promisc_mode_set_fd(int fd, const char *name, int 
> enable)
>  
>   ret = ioctl(fd, SIOCSIFFLAGS, );
>   if (ret < 0) {
> - ODP_DBG("ioctl SIOCSIFFLAGS error\n");
> + __odp_errno = errno;
> + ODP_DBG("ioctl(SIOCSIFFLAGS): %s: \"%s\".\n", strerror(errno),
> + ifr.ifr_name);
>   return -1;
>   }
>   return 0;
> @@ -175,7 +181,9 @@ int promisc_mode_get_fd(int fd, const char *name)
>   snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
>   ret = ioctl(fd, SIOCGIFFLAGS, );
>   if (ret < 0) {
> - ODP_DBG("ioctl SIOCGIFFLAGS error\n");
> + __odp_errno = errno;
> + ODP_DBG("ioctl(SIOCGIFFLAGS): %s: \"%s\".\n", strerror(errno),
> + ifr.ifr_name);
>   return -1;
>   }
>  
> -- 
> 2.1.4
> 

-- 
Stuart.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[Bill Fischofer]

This is an interesting topic.  I'd like to discuss this a bit during
today's ODP public call.

I think the issue is that while a ring is a very useful implementation
construct its semantics are very SW centric. Perhaps there's opportunity
here for a new Queue type that would permit an implementation to implement
the queue API as a ring for additional performance?  The scheduler itself
could use this since its use of queues is subject to the same issues.

On Mon, Dec 7, 2015 at 11:39 PM, HePeng  wrote:

> Hi Maxim,
> I implement a new version of cuckoo hash based on the ODP
> buffer/pool.
>
> As I’ve mentioned earlier, the use of ring in cuckoo hash is like
> to the use of
> a container, e.g. a queue in C++ STL.  In current ODP implementation, I
> found that
> the ODP queue is implemented more likely a facility for transmitting
> objects, not
> a container to store objects. Look at the ODP queue enqueue interface:
>
> int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
>
> the *odp_event_t* is related to the events, but I only want to use
> odp_queue to
> storing and retrieving objects, any objects.
>
>
> So I use ODP buffer/pool interfaces instead of ODP queue
> for the new cuckoo hash implementation.
>
> However, compared to the previous implementation based on ring,
> this version
> suffers a serious performance degradation. The evaluation is carried out
> on a Intel
> servers. I test lookup time for 1000 lookups on a table storing 1 million
> items.
> The ODP buffer/pool version suffers at least a 2x performance degradation.
>
> This is the buffer/pool version, for 1M insert, and 1000 lookup time:
>
> Average insert time = 2.383836, lookup time = 0.000353,
>
> This is the ring version.
>
> Average insert time = 1.629115, lookup time = 0.98
>
> This performance degradation stems from the heavy implementation of
>  ODP buffer/pool. In the ring based one, all the key is stored in a big
> array, and
> the ring only stores the array indexes of each key. Keys are retrieved
> using array indexes.
> In the new one, I use ODP buffer to store the key content. Keys are
> retrieved by
> dereferencing a *odp_buffer_t*  handle.
>
> With this high performance degradation, I suggest moving ring into
> the odp/api
> as a container implementation, and use the previous implementation of
> cuckoo hash.
>
>
>
>
>
>
> ___
> 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] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Stuart Haslam]

On Tue, Dec 08, 2015 at 03:25:01PM +0300, Ilya Maximets wrote:
> 
> 
> On 08.12.2015 15:16, Stuart Haslam wrote:
> > On Tue, Dec 08, 2015 at 02:51:40PM +0300, Ilya Maximets wrote:
> >> On 08.12.2015 14:24, Stuart Haslam wrote:
> >>> On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
>  Creates a new pktio type that allows for creating and
>  sending/receiving packets through TAP interface.
>  It is intended for use as a simple conventional communication
>  method between applications that use kernel network stack
>  (ping, ssh, iperf, etc.) and ODP applications for the purpose
>  of functional testing and can be used as it is with some
>  of the existing example applications.
> 
>  To use this interface the name passed to odp_pktio_open() must
>  begin with "tap:" and be in the format:
> 
>   tap:iface
> 
> iface   the name of TAP device to be created.
> 
>  TUN/TAP kernel module should be loaded to use this pktio.
>  There should be no device named 'iface' in the system.
>  The total length of the 'iface' is limited by IF_NAMESIZE.
> 
>  Signed-off-by: Ilya Maximets 
>  ---
>   platform/linux-generic/Makefile.am |   2 +
>   .../linux-generic/include/odp_packet_io_internal.h |   3 +
>   platform/linux-generic/include/odp_packet_tap.h|  21 ++
>   platform/linux-generic/pktio/io_ops.c  |   1 +
>   platform/linux-generic/pktio/tap.c | 317 
>  +
>   5 files changed, 344 insertions(+)
>   create mode 100644 platform/linux-generic/include/odp_packet_tap.h
>   create mode 100644 platform/linux-generic/pktio/tap.c
> 
>  diff --git a/platform/linux-generic/Makefile.am 
>  b/platform/linux-generic/Makefile.am
>  index 70bd8fe..4639ebc 100644
>  --- a/platform/linux-generic/Makefile.am
>  +++ b/platform/linux-generic/Makefile.am
>  @@ -92,6 +92,7 @@ noinst_HEADERS = \
> ${srcdir}/include/odp_packet_io_queue.h \
> ${srcdir}/include/odp_packet_netmap.h \
> ${srcdir}/include/odp_packet_socket.h \
>  +  ${srcdir}/include/odp_packet_tap.h \
> ${srcdir}/include/odp_pool_internal.h \
> ${srcdir}/include/odp_queue_internal.h \
> ${srcdir}/include/odp_schedule_internal.h \
>  @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
>  pktio/netmap.c \
>  pktio/socket.c \
>  pktio/socket_mmap.c \
>  +   pktio/tap.c \
>  odp_pool.c \
>  odp_queue.c \
>  odp_rwlock.c \
>  diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
>  b/platform/linux-generic/include/odp_packet_io_internal.h
>  index 1a1118c..de29557 100644
>  --- a/platform/linux-generic/include/odp_packet_io_internal.h
>  +++ b/platform/linux-generic/include/odp_packet_io_internal.h
>  @@ -22,6 +22,7 @@ extern "C" {
>   #include 
>   #include 
>   #include 
>  +#include 
>   #include 
>   #include 
>   #include 
>  @@ -78,6 +79,7 @@ struct pktio_entry {
>   #ifdef HAVE_PCAP
>   pkt_pcap_t pkt_pcap;/**< Using pcap for IO 
>  */
>   #endif
>  +pkt_tap_t pkt_tap;  /**< using TAP for IO */
>   };
>   enum {
>   STATE_START = 0,
>  @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
>   #ifdef HAVE_PCAP
>   extern const pktio_if_ops_t pcap_pktio_ops;
>   #endif
>  +extern const pktio_if_ops_t tap_pktio_ops;
>   extern const pktio_if_ops_t * const pktio_if_ops[];
>   
>   #ifdef __cplusplus
>  diff --git a/platform/linux-generic/include/odp_packet_tap.h 
>  b/platform/linux-generic/include/odp_packet_tap.h
>  new file mode 100644
>  index 000..7877586
>  --- /dev/null
>  +++ b/platform/linux-generic/include/odp_packet_tap.h
>  @@ -0,0 +1,21 @@
>  +/* Copyright (c) 2015, Ilya Maximets 
>  + * All rights reserved.
>  + *
>  + * SPDX-License-Identifier: BSD-3-Clause
>  + */
>  +
>  +#ifndef ODP_PACKET_TAP_H_
>  +#define ODP_PACKET_TAP_H_
>  +
>  +#include 
>  +
>  +typedef struct {
>  +int fd; /**< file descriptor for tap 
>  interface*/
>  +int skfd;   /**< socket descriptor */
>  +uint32_t mtu;   /**< cached mtu */
>  +unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side 
>  (not a
> 

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Ilya Maximets]

Matias,
I think, better to make separate patch for that.
It will not intersect with mine in case of only 2 deletions.

Would you prepare it?

Best regards, Ilya Maximets.

On 08.12.2015 15:21, Elo, Matias (Nokia - FI/Espoo) wrote:
> Hi Ilya,
> 
> I had completely missed your previous patch. You could also remove the two 
> errno value checks in pktio_test_send_failure(). They are not defined in the 
> API, so they should not be tested.
> 
> -Matias
> 
>> -Original Message-
>> From: EXT Ilya Maximets [mailto:i.maxim...@samsung.com]
>> Sent: Tuesday, December 08, 2015 12:44 PM
>> To: Elo, Matias (Nokia - FI/Espoo) ; lng-
>> o...@lists.linaro.org
>> Subject: Re: validation: pktio: fix start_stop and send_failure tests
>>
>> Matias,
>> please check out my patch ( https://lists.linaro.org/pipermail/lng-odp/2015-
>> December/018057.html )
>> from my 'TAP pktio' patch set.
>>
>> Best regards, Ilya Maximets.
>>
>> On 08.12.2015 13:36, Elo, Matias (Nokia - FI/Espoo) wrote:
>>> In both tests set MAC addresses to test packets to enable
>>> testing with real pktio interfaces.
>>>
>>> In pktio_test_send_failure() don't check for errno values
>>> as they are not defined in the API.
>>>
>>> Signed-off-by: Matias Elo 
>>> ---
>>>  test/validation/pktio/pktio.c | 26 +-
>>>  1 file changed, 17 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
>>> index 50a6d8a..4ded924 100644
>>> --- a/test/validation/pktio/pktio.c
>>> +++ b/test/validation/pktio/pktio.c
>>> @@ -695,6 +695,7 @@ void pktio_test_inq(void)
>>>  static void pktio_test_start_stop(void)
>>>  {
>>> odp_pktio_t pktio[MAX_NUM_IFACES];
>>> +   pktio_info_t pktio_info[MAX_NUM_IFACES];
>>> odp_packet_t pkt;
>>> odp_event_t tx_ev[1000];
>>> odp_event_t ev;
>>> @@ -705,6 +706,7 @@ static void pktio_test_start_stop(void)
>>> for (i = 0; i < num_ifaces; i++) {
>>> pktio[i] = create_pktio(i, ODP_PKTIN_MODE_SCHED);
>>> CU_ASSERT_FATAL(pktio[i] != ODP_PKTIO_INVALID);
>>> +   pktio_info[i].id = pktio[i];
>>> create_inq(pktio[i],  ODP_QUEUE_TYPE_SCHED);
>>> }
>>>
>>> @@ -724,6 +726,8 @@ static void pktio_test_start_stop(void)
>>> if (pkt == ODP_PACKET_INVALID)
>>> break;
>>> pktio_init_packet(pkt);
>>> +   pktio_pkt_set_macs(pkt, _info[0],
>>> +  _info[1]);
>>> tx_ev[alloc] = odp_packet_to_event(pkt);
>>> }
>>>
>>> @@ -775,6 +779,9 @@ static void pktio_test_start_stop(void)
>>> if (pkt == ODP_PACKET_INVALID)
>>> break;
>>> pktio_init_packet(pkt);
>>> +   if (num_ifaces > 1)
>>> +   pktio_pkt_set_macs(pkt, _info[0],
>>> +  _info[1]);
>>> tx_ev[alloc] = odp_packet_to_event(pkt);
>>> }
>>>
>>> @@ -849,13 +856,14 @@ static void pktio_test_send_failure(void)
>>> odp_pool_param_t pool_params;
>>> odp_pool_t pkt_pool;
>>> int long_pkt_idx = TX_BATCH_LEN / 2;
>>> -   pktio_info_t info_rx;
>>> +   pktio_info_t info_tx, info_rx;
>>>
>>> pktio_tx = create_pktio(0, ODP_PKTIN_MODE_RECV);
>>> if (pktio_tx == ODP_PKTIO_INVALID) {
>>> CU_FAIL("failed to open pktio");
>>> return;
>>> }
>>> +   info_tx.id   = pktio_tx;
>>>
>>> /* read the MTU from the transmit interface */
>>> mtu = odp_pktio_mtu(pktio_tx);
>>> @@ -880,6 +888,10 @@ static void pktio_test_send_failure(void)
>>> } else {
>>> pktio_rx = pktio_tx;
>>> }
>>> +   info_rx.id   = pktio_rx;
>>> +   info_rx.outq = ODP_QUEUE_INVALID;
>>> +   info_rx.inq  = ODP_QUEUE_INVALID;
>>> +   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
>>>
>>> /* generate a batch of packets with a single overly long packet
>>>  * in the middle */
>>> @@ -898,6 +910,8 @@ static void pktio_test_send_failure(void)
>>> pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
>>> if (pkt_seq[i] == TEST_SEQ_INVALID)
>>> break;
>>> +
>>> +   pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
>>> }
>>> alloc_pkts = i;
>>>
>>> @@ -907,12 +921,6 @@ static void pktio_test_send_failure(void)
>>> odp_errno_zero();
>>> ret = odp_pktio_send(pktio_tx, pkt_tbl, TX_BATCH_LEN);
>>> CU_ASSERT(ret == long_pkt_idx);
>>> -   CU_ASSERT(odp_errno() == 0);
>>> -
>>> -   info_rx.id   = pktio_rx;
>>> -   info_rx.outq = ODP_QUEUE_INVALID;
>>> -   info_rx.inq  = ODP_QUEUE_INVALID;
>>> -   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
>>>
>>> for (i = 0; i < ret; ++i) {
>>> pkt_tbl[i] = wait_for_packet(_rx, pkt_seq[i],
>>> @@ -929,9 +937,8 @@ static void pktio_test_send_failure(void)
>>>  

[lng-odp] [API-NEXT/PATCHv1 4/4] example: classifier: add class of service create api

[Balasubramanian Manoharan]

Replaces odp_cos_create() function with odp_cls_cos_create() function

Signed-off-by: Balasubramanian Manoharan 
---
 example/classifier/odp_classifier.c | 42 +
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 2ecf733..481f763 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -357,16 +357,16 @@ static void *pktio_receive_thread(void *arg)
 static void configure_default_cos(odp_pktio_t pktio, appl_args_t *args)
 {
odp_queue_param_t qparam;
-   odp_cos_t cos_default;
const char *queue_name = "DefaultQueue";
const char *pool_name = "DefaultPool";
const char *cos_name = "DefaultCos";
odp_queue_t queue_default;
odp_pool_t pool_default;
+   odp_cos_t cos_default;
odp_pool_param_t pool_params;
+   odp_cls_cos_param_t cls_param;
global_statistics *stats = args->stats;
 
-   cos_default = odp_cos_create(cos_name);
 
odp_queue_param_init();
qparam.sched.prio = ODP_SCHED_PRIO_DEFAULT;
@@ -374,9 +374,8 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
qparam.sched.group = ODP_SCHED_GROUP_ALL;
queue_default = odp_queue_create(queue_name,
 ODP_QUEUE_TYPE_SCHED, );
-
-   if (0 > odp_cos_queue_set(cos_default, queue_default)) {
-   EXAMPLE_ERR("odp_cos_queue_set failed");
+   if (queue_default == ODP_QUEUE_INVALID) {
+   EXAMPLE_ERR("Error: default queue create failed.\n");
exit(EXIT_FAILURE);
}
 
@@ -385,7 +384,6 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
pool_params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
pool_params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
pool_params.type= ODP_POOL_PACKET;
-
pool_default = odp_pool_create(pool_name, _params);
 
if (pool_default == ODP_POOL_INVALID) {
@@ -393,8 +391,14 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
exit(EXIT_FAILURE);
}
 
-   if (0 > odp_cls_cos_pool_set(cos_default, pool_default)) {
-   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = pool_default;
+   cls_param.queue = queue_default;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+   cos_default = odp_cls_cos_create(cos_name, _param);
+
+   if (cos_default == ODP_COS_INVALID) {
+   EXAMPLE_ERR("Error: default cos create failed.\n");
exit(EXIT_FAILURE);
}
 
@@ -420,15 +424,13 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
char queue_name[ODP_QUEUE_NAME_LEN];
char pool_name[ODP_POOL_NAME_LEN];
odp_pool_param_t pool_params;
+   odp_cls_cos_param_t cls_param;
int i;
global_statistics *stats;
odp_queue_param_t qparam;
 
for (i = 0; i < args->policy_count; i++) {
stats = >stats[i];
-   snprintf(cos_name, sizeof(cos_name), "CoS%s",
-stats->cos_name);
-   stats->cos = odp_cos_create(cos_name);
 
const odp_pmr_match_t match = {
.term = stats->rule.term,
@@ -454,11 +456,6 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
exit(EXIT_FAILURE);
}
 
-   if (0 > odp_cos_queue_set(stats->cos, stats->queue)) {
-   EXAMPLE_ERR("odp_cos_queue_set failed");
-   exit(EXIT_FAILURE);
-   }
-
odp_pool_param_init(_params);
pool_params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
pool_params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
@@ -470,11 +467,19 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
 args->stats[i].cos_name, i);
stats->pool = odp_pool_create(pool_name, _params);
 
-   if (0 > odp_cls_cos_pool_set(stats->cos, stats->pool)) {
-   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   if (stats->pool == ODP_POOL_INVALID) {
+   EXAMPLE_ERR("Error: default pool create failed.\n");
exit(EXIT_FAILURE);
}
 
+   snprintf(cos_name, sizeof(cos_name), "CoS%s",
+stats->cos_name);
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = stats->pool;
+   cls_param.queue = stats->queue;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+   stats->cos = odp_cls_cos_create(cos_name, _param);
+
if (0 > odp_pktio_pmr_cos(stats->pmr, pktio, 

[lng-odp] [API-NEXT/PATCHv1 2/4] linux-generic: classification: implement class of service create api

[Balasubramanian Manoharan]

Implements odp_cls_cos_create() and odp_cls_cos_param_init() functions

Signed-off-by: Balasubramanian Manoharan 
---
 platform/linux-generic/odp_classification.c | 31 ++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index b1f51af..da6123e 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -154,9 +154,32 @@ int odp_classification_term_global(void)
return rc;
 }
 
-odp_cos_t odp_cos_create(const char *name)
+void odp_cls_cos_param_init(odp_cls_cos_param_t *param)
+{
+   param->queue = ODP_QUEUE_INVALID;
+   param->pool = ODP_POOL_INVALID;
+   param->drop_policy = ODP_COS_DROP_NEVER;
+}
+
+odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t *param)
 {
int i;
+   queue_entry_t *queue;
+   pool_entry_t *pool;
+   odp_drop_e drop_policy;
+
+   /* Packets are dropped if Queue or Pool is invalid*/
+   if (param->queue == ODP_QUEUE_INVALID)
+   queue = NULL;
+   else
+   queue = queue_to_qentry(param->queue);
+
+   if (param->pool == ODP_POOL_INVALID)
+   pool = NULL;
+   else
+   pool = odp_pool_to_entry(param->pool);
+
+   drop_policy = param->drop_policy;
 
for (i = 0; i < ODP_COS_MAX_ENTRY; i++) {
LOCK(_tbl->cos_entry[i].s.lock);
@@ -166,16 +189,18 @@ odp_cos_t odp_cos_create(const char *name)
cos_tbl->cos_entry[i].s.name[ODP_COS_NAME_LEN - 1] = 0;
cos_tbl->cos_entry[i].s.pmr = NULL;
cos_tbl->cos_entry[i].s.linked_cos = NULL;
-   cos_tbl->cos_entry[i].s.queue = NULL;
-   cos_tbl->cos_entry[i].s.pool = NULL;
+   cos_tbl->cos_entry[i].s.queue = queue;
+   cos_tbl->cos_entry[i].s.pool = pool;
cos_tbl->cos_entry[i].s.flow_set = 0;
cos_tbl->cos_entry[i].s.headroom = 0;
cos_tbl->cos_entry[i].s.valid = 1;
+   cos_tbl->cos_entry[i].s.drop_policy = drop_policy;
UNLOCK(_tbl->cos_entry[i].s.lock);
return _odp_cast_scalar(odp_cos_t, i);
}
UNLOCK(_tbl->cos_entry[i].s.lock);
}
+
ODP_ERR("ODP_COS_MAX_ENTRY reached");
return ODP_COS_INVALID;
 }
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Ilya Maximets]

Matias,
please check out my patch ( 
https://lists.linaro.org/pipermail/lng-odp/2015-December/018057.html )
from my 'TAP pktio' patch set.

Best regards, Ilya Maximets.

On 08.12.2015 13:36, Elo, Matias (Nokia - FI/Espoo) wrote:
> In both tests set MAC addresses to test packets to enable
> testing with real pktio interfaces.
> 
> In pktio_test_send_failure() don't check for errno values
> as they are not defined in the API.
> 
> Signed-off-by: Matias Elo 
> ---
>  test/validation/pktio/pktio.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
> index 50a6d8a..4ded924 100644
> --- a/test/validation/pktio/pktio.c
> +++ b/test/validation/pktio/pktio.c
> @@ -695,6 +695,7 @@ void pktio_test_inq(void)
>  static void pktio_test_start_stop(void)
>  {
>   odp_pktio_t pktio[MAX_NUM_IFACES];
> + pktio_info_t pktio_info[MAX_NUM_IFACES];
>   odp_packet_t pkt;
>   odp_event_t tx_ev[1000];
>   odp_event_t ev;
> @@ -705,6 +706,7 @@ static void pktio_test_start_stop(void)
>   for (i = 0; i < num_ifaces; i++) {
>   pktio[i] = create_pktio(i, ODP_PKTIN_MODE_SCHED);
>   CU_ASSERT_FATAL(pktio[i] != ODP_PKTIO_INVALID);
> + pktio_info[i].id = pktio[i];
>   create_inq(pktio[i],  ODP_QUEUE_TYPE_SCHED);
>   }
>  
> @@ -724,6 +726,8 @@ static void pktio_test_start_stop(void)
>   if (pkt == ODP_PACKET_INVALID)
>   break;
>   pktio_init_packet(pkt);
> + pktio_pkt_set_macs(pkt, _info[0],
> +_info[1]);
>   tx_ev[alloc] = odp_packet_to_event(pkt);
>   }
>  
> @@ -775,6 +779,9 @@ static void pktio_test_start_stop(void)
>   if (pkt == ODP_PACKET_INVALID)
>   break;
>   pktio_init_packet(pkt);
> + if (num_ifaces > 1)
> + pktio_pkt_set_macs(pkt, _info[0],
> +_info[1]);
>   tx_ev[alloc] = odp_packet_to_event(pkt);
>   }
>  
> @@ -849,13 +856,14 @@ static void pktio_test_send_failure(void)
>   odp_pool_param_t pool_params;
>   odp_pool_t pkt_pool;
>   int long_pkt_idx = TX_BATCH_LEN / 2;
> - pktio_info_t info_rx;
> + pktio_info_t info_tx, info_rx;
>  
>   pktio_tx = create_pktio(0, ODP_PKTIN_MODE_RECV);
>   if (pktio_tx == ODP_PKTIO_INVALID) {
>   CU_FAIL("failed to open pktio");
>   return;
>   }
> + info_tx.id   = pktio_tx;
>  
>   /* read the MTU from the transmit interface */
>   mtu = odp_pktio_mtu(pktio_tx);
> @@ -880,6 +888,10 @@ static void pktio_test_send_failure(void)
>   } else {
>   pktio_rx = pktio_tx;
>   }
> + info_rx.id   = pktio_rx;
> + info_rx.outq = ODP_QUEUE_INVALID;
> + info_rx.inq  = ODP_QUEUE_INVALID;
> + info_rx.in_mode = ODP_PKTIN_MODE_RECV;
>  
>   /* generate a batch of packets with a single overly long packet
>* in the middle */
> @@ -898,6 +910,8 @@ static void pktio_test_send_failure(void)
>   pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
>   if (pkt_seq[i] == TEST_SEQ_INVALID)
>   break;
> +
> + pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
>   }
>   alloc_pkts = i;
>  
> @@ -907,12 +921,6 @@ static void pktio_test_send_failure(void)
>   odp_errno_zero();
>   ret = odp_pktio_send(pktio_tx, pkt_tbl, TX_BATCH_LEN);
>   CU_ASSERT(ret == long_pkt_idx);
> - CU_ASSERT(odp_errno() == 0);
> -
> - info_rx.id   = pktio_rx;
> - info_rx.outq = ODP_QUEUE_INVALID;
> - info_rx.inq  = ODP_QUEUE_INVALID;
> - info_rx.in_mode = ODP_PKTIN_MODE_RECV;
>  
>   for (i = 0; i < ret; ++i) {
>   pkt_tbl[i] = wait_for_packet(_rx, pkt_seq[i],
> @@ -929,9 +937,8 @@ static void pktio_test_send_failure(void)
>_tbl[long_pkt_idx],
>TX_BATCH_LEN - long_pkt_idx);
>   CU_ASSERT(ret == -1);
> - CU_ASSERT(odp_errno() != 0);
>   } else {
> - CU_FAIL("failed to receive transmitted packets\n");
> + CU_FAIL("failed to receive transmitted packets");
>   }
>  
>   /* now reduce the size of the long packet and attempt to send
> @@ -942,6 +949,7 @@ static void pktio_test_send_failure(void)
>PKT_LEN_NORMAL);
>   pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
>   CU_ASSERT_FATAL(pkt_seq[i] != TEST_SEQ_INVALID);
> + pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
>   ret = odp_pktio_send(pktio_tx, 

[lng-odp] [API-NEXT/PATCHv1 1/4] api: classification: add class of serivce create api

[Balasubramanian Manoharan]

class of service create function now takes pool, queue, drop policy and
name as input parameters.
Adds class of service parameter structure odp_cls_cos_param_t and
initialization function odp_cls_cos_param_init()

Signed-off-by: Balasubramanian Manoharan 
---
 include/odp/api/classification.h | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/include/odp/api/classification.h b/include/odp/api/classification.h
index 725e1ab..18572ad 100644
--- a/include/odp/api/classification.h
+++ b/include/odp/api/classification.h
@@ -37,7 +37,7 @@ extern "C" {
 
 /**
  * @def ODP_COS_INVALID
- * This value is returned from odp_cos_create() on failure,
+ * This value is returned from odp_cls_cos_create() on failure,
  * May also be used as a sink class of service that
  * results in packets being discarded.
  */
@@ -60,9 +60,9 @@ extern "C" {
  */
 
 /**
- * Class-of-service packet drop policies
+ * class of service packet drop policies
  */
-typedef enum odp_cos_drop {
+typedef enum odp_cls_drop {
ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool policy */
 } odp_drop_e;
@@ -89,14 +89,35 @@ typedef enum odp_cos_hdr_flow_fields {
 } odp_cos_hdr_flow_fields_e;
 
 /**
+ * Class of service parameters
+ * Used to communicate class of service creation options
+ */
+typedef struct odp_cls_cos_param {
+   odp_queue_t queue;  /**< Queue associated with CoS */
+   odp_pool_t pool;/**< Pool associated with CoS */
+   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
+} odp_cls_cos_param_t;
+
+/**
+ * Initialize class of service parameters
+ *
+ * Initialize an odp_cls_cos_param_t to its default value for all fields
+ *
+ * @param param   Address of the odp_cls_cos_param_t to be initialized
+ */
+void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
+
+/**
  * Create a class-of-service
  *
  * @param[in]  nameString intended for debugging purposes.
  *
- * @return Class of service instance identifier
+ * @param[in]  param   class of service parameters
+ *
+ * @retval class of service handle
  * @retval ODP_COS_INVALID on failure.
  */
-odp_cos_t odp_cos_create(const char *name);
+odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t *param);
 
 /**
  * Discard a class-of-service along with all its associated resources
-- 
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: pktio: fix start_stop and send_failure tests

[Elo, Matias (Nokia - FI/Espoo)]

Can be discarded. Already fixed in Ilya Maximets' patch.

-Matias

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT 
> Matias
> Elo
> Sent: Tuesday, December 08, 2015 12:37 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] validation: pktio: fix start_stop and send_failure 
> tests
> 
> In both tests set MAC addresses to test packets to enable
> testing with real pktio interfaces.
> 
> In pktio_test_send_failure() don't check for errno values
> as they are not defined in the API.
> 
> Signed-off-by: Matias Elo 
> ---
>  test/validation/pktio/pktio.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
> index 50a6d8a..4ded924 100644
> --- a/test/validation/pktio/pktio.c
> +++ b/test/validation/pktio/pktio.c
> @@ -695,6 +695,7 @@ void pktio_test_inq(void)
>  static void pktio_test_start_stop(void)
>  {
>   odp_pktio_t pktio[MAX_NUM_IFACES];
> + pktio_info_t pktio_info[MAX_NUM_IFACES];
>   odp_packet_t pkt;
>   odp_event_t tx_ev[1000];
>   odp_event_t ev;
> @@ -705,6 +706,7 @@ static void pktio_test_start_stop(void)
>   for (i = 0; i < num_ifaces; i++) {
>   pktio[i] = create_pktio(i, ODP_PKTIN_MODE_SCHED);
>   CU_ASSERT_FATAL(pktio[i] != ODP_PKTIO_INVALID);
> + pktio_info[i].id = pktio[i];
>   create_inq(pktio[i],  ODP_QUEUE_TYPE_SCHED);
>   }
> 
> @@ -724,6 +726,8 @@ static void pktio_test_start_stop(void)
>   if (pkt == ODP_PACKET_INVALID)
>   break;
>   pktio_init_packet(pkt);
> + pktio_pkt_set_macs(pkt, _info[0],
> +_info[1]);
>   tx_ev[alloc] = odp_packet_to_event(pkt);
>   }
> 
> @@ -775,6 +779,9 @@ static void pktio_test_start_stop(void)
>   if (pkt == ODP_PACKET_INVALID)
>   break;
>   pktio_init_packet(pkt);
> + if (num_ifaces > 1)
> + pktio_pkt_set_macs(pkt, _info[0],
> +_info[1]);
>   tx_ev[alloc] = odp_packet_to_event(pkt);
>   }
> 
> @@ -849,13 +856,14 @@ static void pktio_test_send_failure(void)
>   odp_pool_param_t pool_params;
>   odp_pool_t pkt_pool;
>   int long_pkt_idx = TX_BATCH_LEN / 2;
> - pktio_info_t info_rx;
> + pktio_info_t info_tx, info_rx;
> 
>   pktio_tx = create_pktio(0, ODP_PKTIN_MODE_RECV);
>   if (pktio_tx == ODP_PKTIO_INVALID) {
>   CU_FAIL("failed to open pktio");
>   return;
>   }
> + info_tx.id   = pktio_tx;
> 
>   /* read the MTU from the transmit interface */
>   mtu = odp_pktio_mtu(pktio_tx);
> @@ -880,6 +888,10 @@ static void pktio_test_send_failure(void)
>   } else {
>   pktio_rx = pktio_tx;
>   }
> + info_rx.id   = pktio_rx;
> + info_rx.outq = ODP_QUEUE_INVALID;
> + info_rx.inq  = ODP_QUEUE_INVALID;
> + info_rx.in_mode = ODP_PKTIN_MODE_RECV;
> 
>   /* generate a batch of packets with a single overly long packet
>* in the middle */
> @@ -898,6 +910,8 @@ static void pktio_test_send_failure(void)
>   pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
>   if (pkt_seq[i] == TEST_SEQ_INVALID)
>   break;
> +
> + pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
>   }
>   alloc_pkts = i;
> 
> @@ -907,12 +921,6 @@ static void pktio_test_send_failure(void)
>   odp_errno_zero();
>   ret = odp_pktio_send(pktio_tx, pkt_tbl, TX_BATCH_LEN);
>   CU_ASSERT(ret == long_pkt_idx);
> - CU_ASSERT(odp_errno() == 0);
> -
> - info_rx.id   = pktio_rx;
> - info_rx.outq = ODP_QUEUE_INVALID;
> - info_rx.inq  = ODP_QUEUE_INVALID;
> - info_rx.in_mode = ODP_PKTIN_MODE_RECV;
> 
>   for (i = 0; i < ret; ++i) {
>   pkt_tbl[i] = wait_for_packet(_rx, pkt_seq[i],
> @@ -929,9 +937,8 @@ static void pktio_test_send_failure(void)
>_tbl[long_pkt_idx],
>TX_BATCH_LEN - long_pkt_idx);
>   CU_ASSERT(ret == -1);
> - CU_ASSERT(odp_errno() != 0);
>   } else {
> - CU_FAIL("failed to receive transmitted packets\n");
> + CU_FAIL("failed to receive transmitted packets");
>   }
> 
>   /* now reduce the size of the long packet and attempt to send
> @@ -942,6 +949,7 @@ static void pktio_test_send_failure(void)
>PKT_LEN_NORMAL);
>   pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
>   CU_ASSERT_FATAL(pkt_seq[i] != 

Re: [lng-odp] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Stuart Haslam]

On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
> Creates a new pktio type that allows for creating and
> sending/receiving packets through TAP interface.
> It is intended for use as a simple conventional communication
> method between applications that use kernel network stack
> (ping, ssh, iperf, etc.) and ODP applications for the purpose
> of functional testing and can be used as it is with some
> of the existing example applications.
> 
> To use this interface the name passed to odp_pktio_open() must
> begin with "tap:" and be in the format:
> 
>  tap:iface
> 
>iface   the name of TAP device to be created.
> 
> TUN/TAP kernel module should be loaded to use this pktio.
> There should be no device named 'iface' in the system.
> The total length of the 'iface' is limited by IF_NAMESIZE.
> 
> Signed-off-by: Ilya Maximets 
> ---
>  platform/linux-generic/Makefile.am |   2 +
>  .../linux-generic/include/odp_packet_io_internal.h |   3 +
>  platform/linux-generic/include/odp_packet_tap.h|  21 ++
>  platform/linux-generic/pktio/io_ops.c  |   1 +
>  platform/linux-generic/pktio/tap.c | 317 
> +
>  5 files changed, 344 insertions(+)
>  create mode 100644 platform/linux-generic/include/odp_packet_tap.h
>  create mode 100644 platform/linux-generic/pktio/tap.c
> 
> diff --git a/platform/linux-generic/Makefile.am 
> b/platform/linux-generic/Makefile.am
> index 70bd8fe..4639ebc 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -92,6 +92,7 @@ noinst_HEADERS = \
> ${srcdir}/include/odp_packet_io_queue.h \
> ${srcdir}/include/odp_packet_netmap.h \
> ${srcdir}/include/odp_packet_socket.h \
> +   ${srcdir}/include/odp_packet_tap.h \
> ${srcdir}/include/odp_pool_internal.h \
> ${srcdir}/include/odp_queue_internal.h \
> ${srcdir}/include/odp_schedule_internal.h \
> @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
>  pktio/netmap.c \
>  pktio/socket.c \
>  pktio/socket_mmap.c \
> +pktio/tap.c \
>  odp_pool.c \
>  odp_queue.c \
>  odp_rwlock.c \
> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
> b/platform/linux-generic/include/odp_packet_io_internal.h
> index 1a1118c..de29557 100644
> --- a/platform/linux-generic/include/odp_packet_io_internal.h
> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
> @@ -22,6 +22,7 @@ extern "C" {
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -78,6 +79,7 @@ struct pktio_entry {
>  #ifdef HAVE_PCAP
>   pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
>  #endif
> + pkt_tap_t pkt_tap;  /**< using TAP for IO */
>   };
>   enum {
>   STATE_START = 0,
> @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
>  #ifdef HAVE_PCAP
>  extern const pktio_if_ops_t pcap_pktio_ops;
>  #endif
> +extern const pktio_if_ops_t tap_pktio_ops;
>  extern const pktio_if_ops_t * const pktio_if_ops[];
>  
>  #ifdef __cplusplus
> diff --git a/platform/linux-generic/include/odp_packet_tap.h 
> b/platform/linux-generic/include/odp_packet_tap.h
> new file mode 100644
> index 000..7877586
> --- /dev/null
> +++ b/platform/linux-generic/include/odp_packet_tap.h
> @@ -0,0 +1,21 @@
> +/* Copyright (c) 2015, Ilya Maximets 
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#ifndef ODP_PACKET_TAP_H_
> +#define ODP_PACKET_TAP_H_
> +
> +#include 
> +
> +typedef struct {
> + int fd; /**< file descriptor for tap interface*/
> + int skfd;   /**< socket descriptor */
> + uint32_t mtu;   /**< cached mtu */
> + unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side (not a
> +  MAC address of kernel interface)*/
> + odp_pool_t pool;/**< pool to alloc packets from */
> +} pkt_tap_t;
> +
> +#endif
> diff --git a/platform/linux-generic/pktio/io_ops.c 
> b/platform/linux-generic/pktio/io_ops.c
> index 3b344e6..1933abc 100644
> --- a/platform/linux-generic/pktio/io_ops.c
> +++ b/platform/linux-generic/pktio/io_ops.c
> @@ -18,6 +18,7 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
>  #ifdef HAVE_PCAP
>   _pktio_ops,
>  #endif
> + _pktio_ops,
>   _mmap_pktio_ops,
>   _mmsg_pktio_ops,
>   NULL
> diff --git a/platform/linux-generic/pktio/tap.c 
> b/platform/linux-generic/pktio/tap.c
> new file mode 100644
> index 000..b11e64f
> --- /dev/null
> +++ b/platform/linux-generic/pktio/tap.c
> @@ -0,0 +1,317 @@
> +/* Copyright 

[lng-odp] [PATCH] validation: pktio: fix start_stop and send_failure tests

[Matias Elo]

In both tests set MAC addresses to test packets to enable
testing with real pktio interfaces.

In pktio_test_send_failure() don't check for errno values
as they are not defined in the API.

Signed-off-by: Matias Elo 
---
 test/validation/pktio/pktio.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
index 50a6d8a..4ded924 100644
--- a/test/validation/pktio/pktio.c
+++ b/test/validation/pktio/pktio.c
@@ -695,6 +695,7 @@ void pktio_test_inq(void)
 static void pktio_test_start_stop(void)
 {
odp_pktio_t pktio[MAX_NUM_IFACES];
+   pktio_info_t pktio_info[MAX_NUM_IFACES];
odp_packet_t pkt;
odp_event_t tx_ev[1000];
odp_event_t ev;
@@ -705,6 +706,7 @@ static void pktio_test_start_stop(void)
for (i = 0; i < num_ifaces; i++) {
pktio[i] = create_pktio(i, ODP_PKTIN_MODE_SCHED);
CU_ASSERT_FATAL(pktio[i] != ODP_PKTIO_INVALID);
+   pktio_info[i].id = pktio[i];
create_inq(pktio[i],  ODP_QUEUE_TYPE_SCHED);
}
 
@@ -724,6 +726,8 @@ static void pktio_test_start_stop(void)
if (pkt == ODP_PACKET_INVALID)
break;
pktio_init_packet(pkt);
+   pktio_pkt_set_macs(pkt, _info[0],
+  _info[1]);
tx_ev[alloc] = odp_packet_to_event(pkt);
}
 
@@ -775,6 +779,9 @@ static void pktio_test_start_stop(void)
if (pkt == ODP_PACKET_INVALID)
break;
pktio_init_packet(pkt);
+   if (num_ifaces > 1)
+   pktio_pkt_set_macs(pkt, _info[0],
+  _info[1]);
tx_ev[alloc] = odp_packet_to_event(pkt);
}
 
@@ -849,13 +856,14 @@ static void pktio_test_send_failure(void)
odp_pool_param_t pool_params;
odp_pool_t pkt_pool;
int long_pkt_idx = TX_BATCH_LEN / 2;
-   pktio_info_t info_rx;
+   pktio_info_t info_tx, info_rx;
 
pktio_tx = create_pktio(0, ODP_PKTIN_MODE_RECV);
if (pktio_tx == ODP_PKTIO_INVALID) {
CU_FAIL("failed to open pktio");
return;
}
+   info_tx.id   = pktio_tx;
 
/* read the MTU from the transmit interface */
mtu = odp_pktio_mtu(pktio_tx);
@@ -880,6 +888,10 @@ static void pktio_test_send_failure(void)
} else {
pktio_rx = pktio_tx;
}
+   info_rx.id   = pktio_rx;
+   info_rx.outq = ODP_QUEUE_INVALID;
+   info_rx.inq  = ODP_QUEUE_INVALID;
+   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
 
/* generate a batch of packets with a single overly long packet
 * in the middle */
@@ -898,6 +910,8 @@ static void pktio_test_send_failure(void)
pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
if (pkt_seq[i] == TEST_SEQ_INVALID)
break;
+
+   pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
}
alloc_pkts = i;
 
@@ -907,12 +921,6 @@ static void pktio_test_send_failure(void)
odp_errno_zero();
ret = odp_pktio_send(pktio_tx, pkt_tbl, TX_BATCH_LEN);
CU_ASSERT(ret == long_pkt_idx);
-   CU_ASSERT(odp_errno() == 0);
-
-   info_rx.id   = pktio_rx;
-   info_rx.outq = ODP_QUEUE_INVALID;
-   info_rx.inq  = ODP_QUEUE_INVALID;
-   info_rx.in_mode = ODP_PKTIN_MODE_RECV;
 
for (i = 0; i < ret; ++i) {
pkt_tbl[i] = wait_for_packet(_rx, pkt_seq[i],
@@ -929,9 +937,8 @@ static void pktio_test_send_failure(void)
 _tbl[long_pkt_idx],
 TX_BATCH_LEN - long_pkt_idx);
CU_ASSERT(ret == -1);
-   CU_ASSERT(odp_errno() != 0);
} else {
-   CU_FAIL("failed to receive transmitted packets\n");
+   CU_FAIL("failed to receive transmitted packets");
}
 
/* now reduce the size of the long packet and attempt to send
@@ -942,6 +949,7 @@ static void pktio_test_send_failure(void)
 PKT_LEN_NORMAL);
pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
CU_ASSERT_FATAL(pkt_seq[i] != TEST_SEQ_INVALID);
+   pktio_pkt_set_macs(pkt_tbl[i], _tx, _rx);
ret = odp_pktio_send(pktio_tx, _tbl[i], TX_BATCH_LEN - i);
CU_ASSERT_FATAL(ret == (TX_BATCH_LEN - i));
 
-- 
1.9.1

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local time to be monotonic

[Savolainen, Petri (Nokia - FI/Espoo)]

OK, it's the 32 bit build again (which was not tested).

I have had trouble lately to install 32 bit libraries of OpenSSL into Ubuntu, 
which makes it hard to test linux-generic with -m32. So currently, I'm not 
testing 32 bit build either.

-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Savolainen, Petri (Nokia - FI/Espoo)
> Sent: Tuesday, December 08, 2015 1:02 PM
> To: EXT Maxim Uvarov; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local
> time to be monotonic
> 
> Agree, it's a bug and the test would spin forever. Is this a build error?
> Ivan should have built the code successfully before sending... or do we
> have different warning levels enabled on different make targets?
> 
> -Petri
> 
> > -Original Message-
> > From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> > Sent: Tuesday, December 08, 2015 12:41 PM
> > To: lng-odp@lists.linaro.org; Petri Savolainen
> > Subject: Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local
> > time to be monotonic
> >
> > That patch serries looks ok, instead of one overrun of 32 bit counter.
> > I can fix it just in place.
> >
> > Petri, agree?
> >
> > time.c: In function 'time_test_monotony':
> > time.c:60:15: error: comparison is always true due to limited range of
> > data type [-Werror=type-limits]
> >while (count < BUSY_LOOP_CNT_LONG) {
> >
> > --- a/test/validation/time/time.c
> > +++ b/test/validation/time/time.c
> > @@ -45,7 +45,7 @@ void time_test_odp_conversion(void)
> >
> >   void time_test_monotony(void)
> >   {
> > -   volatile unsigned long count = 0;
> > +   volatile uint64_t count = 0;
> >  odp_time_t t1, t2, t3;
> >  uint64_t ns1, ns2, ns3;
> >
> > Maxim.
> >
> >
> > On 12/04/2015 20:51, Ivan Khoronzhuk wrote:
> > > This series is intended to modify time API to be used as monotonic
> wall
> > > time in order to simplify time API usage and create prerequisites for
> > > adding global time API.
> > >
> > > Since v6:
> > > - changed patch order a little to pass validation tests
> > > - fixed issue with pktio perf test
> > > - no functional changes
> > >
> > > Since v5:
> > >linux-generic: align with new wall time API
> > > - deleted _odp prefix for local functions
> > > - avoided modulo operation
> > > - used common global var for start time
> > >
> > > Since v3:
> > > - "api: time: make odp_local_time to be monotonic wall time"
> > >splitted on;
> > >"linux-generic: align with new wall time API"
> > >"test/example: use local time API as wall time"
> > > - increased BUSY_LOOP_CNT to fit in resolution and 4+ sec
> > >
> > > Since v2:
> > > - removed patch changing type of ODP_TIME_*
> > > - added new patch:
> > >test: performance: pktio: don't use direct arithmetic operations
> with
> > >  odp_time_t
> > > - added new patch:
> > >performance: sched: use ODP time API instead of clock_gettime
> > > - combined monotonic and wall time patches
> > > - removed odp_time_local_val() and odp_time_val_to_ns()
> > > - replaced terms monotonic and wall in API desc
> > >
> > > Since v1:
> > > - corrected name of the series to be api-next
> > > - use thread local for holding start time
> > >
> > > Ivan Khoronzhuk (9):
> > >validation: time: don't assign int directly to odp_time_t
> > >test: performance: pktio: don't use direct arithmetic operations
> with
> > >  odp_time_t
> > >linux-generic: schedule: use schedule time in ns
> > >linux-generic: odp_time: don't use cpu cycle API to get time
> > >performance: sched: use ODP time API instead of clock_gettime
> > >api: time: make odp_local_time to be monotonic wall time
> > >validation: time: align tests with current time API
> > >linux-generic: align with new wall time API
> > >test/example: use local time API as wall time
> > >
> > >   example/generator/odp_generator.c  |  10 +-
> > >   include/odp/api/time.h |   3 +-
> > >   platform/linux-generic/Makefile.am |   1 -
> > >   .../linux-generic/include/odp/plat/time_types.h|   6 +-
> > >   platform/linux-generic/include/odp_cpu_internal.h  |  29 ---
> > >   platform/linux-generic/include/odp_internal.h  |   2 +
> > >   platform/linux-generic/odp_cpu.c   |   6 +-
> > >   platform/linux-generic/odp_init.c  |   4 +
> > >   platform/linux-generic/odp_schedule.c  |  18 +-
> > >   platform/linux-generic/odp_time.c  | 112 +++---
> > >   test/performance/odp_pktio_perf.c  |  24 +--
> > >   test/performance/odp_scheduling.c  |  37 +---
> > >   test/validation/pktio/pktio.c  |  21 +-
> > >   test/validation/time/time.c| 228
> > ++---
> > >   test/validation/time/time.h|   7 +-
> > >   15 files changed, 346 

Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local time to be monotonic

[Maxim Uvarov]

Merged,
Maxim.

On 12/08/2015 14:11, Savolainen, Petri (Nokia - FI/Espoo) wrote:

OK, it's the 32 bit build again (which was not tested).

I have had trouble lately to install 32 bit libraries of OpenSSL into Ubuntu, 
which makes it hard to test linux-generic with -m32. So currently, I'm not 
testing 32 bit build either.

-Petri


Yes it's test for 32 bit. I use odp-check scripts. But I don't remember 
if I installed something or it did it automatically.





-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Savolainen, Petri (Nokia - FI/Espoo)
Sent: Tuesday, December 08, 2015 1:02 PM
To: EXT Maxim Uvarov; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local
time to be monotonic

Agree, it's a bug and the test would spin forever. Is this a build error?
Ivan should have built the code successfully before sending... or do we
have different warning levels enabled on different make targets?

-Petri


-Original Message-
From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
Sent: Tuesday, December 08, 2015 12:41 PM
To: lng-odp@lists.linaro.org; Petri Savolainen
Subject: Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local
time to be monotonic

That patch serries looks ok, instead of one overrun of 32 bit counter.
I can fix it just in place.

Petri, agree?

time.c: In function 'time_test_monotony':
time.c:60:15: error: comparison is always true due to limited range of
data type [-Werror=type-limits]
while (count < BUSY_LOOP_CNT_LONG) {

--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -45,7 +45,7 @@ void time_test_odp_conversion(void)

   void time_test_monotony(void)
   {
-   volatile unsigned long count = 0;
+   volatile uint64_t count = 0;
  odp_time_t t1, t2, t3;
  uint64_t ns1, ns2, ns3;

Maxim.


On 12/04/2015 20:51, Ivan Khoronzhuk wrote:

This series is intended to modify time API to be used as monotonic

wall

time in order to simplify time API usage and create prerequisites for
adding global time API.

Since v6:
- changed patch order a little to pass validation tests
- fixed issue with pktio perf test
- no functional changes

Since v5:
linux-generic: align with new wall time API
- deleted _odp prefix for local functions
- avoided modulo operation
- used common global var for start time

Since v3:
- "api: time: make odp_local_time to be monotonic wall time"
splitted on;
"linux-generic: align with new wall time API"
"test/example: use local time API as wall time"
- increased BUSY_LOOP_CNT to fit in resolution and 4+ sec

Since v2:
- removed patch changing type of ODP_TIME_*
- added new patch:
test: performance: pktio: don't use direct arithmetic operations

with

  odp_time_t
- added new patch:
performance: sched: use ODP time API instead of clock_gettime
- combined monotonic and wall time patches
- removed odp_time_local_val() and odp_time_val_to_ns()
- replaced terms monotonic and wall in API desc

Since v1:
- corrected name of the series to be api-next
- use thread local for holding start time

Ivan Khoronzhuk (9):
validation: time: don't assign int directly to odp_time_t
test: performance: pktio: don't use direct arithmetic operations

with

  odp_time_t
linux-generic: schedule: use schedule time in ns
linux-generic: odp_time: don't use cpu cycle API to get time
performance: sched: use ODP time API instead of clock_gettime
api: time: make odp_local_time to be monotonic wall time
validation: time: align tests with current time API
linux-generic: align with new wall time API
test/example: use local time API as wall time

   example/generator/odp_generator.c  |  10 +-
   include/odp/api/time.h |   3 +-
   platform/linux-generic/Makefile.am |   1 -
   .../linux-generic/include/odp/plat/time_types.h|   6 +-
   platform/linux-generic/include/odp_cpu_internal.h  |  29 ---
   platform/linux-generic/include/odp_internal.h  |   2 +
   platform/linux-generic/odp_cpu.c   |   6 +-
   platform/linux-generic/odp_init.c  |   4 +
   platform/linux-generic/odp_schedule.c  |  18 +-
   platform/linux-generic/odp_time.c  | 112 +++---
   test/performance/odp_pktio_perf.c  |  24 +--
   test/performance/odp_scheduling.c  |  37 +---
   test/validation/pktio/pktio.c  |  21 +-
   test/validation/time/time.c| 228

++---

   test/validation/time/time.h|   7 +-
   15 files changed, 346 insertions(+), 162 deletions(-)
   delete mode 100644 platform/linux-generic/include/odp_cpu_internal.h


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] queue: fix memory corruption in reorder_enq()

[Maxim Uvarov]

Patch merged,
Maxim.

On 12/07/2015 21:44, Zoltan Kiss wrote:



On 07/12/15 17:52, Bill Fischofer wrote:

You're seeing this because in linux-dpdk the next field of the
odp_buffer_hdr_t is not at offset 0.  In linux-generic next is at offset
zero so this code is slightly more efficient.  So this change really
should be in the linux-dpdk version of this code rather than 
linux-generic.


I see. Well, it's very obscure.

Btw. I don't see why we have origin_qe->s.reorder_tail: we never use 
its value, and even if we would have the tail member of the linked 
list, it has little use as it is not double-linked.




However the performance penalty is minor if you want to keep a common
linux-generic/linux-dpdk version of this file, so:

On Mon, Dec 7, 2015 at 11:36 AM, Zoltan Kiss > wrote:

Maxim, Bill, please check this ASAP, and if feasible commit it to
master, it blocks ODP-DPDK upgrade to 1.5

Zoli


On 07/12/15 17:33, Zoltan Kiss wrote:

reorder_prev is set to the address of the pointer
origin_qe->s.reorder_head,
which is wrong. If the linked list was empty, that won't be
corrected, and
reorder_prev->next points to the adjacent queue entry's status
field. If that
entry is used, that queue's metadata will be corrupted.
This was found by running the chaos scheduler test with 
ODP-DPDK.


Signed-off-by: Zoltan Kiss >


Reviewed-by: Bill Fischofer >

---
diff --git a/platform/linux-generic/include/odp_queue_internal.h
b/platform/linux-generic/include/odp_queue_internal.h
index a70044b..1cc0ed2 100644
--- a/platform/linux-generic/include/odp_queue_internal.h
+++ b/platform/linux-generic/include/odp_queue_internal.h
@@ -212,8 +212,7 @@ static inline void reorder_enq(queue_entry_t
*queue,
int sustain)
   {
 odp_buffer_hdr_t *reorder_buf = 
origin_qe->s.reorder_head;

-   odp_buffer_hdr_t *reorder_prev =
-   (odp_buffer_hdr_t *)(void
*)_qe->s.reorder_head;
+   odp_buffer_hdr_t *reorder_prev = NULL;

 while (reorder_buf && order >= reorder_buf->order) {
 reorder_prev = reorder_buf;
@@ -221,7 +220,12 @@ static inline void
reorder_enq(queue_entry_t *queue,
 }

 buf_hdr->next = reorder_buf;
-   reorder_prev->next = buf_hdr;
+
+   if (reorder_prev)
+   reorder_prev->next = buf_hdr;
+   else
+   origin_qe->s.reorder_head = buf_hdr;
+

 if (!reorder_buf)
 origin_qe->s.reorder_tail = buf_hdr;




___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Tuesday, December 08, 2015 10:44 AM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use
> odp_hash_crc32c() api to avoid arch issues
> 
> On 12/08/2015 10:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > Bill,
> >
> > hash_tbl_entry is now uintptr_t, which is 64 bits on a 64 bit build and
> 32 bits on a 32 bit build. These shifts and all other lines  that expect
> that hash_tbl_entry (pointer size) is 64 bits should be updated also.
> >
> > -Petri
> >
> 
> Yes, that is what I said before.  For now we can go with simple using 64
> bit hash entries for 32 bit case also.
> Where 6 upper bits will be for defining first or secondary hash and it's
> size. And all lower 32 for address pointer.
> I.e. 26 bits will be lost.
> 
> #define PRIMARY_HASH_TBL_SIZE(16 * 1024)
> 26 * PRIMARY_HASH_TBL_SIZE = 425984 = 53248 bytes = 13 pages;
> 
> #define SECONDARY_HASH_TBL_SIZE  128
> 26 * SECONDARY_HASH_TBL_SIZE = 3328 = 416 bytes
> 
> So we lost for 32 bits some memory but code has to work in the same way
> as for 64 bits.
> After that if memory efficient fix will be needed for somebody than he
> can fix it.
> Or we will reuse some odp hash table api instead of odp_name_table.c.
> 
> So for now I would do quick fix with some comment that there is unused
> memory for 32 bit case.
> 
> --- a/platform/linux-generic/odp_name_table.c
> +++ b/platform/linux-generic/odp_name_table.c
> @@ -93,7 +93,7 @@ typedef struct {
>* NOT zero then this values points to a (linked list of)
> name_table_entry_t
>* records AND the bottom 6 bits are the length of this list.
>*/
> -typedef uintptr_t hash_tbl_entry_t;
> +typedef uint64_t hash_tbl_entry_t;
> 
> 
> BR,
> Maxim.


odp_name_table.c: In function 'make_hash_tbl_entry':
odp_name_table.c:570:20: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
  hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;


static hash_tbl_entry_t make_hash_tbl_entry(name_tbl_entry_t *name_tbl_entry,
uint32_t  entry_cnt)
{
hash_tbl_entry_t hash_tbl_entry;
uint32_t new_entry_cnt;

new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
hash_tbl_entry  = (hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
hash_tbl_entry &= ~0x3F;
hash_tbl_entry |= new_entry_cnt;
return hash_tbl_entry;
}


And compiler is still happy with the casts? Maybe the casting issue was 
actually caused by removal of the uintptr_t cast above.

-Petri

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Maxim Uvarov]

On 12/08/2015 13:09, Savolainen, Petri (Nokia - FI/Espoo) wrote:



-Original Message-
From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
Sent: Tuesday, December 08, 2015 10:44 AM
To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use
odp_hash_crc32c() api to avoid arch issues

On 12/08/2015 10:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Bill,

hash_tbl_entry is now uintptr_t, which is 64 bits on a 64 bit build and

32 bits on a 32 bit build. These shifts and all other lines  that expect
that hash_tbl_entry (pointer size) is 64 bits should be updated also.

-Petri


Yes, that is what I said before.  For now we can go with simple using 64
bit hash entries for 32 bit case also.
Where 6 upper bits will be for defining first or secondary hash and it's
size. And all lower 32 for address pointer.
I.e. 26 bits will be lost.

#define PRIMARY_HASH_TBL_SIZE(16 * 1024)
26 * PRIMARY_HASH_TBL_SIZE = 425984 = 53248 bytes = 13 pages;

#define SECONDARY_HASH_TBL_SIZE  128
26 * SECONDARY_HASH_TBL_SIZE = 3328 = 416 bytes

So we lost for 32 bits some memory but code has to work in the same way
as for 64 bits.
After that if memory efficient fix will be needed for somebody than he
can fix it.
Or we will reuse some odp hash table api instead of odp_name_table.c.

So for now I would do quick fix with some comment that there is unused
memory for 32 bit case.

--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -93,7 +93,7 @@ typedef struct {
* NOT zero then this values points to a (linked list of)
name_table_entry_t
* records AND the bottom 6 bits are the length of this list.
*/
-typedef uintptr_t hash_tbl_entry_t;
+typedef uint64_t hash_tbl_entry_t;


BR,
Maxim.


odp_name_table.c: In function 'make_hash_tbl_entry':
odp_name_table.c:570:20: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
   hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;


static hash_tbl_entry_t make_hash_tbl_entry(name_tbl_entry_t *name_tbl_entry,
uint32_t  entry_cnt)
{
hash_tbl_entry_t hash_tbl_entry;
uint32_t new_entry_cnt;

new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
hash_tbl_entry  = (hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
hash_tbl_entry &= ~0x3F;
hash_tbl_entry |= new_entry_cnt;
return hash_tbl_entry;
}


And compiler is still happy with the casts? Maybe the casting issue was 
actually caused by removal of the uintptr_t cast above.

-Petri

Petri, Looks like you did not apply that patch. If you apply it and do 
change to uint64_t everything compiles.


Maxim.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local time to be monotonic

[Savolainen, Petri (Nokia - FI/Espoo)]

Agree, it's a bug and the test would spin forever. Is this a build error? Ivan 
should have built the code successfully before sending... or do we have 
different warning levels enabled on different make targets?

-Petri

> -Original Message-
> From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Tuesday, December 08, 2015 12:41 PM
> To: lng-odp@lists.linaro.org; Petri Savolainen
> Subject: Re: [lng-odp] [API-NEXT PATCH v7 0/9] api: time: update local
> time to be monotonic
> 
> That patch serries looks ok, instead of one overrun of 32 bit counter.
> I can fix it just in place.
> 
> Petri, agree?
> 
> time.c: In function 'time_test_monotony':
> time.c:60:15: error: comparison is always true due to limited range of
> data type [-Werror=type-limits]
>while (count < BUSY_LOOP_CNT_LONG) {
> 
> --- a/test/validation/time/time.c
> +++ b/test/validation/time/time.c
> @@ -45,7 +45,7 @@ void time_test_odp_conversion(void)
> 
>   void time_test_monotony(void)
>   {
> -   volatile unsigned long count = 0;
> +   volatile uint64_t count = 0;
>  odp_time_t t1, t2, t3;
>  uint64_t ns1, ns2, ns3;
> 
> Maxim.
> 
> 
> On 12/04/2015 20:51, Ivan Khoronzhuk wrote:
> > This series is intended to modify time API to be used as monotonic wall
> > time in order to simplify time API usage and create prerequisites for
> > adding global time API.
> >
> > Since v6:
> > - changed patch order a little to pass validation tests
> > - fixed issue with pktio perf test
> > - no functional changes
> >
> > Since v5:
> >linux-generic: align with new wall time API
> > - deleted _odp prefix for local functions
> > - avoided modulo operation
> > - used common global var for start time
> >
> > Since v3:
> > - "api: time: make odp_local_time to be monotonic wall time"
> >splitted on;
> >"linux-generic: align with new wall time API"
> >"test/example: use local time API as wall time"
> > - increased BUSY_LOOP_CNT to fit in resolution and 4+ sec
> >
> > Since v2:
> > - removed patch changing type of ODP_TIME_*
> > - added new patch:
> >test: performance: pktio: don't use direct arithmetic operations with
> >  odp_time_t
> > - added new patch:
> >performance: sched: use ODP time API instead of clock_gettime
> > - combined monotonic and wall time patches
> > - removed odp_time_local_val() and odp_time_val_to_ns()
> > - replaced terms monotonic and wall in API desc
> >
> > Since v1:
> > - corrected name of the series to be api-next
> > - use thread local for holding start time
> >
> > Ivan Khoronzhuk (9):
> >validation: time: don't assign int directly to odp_time_t
> >test: performance: pktio: don't use direct arithmetic operations with
> >  odp_time_t
> >linux-generic: schedule: use schedule time in ns
> >linux-generic: odp_time: don't use cpu cycle API to get time
> >performance: sched: use ODP time API instead of clock_gettime
> >api: time: make odp_local_time to be monotonic wall time
> >validation: time: align tests with current time API
> >linux-generic: align with new wall time API
> >test/example: use local time API as wall time
> >
> >   example/generator/odp_generator.c  |  10 +-
> >   include/odp/api/time.h |   3 +-
> >   platform/linux-generic/Makefile.am |   1 -
> >   .../linux-generic/include/odp/plat/time_types.h|   6 +-
> >   platform/linux-generic/include/odp_cpu_internal.h  |  29 ---
> >   platform/linux-generic/include/odp_internal.h  |   2 +
> >   platform/linux-generic/odp_cpu.c   |   6 +-
> >   platform/linux-generic/odp_init.c  |   4 +
> >   platform/linux-generic/odp_schedule.c  |  18 +-
> >   platform/linux-generic/odp_time.c  | 112 +++---
> >   test/performance/odp_pktio_perf.c  |  24 +--
> >   test/performance/odp_scheduling.c  |  37 +---
> >   test/validation/pktio/pktio.c  |  21 +-
> >   test/validation/time/time.c| 228
> ++---
> >   test/validation/time/time.h|   7 +-
> >   15 files changed, 346 insertions(+), 162 deletions(-)
> >   delete mode 100644 platform/linux-generic/include/odp_cpu_internal.h
> >

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Bill Fischofer]

The cast plus the uint64_t typedef is the v1 patch.  So is that one now
good?

On Tue, Dec 8, 2015 at 4:45 AM, Maxim Uvarov 
wrote:

> On 12/08/2015 13:09, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>
>>
>> -Original Message-
>>> From: EXT Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>>> Sent: Tuesday, December 08, 2015 10:44 AM
>>> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] [API-NEXT PATCHv2] linux-generic: tm: use
>>> odp_hash_crc32c() api to avoid arch issues
>>>
>>> On 12/08/2015 10:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>>
 Bill,

 hash_tbl_entry is now uintptr_t, which is 64 bits on a 64 bit build and

>>> 32 bits on a 32 bit build. These shifts and all other lines  that expect
>>> that hash_tbl_entry (pointer size) is 64 bits should be updated also.
>>>
 -Petri

 Yes, that is what I said before.  For now we can go with simple using 64
>>> bit hash entries for 32 bit case also.
>>> Where 6 upper bits will be for defining first or secondary hash and it's
>>> size. And all lower 32 for address pointer.
>>> I.e. 26 bits will be lost.
>>>
>>> #define PRIMARY_HASH_TBL_SIZE(16 * 1024)
>>> 26 * PRIMARY_HASH_TBL_SIZE = 425984 = 53248 bytes = 13 pages;
>>>
>>> #define SECONDARY_HASH_TBL_SIZE  128
>>> 26 * SECONDARY_HASH_TBL_SIZE = 3328 = 416 bytes
>>>
>>> So we lost for 32 bits some memory but code has to work in the same way
>>> as for 64 bits.
>>> After that if memory efficient fix will be needed for somebody than he
>>> can fix it.
>>> Or we will reuse some odp hash table api instead of odp_name_table.c.
>>>
>>> So for now I would do quick fix with some comment that there is unused
>>> memory for 32 bit case.
>>>
>>> --- a/platform/linux-generic/odp_name_table.c
>>> +++ b/platform/linux-generic/odp_name_table.c
>>> @@ -93,7 +93,7 @@ typedef struct {
>>> * NOT zero then this values points to a (linked list of)
>>> name_table_entry_t
>>> * records AND the bottom 6 bits are the length of this list.
>>> */
>>> -typedef uintptr_t hash_tbl_entry_t;
>>> +typedef uint64_t hash_tbl_entry_t;
>>>
>>>
>>> BR,
>>> Maxim.
>>>
>>
>> odp_name_table.c: In function 'make_hash_tbl_entry':
>> odp_name_table.c:570:20: error: cast from pointer to integer of different
>> size [-Werror=pointer-to-int-cast]
>>hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;
>>
>>
>> static hash_tbl_entry_t make_hash_tbl_entry(name_tbl_entry_t
>> *name_tbl_entry,
>> uint32_t  entry_cnt)
>> {
>> hash_tbl_entry_t hash_tbl_entry;
>> uint32_t new_entry_cnt;
>>
>> new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
>> hash_tbl_entry  = (hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
>> hash_tbl_entry &= ~0x3F;
>> hash_tbl_entry |= new_entry_cnt;
>> return hash_tbl_entry;
>> }
>>
>>
>> And compiler is still happy with the casts? Maybe the casting issue was
>> actually caused by removal of the uintptr_t cast above.
>>
>> -Petri
>>
>> Petri, Looks like you did not apply that patch. If you apply it and do
> change to uint64_t everything compiles.
>
> Maxim.
>
> ___
> 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] [API-NEXT PATCH v3] api: atomic: added atomic_lock_free_u64

[Bill Fischofer]

Can we resolve any outstanding issues with this during today's ODP call?
This has been on the list for a while.

On Tue, Dec 8, 2015 at 1:53 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> ping.
>
> > -Original Message-
> > From: Savolainen, Petri (Nokia - FI/Espoo)
> > Sent: Thursday, November 26, 2015 10:56 AM
> > To: lng-odp@lists.linaro.org
> > Subject: RE: [lng-odp] [API-NEXT PATCH v3] api: atomic: added
> > atomic_lock_free_u64
> >
> > ping.
> >
> > > -Original Message-
> > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> EXT
> > > Petri Savolainen
> > > Sent: Thursday, November 12, 2015 10:30 AM
> > > To: lng-odp@lists.linaro.org
> > > Subject: [lng-odp] [API-NEXT PATCH v3] api: atomic: added
> > > atomic_lock_free_u64
> > >
> > > Platforms may support some uint64 operations lock-free and
> > > others not. For example, inc_64 can be natively supported but
> > > cas_64 (or max_64/min_64) not. User may be able to switch to
> > > 32 bit variables when a 64 bit operation uses locks. The same
> > > atomic operation struture could be used for platform init to guide
> > > lock vs. lock-free implementation (e.g. if cas_64 is never
> > > called, inc_64 can be lock-free).
> > >
> > > Signed-off-by: Petri Savolainen 
> > > ---
> > >  include/odp/api/atomic.h| 48
> > > +
> > >  platform/linux-generic/Makefile.am  |  1 +
> > >  platform/linux-generic/odp_atomic.c | 24 +++
> > >  3 files changed, 73 insertions(+)
> > >  create mode 100644 platform/linux-generic/odp_atomic.c
> > >
> > > diff --git a/include/odp/api/atomic.h b/include/odp/api/atomic.h
> > > index 316f13a..5e897c1 100644
> > > --- a/include/odp/api/atomic.h
> > > +++ b/include/odp/api/atomic.h
> > > @@ -388,6 +388,54 @@ void odp_atomic_add_rls_u32(odp_atomic_u32_t
> *atom,
> > > uint32_t val);
> > >  void odp_atomic_sub_rls_u32(odp_atomic_u32_t *atom, uint32_t val);
> > >
> > >  /**
> > > + * Atomic operations
> > > + *
> > > + * Atomic operations listed in a bit field structure.
> > > + */
> > > +typedef union odp_atomic_op_t {
> > > +   /** Operation flags */
> > > +   struct {
> > > +   uint32_t init  : 1;  /**< Init atomic variable */
> > > +   uint32_t load  : 1;  /**< Atomic load */
> > > +   uint32_t store : 1;  /**< Atomic store */
> > > +   uint32_t fetch_add : 1;  /**< Atomic fetch and add */
> > > +   uint32_t add   : 1;  /**< Atomic add */
> > > +   uint32_t fetch_sub : 1;  /**< Atomic fetch and substract */
> > > +   uint32_t sub   : 1;  /**< Atomic substract */
> > > +   uint32_t fetch_inc : 1;  /**< Atomic fetch and increment */
> > > +   uint32_t inc   : 1;  /**< Atomic increment */
> > > +   uint32_t fetch_dec : 1;  /**< Atomic fetch and decrement */
> > > +   uint32_t dec   : 1;  /**< Atomic decrement */
> > > +   uint32_t min   : 1;  /**< Atomic minimum */
> > > +   uint32_t max   : 1;  /**< Atomic maximum */
> > > +   uint32_t cas   : 1;  /**< Atomic compare and swap */
> > > +   } op;
> > > +
> > > +   /** All bits of the bit field structure.
> > > + * Operation flag mapping is architecture specific. This field can
> > > be
> > > + * used to set/clear all flags, or bitwise operations over the
> > > entire
> > > + * structure. */
> > > +   uint32_t all_bits;
> > > +} odp_atomic_op_t;
> > > +
> > > +/**
> > > + * Query which atomic uint64 operations are lock-free
> > > + *
> > > + * Lock-free implementations have higher performance and scale better
> > > than
> > > + * implementations using locks. User can decide to use e.g. uint32
> > atomic
> > > + * variables instead of uint64 to optimize performance on platforms
> > that
> > > + * implement a performance critical operation using locks.
> > > + *
> > > + * @param atomic_op  Pointer to atomic operation structure for storing
> > > + *   operation flags. All bits are initialized to zero
> > > during
> > > + *   the operation. The parameter is ignored when
> NULL.
> > > + * @retval 0 None of the operations are lock-free
> > > + * @retval 1 Some of the operations are lock-free
> > > + * @retval 2 All operations are lock-free
> > > + */
> > > +int odp_atomic_lock_free_u64(odp_atomic_op_t *atomic_op);
> > > +
> > > +/**
> > >   * @}
> > >   */
> > >
> > > diff --git a/platform/linux-generic/Makefile.am b/platform/linux-
> > > generic/Makefile.am
> > > index a6b6029..0b7234e 100644
> > > --- a/platform/linux-generic/Makefile.am
> > > +++ b/platform/linux-generic/Makefile.am
> > > @@ -151,6 +151,7 @@ noinst_HEADERS = \
> > >   ${srcdir}/Makefile.inc
> > >
> > >  __LIB__libodp_la_SOURCES = \
> > > +  odp_atomic.c \
> > >odp_barrier.c \
> > >odp_buffer.c 

Re: [lng-odp] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Ilya Maximets]

On 08.12.2015 15:16, Stuart Haslam wrote:
> On Tue, Dec 08, 2015 at 02:51:40PM +0300, Ilya Maximets wrote:
>> On 08.12.2015 14:24, Stuart Haslam wrote:
>>> On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
 Creates a new pktio type that allows for creating and
 sending/receiving packets through TAP interface.
 It is intended for use as a simple conventional communication
 method between applications that use kernel network stack
 (ping, ssh, iperf, etc.) and ODP applications for the purpose
 of functional testing and can be used as it is with some
 of the existing example applications.

 To use this interface the name passed to odp_pktio_open() must
 begin with "tap:" and be in the format:

  tap:iface

iface   the name of TAP device to be created.

 TUN/TAP kernel module should be loaded to use this pktio.
 There should be no device named 'iface' in the system.
 The total length of the 'iface' is limited by IF_NAMESIZE.

 Signed-off-by: Ilya Maximets 
 ---
  platform/linux-generic/Makefile.am |   2 +
  .../linux-generic/include/odp_packet_io_internal.h |   3 +
  platform/linux-generic/include/odp_packet_tap.h|  21 ++
  platform/linux-generic/pktio/io_ops.c  |   1 +
  platform/linux-generic/pktio/tap.c | 317 
 +
  5 files changed, 344 insertions(+)
  create mode 100644 platform/linux-generic/include/odp_packet_tap.h
  create mode 100644 platform/linux-generic/pktio/tap.c

 diff --git a/platform/linux-generic/Makefile.am 
 b/platform/linux-generic/Makefile.am
 index 70bd8fe..4639ebc 100644
 --- a/platform/linux-generic/Makefile.am
 +++ b/platform/linux-generic/Makefile.am
 @@ -92,6 +92,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_packet_io_queue.h \
  ${srcdir}/include/odp_packet_netmap.h \
  ${srcdir}/include/odp_packet_socket.h \
 +${srcdir}/include/odp_packet_tap.h \
  ${srcdir}/include/odp_pool_internal.h \
  ${srcdir}/include/odp_queue_internal.h \
  ${srcdir}/include/odp_schedule_internal.h \
 @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
   pktio/netmap.c \
   pktio/socket.c \
   pktio/socket_mmap.c \
 + pktio/tap.c \
   odp_pool.c \
   odp_queue.c \
   odp_rwlock.c \
 diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
 b/platform/linux-generic/include/odp_packet_io_internal.h
 index 1a1118c..de29557 100644
 --- a/platform/linux-generic/include/odp_packet_io_internal.h
 +++ b/platform/linux-generic/include/odp_packet_io_internal.h
 @@ -22,6 +22,7 @@ extern "C" {
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -78,6 +79,7 @@ struct pktio_entry {
  #ifdef HAVE_PCAP
pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
  #endif
 +  pkt_tap_t pkt_tap;  /**< using TAP for IO */
};
enum {
STATE_START = 0,
 @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
  #ifdef HAVE_PCAP
  extern const pktio_if_ops_t pcap_pktio_ops;
  #endif
 +extern const pktio_if_ops_t tap_pktio_ops;
  extern const pktio_if_ops_t * const pktio_if_ops[];
  
  #ifdef __cplusplus
 diff --git a/platform/linux-generic/include/odp_packet_tap.h 
 b/platform/linux-generic/include/odp_packet_tap.h
 new file mode 100644
 index 000..7877586
 --- /dev/null
 +++ b/platform/linux-generic/include/odp_packet_tap.h
 @@ -0,0 +1,21 @@
 +/* Copyright (c) 2015, Ilya Maximets 
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier: BSD-3-Clause
 + */
 +
 +#ifndef ODP_PACKET_TAP_H_
 +#define ODP_PACKET_TAP_H_
 +
 +#include 
 +
 +typedef struct {
 +  int fd; /**< file descriptor for tap interface*/
 +  int skfd;   /**< socket descriptor */
 +  uint32_t mtu;   /**< cached mtu */
 +  unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side (not a
 +   MAC address of kernel interface)*/
 +  odp_pool_t pool;/**< pool to alloc packets from */
 +} pkt_tap_t;
 +
 +#endif
 diff --git a/platform/linux-generic/pktio/io_ops.c 
 b/platform/linux-generic/pktio/io_ops.c
 index 3b344e6..1933abc 100644
 --- a/platform/linux-generic/pktio/io_ops.c
 +++ b/platform/linux-generic/pktio/io_ops.c
 @@ -18,6 

Re: [lng-odp] ODP crypto API

[Ola Liljedahl]

On 8 December 2015 at 09:53, Bogdan Pricope  wrote:

> Hi,
>
>
>
> I have some questions on ODP crypto API:
>
> 1.   Where can I find an ODP crypto API manual/document?
>
> 2.   Some crypto APIs have a way to associate a crypto session with a
> „device”: create a crypto session in the context of that „device”. Is that
> possible with ODP crypto API?
>
Using some specific crypto/security device for a crypto session can be
considered part of the implementation which is not visible to the
application. The implementation is free to use any crypto device which can
handle the cipher algorithms etc specified in the crypto session. Why would
this be exposed to the user?

> 3.   Some crypto APIs have asynchronous crypto session
> creation/deletion. Is that possible with ODP crypto API?
>
> I know that ODP API provides completion queue with the session creation
> API (odp_crypto_session_create()) but it (ODP implementation) is supposed
> to generate a completion notification of special type when session creation
> is completed or… ?
>
As Bill wrote, creating an ODP crypto session is currently a synchronous
call. If you want to make this asynchronous, provide a patch to the API and
the reference implementation and the validation suite.


>
> *Bogdan Pricope*
>
> Software Engineer
>
> Engineering Office
>
>
>
> *Email*  *bogdan.pric...@enea.com *
>
> *Phone*  +4 074.20.20.475
>
>
>
> *Enea Global Services*
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D0B99B.6F4867F0]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
>
> ___
> 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] [PATCHv4 3/3] linux-generic: pktio: add test for tap pktio

[Ilya Maximets]

Signed-off-by: Ilya Maximets 
---
 platform/linux-generic/test/Makefile.am |   1 +
 platform/linux-generic/test/pktio/Makefile.am   |   3 +-
 platform/linux-generic/test/pktio/pktio_run_tap | 114 
 3 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100755 platform/linux-generic/test/pktio/pktio_run_tap

diff --git a/platform/linux-generic/test/Makefile.am 
b/platform/linux-generic/test/Makefile.am
index 1475589..28bd3dc 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -5,6 +5,7 @@ ODP_MODULES = pktio
 
 if test_vald
 TESTS = pktio/pktio_run \
+   pktio/pktio_run_tap \
${top_builddir}/test/validation/buffer/buffer_main$(EXEEXT) \

${top_builddir}/test/validation/classification/classification_main$(EXEEXT) \
${top_builddir}/test/validation/cpumask/cpumask_main$(EXEEXT) \
diff --git a/platform/linux-generic/test/pktio/Makefile.am 
b/platform/linux-generic/test/pktio/Makefile.am
index 4d39372..ea0ad87 100644
--- a/platform/linux-generic/test/pktio/Makefile.am
+++ b/platform/linux-generic/test/pktio/Makefile.am
@@ -1,5 +1,6 @@
 dist_check_SCRIPTS = pktio_env \
-pktio_run
+pktio_run \
+pktio_run_tap
 
 if HAVE_PCAP
 dist_check_SCRIPTS += pktio_run_pcap
diff --git a/platform/linux-generic/test/pktio/pktio_run_tap 
b/platform/linux-generic/test/pktio/pktio_run_tap
new file mode 100755
index 000..59bcd29
--- /dev/null
+++ b/platform/linux-generic/test/pktio/pktio_run_tap
@@ -0,0 +1,114 @@
+#!/bin/sh
+#
+# Copyright (c) 2015, Ilya Maximets 
+# All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+#
+
+# directories where pktio_main binary can be found:
+# -in the validation dir when running make check (intree or out of tree)
+# -in the script directory, when running after 'make install', or
+# -in the validation when running standalone intree.
+# -in the current directory.
+# running stand alone out of tree requires setting PATH
+PATH=${TEST_DIR}/pktio:$PATH
+PATH=$(dirname $0):$PATH
+PATH=$(dirname $0)/../../../../test/validation/pktio:$PATH
+PATH=.:$PATH
+
+pktio_main_path=$(which pktio_main${EXEEXT})
+if [ -x "$pktio_main_path" ] ; then
+   echo "running with $pktio_main_path"
+else
+   echo "cannot find pktio_main${EXEEXT}: please set you PATH for it."
+fi
+
+# exit code expected by automake for skipped tests
+TEST_SKIPPED=77
+
+TAP_BASE_NAME=iotap_vald
+IF0=${TAP_BASE_NAME}0
+IF1=${TAP_BASE_NAME}1
+BR=${TAP_BASE_NAME}_br
+
+export ODP_PKTIO_IF0="tap:$IF0"
+export ODP_PKTIO_IF1="tap:$IF1"
+
+tap_cleanup()
+{
+   ret=$?
+
+   for iface in $IF0 $IF1; do
+   ip link set dev $iface nomaster
+   done
+
+   ip link delete $BR type bridge
+
+   for iface in $IF0 $IF1; do
+   ip tuntap del mode tap $iface
+   done
+
+   trap - EXIT
+   exit $ret
+}
+
+tap_setup()
+{
+   if [ "$(id -u)" != "0" ]; then
+   echo "pktio: need to be root to setup TAP interfaces."
+   return $TEST_SKIPPED
+   fi
+
+   for iface in $IF0 $IF1 $BR; do
+   ip link show $iface 2> /dev/null
+   if [ $? -eq 0 ]; then
+   echo "pktio: interface $iface already exist $?"
+   return 2
+   fi
+   done
+
+   trap tap_cleanup EXIT
+
+   for iface in $IF0 $IF1; do
+   ip tuntap add mode tap $iface
+   if [ $? -ne 0 ]; then
+   echo "pktio: error: unable to create TAP device $iface"
+   return 3
+   fi
+   done
+
+   ip link add name $BR type bridge
+   if [ $? -ne 0 ]; then
+   echo "pktio: error: unable to create bridge $BR"
+   return 3
+   fi
+
+   for iface in $IF0 $IF1; do
+   ip link set dev $iface master $BR
+   if [ $? -ne 0 ]; then
+   echo "pktio: error: unable to add $iface to bridge $BR"
+   return 4
+   fi
+   done
+
+   for iface in $IF0 $IF1 $BR; do
+   ifconfig $iface -arp
+   sysctl -w net.ipv6.conf.${iface}.disable_ipv6=1
+   ip link set dev $iface mtu 9216 up
+   done
+
+   return 0
+}
+
+tap_setup
+ret=$?
+if [ $ret -ne 0 ]; then
+   echo "pktio: tap_setup() FAILED!"
+   exit $ret
+fi
+
+pktio_main${EXEEXT}
+ret=$?
+
+exit $ret
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[Ola Liljedahl]

On 8 December 2015 at 06:39, HePeng  wrote:

> Hi Maxim,
> I implement a new version of cuckoo hash based on the ODP
> buffer/pool.
>
> As I’ve mentioned earlier, the use of ring in cuckoo hash is like
> to the use of
> a container, e.g. a queue in C++ STL.  In current ODP implementation, I
> found that
> the ODP queue is implemented more likely a facility for transmitting
> objects, not
>
ODP queues are for storing ODP events and passing them from producer to
consumer (which may be SW threads and also HW blocks).


> a container to store objects. Look at the ODP queue enqueue interface:
>
> int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
>
> the *odp_event_t* is related to the events, but I only want to use
> odp_queue to
> storing and retrieving objects, any objects.
>
Using ODP HW abstractions (e.g. ODP queues, ODP pools) doesn't seem optimal
for storing any type of SW objects.


>
>
> So I use ODP buffer/pool interfaces instead of ODP queue
> for the new cuckoo hash implementation.
>
> However, compared to the previous implementation based on ring,
> this version
> suffers a serious performance degradation. The evaluation is carried out
> on a Intel
> servers. I test lookup time for 1000 lookups on a table storing 1 million
> items.
> The ODP buffer/pool version suffers at least a 2x performance degradation.
>
Which ODP implementation are you using? ODP/DPDK or linux-generic?


> This is the buffer/pool version, for 1M insert, and 1000 lookup time:
>
> Average insert time = 2.383836, lookup time = 0.000353,
>
> This is the ring version.
>
> Average insert time = 1.629115, lookup time = 0.98
>
> This performance degradation stems from the heavy implementation of
>  ODP buffer/pool. In the ring based one, all the key is stored in a big
> array, and
> the ring only stores the array indexes of each key. Keys are retrieved
> using array indexes.
> In the new one, I use ODP buffer to store the key content. Keys are
> retrieved by
> dereferencing a *odp_buffer_t*  handle.
>
> With this high performance degradation, I suggest moving ring into
> the odp/api
> as a container implementation, and use the previous implementation of
> cuckoo hash.
>
Is the ODP (I think the heritage goes back to BSD) ring optimal for this?


>
>
>
>
>
>
> ___
> 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] [PATCH 00/10] Pktio checks

[Savolainen, Petri (Nokia - FI/Espoo)]

Could you merge this into api-next ASAP. Just lost couple of hours in debugging 
these same malfunctioning tests.

-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Maxim Uvarov
> Sent: Tuesday, December 08, 2015 4:14 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH 00/10] Pktio checks
> 
> Merged,
> Maxim.
> 
> On 11/10/2015 18:49, Nicolas Morey-Chaisemartin wrote:
> > This series add several tests for pktios and fixes the issue they
> raised.
> > The main features checked are:
> > * RONLY pktio cannot be sent to
> > * WONLY pktio cannot be read from
> > * stopped pktio cannot be stopped
> > * started pktio cannot be started
> > * started pktio cannot be configured
> >
> > Nicolas Morey-Chaisemartin (10):
> >linux-generic: pktio: check interface mode is compatible before
> >  receiving or sending
> >validation: pktio: add customizable out mode for pktios
> >validation: pktio: add tests for rrecv() on WONLY, and send on RONLY
> >  pktios
> >validation: pktio: stop interfaces before removing the default inq
> >validation: pktio: remove unneeded stop as interface is stopped after
> >  open()
> >validation: classification: start pktio after setting inq and stop it
> >  before removing it
> >validation: classification: stronger checks to avoid SEGV on pktio
> >  failure
> >linux-generic: pktio: check for pktio_start when started and
> >  pktio_stop when stopped
> >linux-generic: pktio: configuration functions check that interface is
> >  stopped
> >validation: pktio: add test for start when started and stop when
> >  stopped()
> >
> >   platform/linux-generic/odp_packet_io.c |  25 -
> >   .../classification/odp_classification_common.c |   2 +
> >   .../classification/odp_classification_test_pmr.c   |  25 +++--
> >   test/validation/pktio/pktio.c  | 116
> ++---
> >   4 files changed, 140 insertions(+), 28 deletions(-)
> >
> > ___
> > 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv4 2/5] helper: table: add impl of hashtable

[Ola Liljedahl]

On 3 December 2015 at 14:14, Ivan Khoronzhuk 
wrote:

> It's in master already but I wonder how checkpatch missed it.
>
> On 05.11.15 13:20, huanggaoyang wrote:
>
>> Signed-off-by: huanggaoyang 
>> ---
>>   helper/hashtable.c  | 346
>> 
>>   helper/odph_hashtable.h |  42 ++
>>   helper/odph_list_internal.h |  85 +++
>>   3 files changed, 473 insertions(+)
>>   create mode 100644 helper/hashtable.c
>>   create mode 100644 helper/odph_hashtable.h
>>   create mode 100644 helper/odph_list_internal.h
>>
>> diff --git a/helper/hashtable.c b/helper/hashtable.c
>> new file mode 100644
>> index 000..0b29814
>> --- /dev/null
>> +++ b/helper/hashtable.c
>> @@ -0,0 +1,346 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier:   BSD-3-Clause
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "odph_hashtable.h"
>> +#include "odph_list_internal.h"
>> +#include "odph_debug.h"
>> +#include 
>> +
>> +#defineODPH_SUCCESS0
>> +#defineODPH_FAIL   -1
>> +
>> +/** @magic word, write to the first byte of the memory block
>> + * to indicate this block is used by a hash table structure
>> + */
>> +#defineODPH_HASH_TABLE_MAGIC_WORD  0xABABBABA
>>
> tabs after define, how it was missed?
>
And surely the value should be 0xABBAABBA!?!


>
> +
>> +/** @support 64k buckets. Bucket is a list that composed of
>> + * elements with the same HASH-value but different keys
>> + */
>> +#defineODPH_MAX_BUCKET_NUM 0x1
>>
> tabs after define, how it was missed?
>
> +
>> +/** @inner element structure of hash table
>> + * To resolve the hash confict:
>> + * we put the elements with different keys but a same HASH-value
>> + * into a list
>> + */
>> +typedef struct odph_hash_node {
>> +   /** list structure,for list opt */
>> +   odph_list_object list_node;
>> +   /** Flexible Array,memory will be alloced when table has been
>> created
>> +* Its length is key_size + value_size,
>> +* suppose key_size = m; value_size = n;
>> +* its structure is like:
>> +* k_byte1 k_byte2...k_byten v_byte1...v_bytem
>> +*/
>> +   char content[0];
>> +} odph_hash_node;
>> +
>> +typedef struct {
>> +   uint32_t magicword; /**< for check */
>> +   uint32_t key_size; /**< input param when create,in Bytes */
>> +   uint32_t value_size; /**< input param when create,in Bytes */
>> +   uint32_t init_cap; /**< input param when create,in Bytes */
>> +   /** multi-process support,every list has one rw lock */
>> +   odp_rwlock_t *lock_pool;
>> +   /** table bucket pool,every hash value has one list head */
>> +   odph_list_head *list_head_pool;
>> +   /** number of the list head in list_head_pool */
>> +   uint32_t head_num;
>> +   /** table element pool */
>> +   odph_hash_node *hash_node_pool;
>> +   /** number of element in the hash_node_pool */
>> +   uint32_t hash_node_num;
>> +   char rsv[7]; /**< Reserved,for alignment */
>> +   char name[ODPH_TABLE_NAME_LEN]; /**< table name */
>> +} odph_hash_table_imp;
>> +
>> +odph_table_t odph_hash_table_create(const char *name, uint32_t capacity,
>> +   uint32_t key_size,
>> +   uint32_t value_size)
>> +{
>> +   int idx, i;
>> +   uint32_t node_num;
>> +   odph_hash_table_imp *tbl;
>> +   odp_shm_t shmem;
>> +   uint32_t node_mem;
>> +
>> +   if (strlen(name) >= ODPH_TABLE_NAME_LEN || capacity < 1 ||
>> +   capacity >= 0x1000 || key_size == 0 || value_size == 0) {
>> +   ODPH_DBG("create para input error!\n");
>> +   return NULL;
>> +   }
>> +   tbl = (odph_hash_table_imp *)odp_shm_addr(odp_shm_lookup(name));
>> +   if (tbl != NULL) {
>> +   ODPH_DBG("name already exist\n");
>> +   return NULL;
>> +   }
>> +   shmem = odp_shm_reserve(name, capacity << 20, 64,
>> ODP_SHM_SW_ONLY);
>> +   if (shmem == ODP_SHM_INVALID) {
>> +   ODPH_DBG("shm reserve fail\n");
>> +   return NULL;
>> +   }
>> +   tbl = (odph_hash_table_imp *)odp_shm_addr(shmem);
>> +
>> +   /* clean this block of memory */
>> +   memset(tbl, 0, capacity << 20);
>> +
>> +   tbl->init_cap = capacity << 20;
>> +   strncpy(tbl->name, name, ODPH_TABLE_NAME_LEN);
>> +   tbl->key_size = key_size;
>> +   tbl->value_size = value_size;
>> +
>> +   /* header of this mem block is the table control struct,
>> +* then the lock pool, then the list header pool
>> +* the last part is the element node pool
>> +*/
>> +
>> +   tbl->lock_pool = (odp_rwlock_t *)((char *)tbl
>> +   + sizeof(odph_hash_table_imp));
>> +   tbl->list_head_pool = (odph_list_head 

Re: [lng-odp] [PATCH] linux-generic: socket: set up __odp_errno on ioctl failures

[Maxim Uvarov]

Merged,
Thanks.

On 12/08/2015 14:29, Stuart Haslam wrote:

On Mon, Dec 07, 2015 at 05:25:03PM +0300, Ilya Maximets wrote:

Also debug output enhanced.

Signed-off-by: Ilya Maximets 

Reviewed-by: Stuart Haslam 


---
  platform/linux-generic/pktio/socket.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/pktio/socket.c 
b/platform/linux-generic/pktio/socket.c
index 5f5e0ae..ef2e031 100644
--- a/platform/linux-generic/pktio/socket.c
+++ b/platform/linux-generic/pktio/socket.c
@@ -126,7 +126,9 @@ int mtu_get_fd(int fd, const char *name)
snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
ret = ioctl(fd, SIOCGIFMTU, );
if (ret < 0) {
-   ODP_DBG("ioctl SIOCGIFMTU error\n");
+   __odp_errno = errno;
+   ODP_DBG("ioctl(SIOCGIFMTU): %s: \"%s\".\n", strerror(errno),
+   ifr.ifr_name);
return -1;
}
return ifr.ifr_mtu;
@@ -145,7 +147,9 @@ int promisc_mode_set_fd(int fd, const char *name, int 
enable)
snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
ret = ioctl(fd, SIOCGIFFLAGS, );
if (ret < 0) {
-   ODP_DBG("ioctl SIOCGIFFLAGS error\n");
+   __odp_errno = errno;
+   ODP_DBG("ioctl(SIOCGIFFLAGS): %s: \"%s\".\n", strerror(errno),
+   ifr.ifr_name);
return -1;
}
  
@@ -156,7 +160,9 @@ int promisc_mode_set_fd(int fd, const char *name, int enable)
  
  	ret = ioctl(fd, SIOCSIFFLAGS, );

if (ret < 0) {
-   ODP_DBG("ioctl SIOCSIFFLAGS error\n");
+   __odp_errno = errno;
+   ODP_DBG("ioctl(SIOCSIFFLAGS): %s: \"%s\".\n", strerror(errno),
+   ifr.ifr_name);
return -1;
}
return 0;
@@ -175,7 +181,9 @@ int promisc_mode_get_fd(int fd, const char *name)
snprintf(ifr.ifr_name, IF_NAMESIZE, "%s", name);
ret = ioctl(fd, SIOCGIFFLAGS, );
if (ret < 0) {
-   ODP_DBG("ioctl SIOCGIFFLAGS error\n");
+   __odp_errno = errno;
+   ODP_DBG("ioctl(SIOCGIFFLAGS): %s: \"%s\".\n", strerror(errno),
+   ifr.ifr_name);
return -1;
}
  
--

2.1.4



___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] ODP crypto API

[Bogdan Pricope]

Hi,

I imagine that it can be a good reason behind this API model: some boards may 
have multiple HW resources identifiable in same way and some applications may 
prefer to allocate by hand sessions to those resources (resource partitioning).
OK, round robin allocation may work in most of the cases but not in all.

Bogdan Pricope
Software Engineer
Engineering Office

Email  bogdan.pric...@enea.com
Phone  +4 074.20.20.475

Enea Global Services

www.enea.com

[cid:image002.png@01D0B99B.6F4867F0]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.


From: Ola Liljedahl [mailto:ola.liljed...@linaro.org]
Sent: Tuesday, December 08, 2015 3:56 PM
To: Bogdan Pricope 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] ODP crypto API



On 8 December 2015 at 09:53, Bogdan Pricope 
> wrote:
Hi,

I have some questions on ODP crypto API:

1.   Where can I find an ODP crypto API manual/document?

2.   Some crypto APIs have a way to associate a crypto session with a 
„device”: create a crypto session in the context of that „device”. Is that 
possible with ODP crypto API?
Using some specific crypto/security device for a crypto session can be 
considered part of the implementation which is not visible to the application. 
The implementation is free to use any crypto device which can handle the cipher 
algorithms etc specified in the crypto session. Why would this be exposed to 
the user?

3.   Some crypto APIs have asynchronous crypto session creation/deletion. 
Is that possible with ODP crypto API?
I know that ODP API provides completion queue with the session creation API 
(odp_crypto_session_create()) but it (ODP implementation) is supposed to 
generate a completion notification of special type when session creation is 
completed or… ?
As Bill wrote, creating an ODP crypto session is currently a synchronous call. 
If you want to make this asynchronous, provide a patch to the API and the 
reference implementation and the validation suite.


Bogdan Pricope
Software Engineer
Engineering Office

Email  bogdan.pric...@enea.com
Phone  +4 074.20.20.475

Enea Global Services

www.enea.com

[cid:image002.png@01D0B99B.6F4867F0]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.



___
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] [PATCHv4 1/3] validation: pktio: initialize mac addresses for all packets

[Ilya Maximets]

For the purpose of testing of real-world interfaces the packet's
content should be valid or kernel will throw them away.

Signed-off-by: Ilya Maximets 
---
 test/validation/pktio/pktio.c | 46 ---
 1 file changed, 39 insertions(+), 7 deletions(-)

diff --git a/test/validation/pktio/pktio.c b/test/validation/pktio/pktio.c
index 50a6d8a..4c7d458 100644
--- a/test/validation/pktio/pktio.c
+++ b/test/validation/pktio/pktio.c
@@ -86,16 +86,16 @@ static void set_pool_len(odp_pool_param_t *params)
 }
 
 static void pktio_pkt_set_macs(odp_packet_t pkt,
-  pktio_info_t *src, pktio_info_t *dst)
+  odp_pktio_t src, odp_pktio_t dst)
 {
uint32_t len;
odph_ethhdr_t *eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, );
int ret;
 
-   ret = odp_pktio_mac_addr(src->id, >src, sizeof(eth->src));
+   ret = odp_pktio_mac_addr(src, >src, sizeof(eth->src));
CU_ASSERT(ret == ODPH_ETHADDR_LEN);
 
-   ret = odp_pktio_mac_addr(dst->id, >dst, sizeof(eth->dst));
+   ret = odp_pktio_mac_addr(dst, >dst, sizeof(eth->dst));
CU_ASSERT(ret == ODPH_ETHADDR_LEN);
 }
 
@@ -410,12 +410,16 @@ static void pktio_txrx_multi(pktio_info_t *pktio_a, 
pktio_info_t *pktio_b,
break;
 
tx_seq[i] = pktio_init_packet(tx_pkt[i]);
-   if (tx_seq[i] == TEST_SEQ_INVALID)
+   if (tx_seq[i] == TEST_SEQ_INVALID) {
+   odp_packet_free(tx_pkt[i]);
break;
+   }
 
-   pktio_pkt_set_macs(tx_pkt[i], pktio_a, pktio_b);
-   if (pktio_fixup_checksums(tx_pkt[i]) != 0)
+   pktio_pkt_set_macs(tx_pkt[i], pktio_a->id, pktio_b->id);
+   if (pktio_fixup_checksums(tx_pkt[i]) != 0) {
+   odp_packet_free(tx_pkt[i]);
break;
+   }
 
tx_ev[i] = odp_packet_to_event(tx_pkt[i]);
}
@@ -724,6 +728,13 @@ static void pktio_test_start_stop(void)
if (pkt == ODP_PACKET_INVALID)
break;
pktio_init_packet(pkt);
+
+   pktio_pkt_set_macs(pkt, pktio[0], pktio[1]);
+   if (pktio_fixup_checksums(pkt) != 0) {
+   odp_packet_free(pkt);
+   break;
+   }
+
tx_ev[alloc] = odp_packet_to_event(pkt);
}
 
@@ -775,6 +786,13 @@ static void pktio_test_start_stop(void)
if (pkt == ODP_PACKET_INVALID)
break;
pktio_init_packet(pkt);
+   if (num_ifaces > 1) {
+   pktio_pkt_set_macs(pkt, pktio[0], pktio[1]);
+   if (pktio_fixup_checksums(pkt) != 0) {
+   odp_packet_free(pkt);
+   break;
+   }
+   }
tx_ev[alloc] = odp_packet_to_event(pkt);
}
 
@@ -896,8 +914,17 @@ static void pktio_test_send_failure(void)
break;
 
pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
-   if (pkt_seq[i] == TEST_SEQ_INVALID)
+
+   pktio_pkt_set_macs(pkt_tbl[i], pktio_tx, pktio_rx);
+   if (pktio_fixup_checksums(pkt_tbl[i]) != 0) {
+   odp_packet_free(pkt_tbl[i]);
+   break;
+   }
+
+   if (pkt_seq[i] == TEST_SEQ_INVALID) {
+   odp_packet_free(pkt_tbl[i]);
break;
+   }
}
alloc_pkts = i;
 
@@ -941,6 +968,11 @@ static void pktio_test_send_failure(void)
 odp_packet_len(pkt_tbl[i]) -
 PKT_LEN_NORMAL);
pkt_seq[i] = pktio_init_packet(pkt_tbl[i]);
+
+   pktio_pkt_set_macs(pkt_tbl[i], pktio_tx, pktio_rx);
+   ret = pktio_fixup_checksums(pkt_tbl[i]);
+   CU_ASSERT_FATAL(ret == 0);
+
CU_ASSERT_FATAL(pkt_seq[i] != TEST_SEQ_INVALID);
ret = odp_pktio_send(pktio_tx, _tbl[i], TX_BATCH_LEN - i);
CU_ASSERT_FATAL(ret == (TX_BATCH_LEN - i));
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv4 2/3] linux-generic: pktio: add tap pktio type

[Ilya Maximets]

Creates a new pktio type that allows for creating and
sending/receiving packets through TAP interface.
It is intended for use as a simple conventional communication
method between applications that use kernel network stack
(ping, ssh, iperf, etc.) and ODP applications for the purpose
of functional testing and can be used as it is with some
of the existing example applications.

To use this interface the name passed to odp_pktio_open() must
begin with "tap:" and be in the format:

 tap:iface

   iface   the name of TAP device to be created.

TUN/TAP kernel module should be loaded to use this pktio.
There should be no device named 'iface' in the system.
The total length of the 'iface' is limited by IF_NAMESIZE.

Signed-off-by: Ilya Maximets 
---
 platform/linux-generic/Makefile.am |   2 +
 .../linux-generic/include/odp_packet_io_internal.h |   3 +
 platform/linux-generic/include/odp_packet_tap.h|  21 ++
 platform/linux-generic/pktio/io_ops.c  |   1 +
 platform/linux-generic/pktio/tap.c | 327 +
 5 files changed, 354 insertions(+)
 create mode 100644 platform/linux-generic/include/odp_packet_tap.h
 create mode 100644 platform/linux-generic/pktio/tap.c

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 70bd8fe..4639ebc 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -92,6 +92,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_packet_io_queue.h \
  ${srcdir}/include/odp_packet_netmap.h \
  ${srcdir}/include/odp_packet_socket.h \
+ ${srcdir}/include/odp_packet_tap.h \
  ${srcdir}/include/odp_pool_internal.h \
  ${srcdir}/include/odp_queue_internal.h \
  ${srcdir}/include/odp_schedule_internal.h \
@@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
   pktio/netmap.c \
   pktio/socket.c \
   pktio/socket_mmap.c \
+  pktio/tap.c \
   odp_pool.c \
   odp_queue.c \
   odp_rwlock.c \
diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index 1a1118c..de29557 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -22,6 +22,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,7 @@ struct pktio_entry {
 #ifdef HAVE_PCAP
pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
 #endif
+   pkt_tap_t pkt_tap;  /**< using TAP for IO */
};
enum {
STATE_START = 0,
@@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
 #ifdef HAVE_PCAP
 extern const pktio_if_ops_t pcap_pktio_ops;
 #endif
+extern const pktio_if_ops_t tap_pktio_ops;
 extern const pktio_if_ops_t * const pktio_if_ops[];
 
 #ifdef __cplusplus
diff --git a/platform/linux-generic/include/odp_packet_tap.h 
b/platform/linux-generic/include/odp_packet_tap.h
new file mode 100644
index 000..7877586
--- /dev/null
+++ b/platform/linux-generic/include/odp_packet_tap.h
@@ -0,0 +1,21 @@
+/* Copyright (c) 2015, Ilya Maximets 
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PACKET_TAP_H_
+#define ODP_PACKET_TAP_H_
+
+#include 
+
+typedef struct {
+   int fd; /**< file descriptor for tap interface*/
+   int skfd;   /**< socket descriptor */
+   uint32_t mtu;   /**< cached mtu */
+   unsigned char if_mac[ETH_ALEN]; /**< MAC address of pktio side (not a
+MAC address of kernel interface)*/
+   odp_pool_t pool;/**< pool to alloc packets from */
+} pkt_tap_t;
+
+#endif
diff --git a/platform/linux-generic/pktio/io_ops.c 
b/platform/linux-generic/pktio/io_ops.c
index 3b344e6..1933abc 100644
--- a/platform/linux-generic/pktio/io_ops.c
+++ b/platform/linux-generic/pktio/io_ops.c
@@ -18,6 +18,7 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
 #ifdef HAVE_PCAP
_pktio_ops,
 #endif
+   _pktio_ops,
_mmap_pktio_ops,
_mmsg_pktio_ops,
NULL
diff --git a/platform/linux-generic/pktio/tap.c 
b/platform/linux-generic/pktio/tap.c
new file mode 100644
index 000..7ecb300
--- /dev/null
+++ b/platform/linux-generic/pktio/tap.c
@@ -0,0 +1,327 @@
+/* Copyright (c) 2015, Ilya Maximets 
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * TAP pktio type
+ *
+ * This file provides a pktio interface that allows for creating and
+ * send/receive 

Re: [lng-odp] ODP crypto API

[Ola Liljedahl]

On 8 December 2015 at 15:44, Bogdan Pricope  wrote:

> Hi,
>
>
>
> I imagine that it can be a good reason behind this API model: some boards
> may have multiple HW resources identifiable in same way and some
> applications may prefer to allocate by hand sessions to those resources
> (resource partitioning).
>
ODP presents an abstract HW model in order to provide e.g. portability.
Exposing different HW configurations makes it less abstract and
applications less portable.

OK, round robin allocation may work in most of the cases but not in all.
>
Then implement a better algorithm in your ODP implementation for this
platform. Don't push the responsibility to the application. The application
is less likely to know what is a good allocation strategy.


>
>
> *Bogdan Pricope*
>
> Software Engineer
>
> Engineering Office
>
>
>
> *Email*  *bogdan.pric...@enea.com *
>
> *Phone*  +4 074.20.20.475
>
>
>
> *Enea Global Services*
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D0B99B.6F4867F0]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
>
> *From:* Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> *Sent:* Tuesday, December 08, 2015 3:56 PM
> *To:* Bogdan Pricope 
> *Cc:* lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] ODP crypto API
>
>
>
>
>
>
>
> On 8 December 2015 at 09:53, Bogdan Pricope 
> wrote:
>
> Hi,
>
>
>
> I have some questions on ODP crypto API:
>
> 1.   Where can I find an ODP crypto API manual/document?
>
> 2.   Some crypto APIs have a way to associate a crypto session with a
> „device”: create a crypto session in the context of that „device”. Is that
> possible with ODP crypto API?
>
> Using some specific crypto/security device for a crypto session can be
> considered part of the implementation which is not visible to the
> application. The implementation is free to use any crypto device which can
> handle the cipher algorithms etc specified in the crypto session. Why would
> this be exposed to the user?
>
> 3.   Some crypto APIs have asynchronous crypto session
> creation/deletion. Is that possible with ODP crypto API?
>
> I know that ODP API provides completion queue with the session creation
> API (odp_crypto_session_create()) but it (ODP implementation) is supposed
> to generate a completion notification of special type when session creation
> is completed or… ?
>
> As Bill wrote, creating an ODP crypto session is currently a synchronous
> call. If you want to make this asynchronous, provide a patch to the API and
> the reference implementation and the validation suite.
>
>
>
>
>
> *Bogdan Pricope*
>
> Software Engineer
>
> Engineering Office
>
>
>
> *Email*  *bogdan.pric...@enea.com *
>
> *Phone*  +4 074.20.20.475
>
>
>
> *Enea Global Services*
>
>
>
> www.enea.com
>
>
>
> [image: cid:image002.png@01D0B99B.6F4867F0]
>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, a mended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
>
>
>
>
>
> ___
> 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] validation: pktio: fix start_stop and send_failure tests

[Mike Holmes]

On 8 December 2015 at 10:17, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Ilya Maximets
> > Sent: Tuesday, December 08, 2015 4:48 PM
> > To: Stuart Haslam; Elo, Matias (Nokia - FI/Espoo)
> > Cc: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] validation: pktio: fix start_stop and send_failure
> > tests
> >
> >
> >
> > On 08.12.2015 17:38, Stuart Haslam wrote:
> > > On Tue, Dec 08, 2015 at 12:21:06PM +, Elo, Matias (Nokia -
> FI/Espoo)
> > wrote:
> > >> Hi Ilya,
> > >>
> > >> I had completely missed your previous patch. You could also remove the
> > two errno value checks in pktio_test_send_failure(). They are not defined
> > in the API, so they should not be tested.
> > >>
> > >> -Matias
> > >>
> > >
> > > It realise it's back-to-front, but IMO it would be better to document
> > > that the errno must be set.
> > >
> >
> > I agree with that. There is so little set of functions, according to
> > documentation, sets up errno.
> > My opinion is that almost all functions should set it on errors,
> otherwise
> > it useless.
> >
> > Best regards, Ilya Maximets.
>
>
> The problem with errno is that we'd need to define also a set of errno
> values and usage of those in a way that is valid for all implementations.
> Specifying errno's is easy on a single implementation but same errors may
> not be easily checked over multiple implementations.
>
> So in this phase,


When would we tackle the next phase if we don't start creating the
 supported list now ? The rationale that not all platforms support it will
still be true then.


> I'd specify that generally ODP functions that return "failure" may set
> odp_errno with implementation specific, non-zero value. Errno could be
> logged and used for debugging, but not tested against in an application.
> App would always test e.g. ret < 0.
>
> -Petri
>
>
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv3 2/3] linux-generic: pktio: add tap pktio type

[Ilya Maximets]

On 08.12.2015 15:35, Stuart Haslam wrote:
> On Tue, Dec 08, 2015 at 03:25:01PM +0300, Ilya Maximets wrote:
>>
>>
>> On 08.12.2015 15:16, Stuart Haslam wrote:
>>> On Tue, Dec 08, 2015 at 02:51:40PM +0300, Ilya Maximets wrote:
 On 08.12.2015 14:24, Stuart Haslam wrote:
> On Mon, Dec 07, 2015 at 01:55:31PM +0300, Ilya Maximets wrote:
>> Creates a new pktio type that allows for creating and
>> sending/receiving packets through TAP interface.
>> It is intended for use as a simple conventional communication
>> method between applications that use kernel network stack
>> (ping, ssh, iperf, etc.) and ODP applications for the purpose
>> of functional testing and can be used as it is with some
>> of the existing example applications.
>>
>> To use this interface the name passed to odp_pktio_open() must
>> begin with "tap:" and be in the format:
>>
>>  tap:iface
>>
>>iface   the name of TAP device to be created.
>>
>> TUN/TAP kernel module should be loaded to use this pktio.
>> There should be no device named 'iface' in the system.
>> The total length of the 'iface' is limited by IF_NAMESIZE.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>  platform/linux-generic/Makefile.am |   2 +
>>  .../linux-generic/include/odp_packet_io_internal.h |   3 +
>>  platform/linux-generic/include/odp_packet_tap.h|  21 ++
>>  platform/linux-generic/pktio/io_ops.c  |   1 +
>>  platform/linux-generic/pktio/tap.c | 317 
>> +
>>  5 files changed, 344 insertions(+)
>>  create mode 100644 platform/linux-generic/include/odp_packet_tap.h
>>  create mode 100644 platform/linux-generic/pktio/tap.c
>>
>> diff --git a/platform/linux-generic/Makefile.am 
>> b/platform/linux-generic/Makefile.am
>> index 70bd8fe..4639ebc 100644
>> --- a/platform/linux-generic/Makefile.am
>> +++ b/platform/linux-generic/Makefile.am
>> @@ -92,6 +92,7 @@ noinst_HEADERS = \
>>${srcdir}/include/odp_packet_io_queue.h \
>>${srcdir}/include/odp_packet_netmap.h \
>>${srcdir}/include/odp_packet_socket.h \
>> +  ${srcdir}/include/odp_packet_tap.h \
>>${srcdir}/include/odp_pool_internal.h \
>>${srcdir}/include/odp_queue_internal.h \
>>${srcdir}/include/odp_schedule_internal.h \
>> @@ -120,6 +121,7 @@ __LIB__libodp_la_SOURCES = \
>> pktio/netmap.c \
>> pktio/socket.c \
>> pktio/socket_mmap.c \
>> +   pktio/tap.c \
>> odp_pool.c \
>> odp_queue.c \
>> odp_rwlock.c \
>> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
>> b/platform/linux-generic/include/odp_packet_io_internal.h
>> index 1a1118c..de29557 100644
>> --- a/platform/linux-generic/include/odp_packet_io_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
>> @@ -22,6 +22,7 @@ extern "C" {
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -78,6 +79,7 @@ struct pktio_entry {
>>  #ifdef HAVE_PCAP
>>  pkt_pcap_t pkt_pcap;/**< Using pcap for IO 
>> */
>>  #endif
>> +pkt_tap_t pkt_tap;  /**< using TAP for IO */
>>  };
>>  enum {
>>  STATE_START = 0,
>> @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
>>  #ifdef HAVE_PCAP
>>  extern const pktio_if_ops_t pcap_pktio_ops;
>>  #endif
>> +extern const pktio_if_ops_t tap_pktio_ops;
>>  extern const pktio_if_ops_t * const pktio_if_ops[];
>>  
>>  #ifdef __cplusplus
>> diff --git a/platform/linux-generic/include/odp_packet_tap.h 
>> b/platform/linux-generic/include/odp_packet_tap.h
>> new file mode 100644
>> index 000..7877586
>> --- /dev/null
>> +++ b/platform/linux-generic/include/odp_packet_tap.h
>> @@ -0,0 +1,21 @@
>> +/* Copyright (c) 2015, Ilya Maximets 
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#ifndef ODP_PACKET_TAP_H_
>> +#define ODP_PACKET_TAP_H_
>> +
>> +#include 
>> +
>> +typedef struct {
>> +int fd; /**< file descriptor for tap 
>> interface*/
>> +int skfd;   /**< socket descriptor */
>> +uint32_t mtu;   /**< cached mtu */
>> +unsigned char if_mac[ETH_ALEN]; 

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Ilya Maximets]

On 08.12.2015 17:38, Stuart Haslam wrote:
> On Tue, Dec 08, 2015 at 12:21:06PM +, Elo, Matias (Nokia - FI/Espoo) 
> wrote:
>> Hi Ilya,
>>
>> I had completely missed your previous patch. You could also remove the two 
>> errno value checks in pktio_test_send_failure(). They are not defined in the 
>> API, so they should not be tested.
>>
>> -Matias
>>
> 
> It realise it's back-to-front, but IMO it would be better to document
> that the errno must be set.
> 

I agree with that. There is so little set of functions, according to 
documentation, sets up errno.
My opinion is that almost all functions should set it on errors, otherwise it 
useless.

Best regards, Ilya Maximets.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Ilya Maximets
> Sent: Tuesday, December 08, 2015 4:48 PM
> To: Stuart Haslam; Elo, Matias (Nokia - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] validation: pktio: fix start_stop and send_failure
> tests
> 
> 
> 
> On 08.12.2015 17:38, Stuart Haslam wrote:
> > On Tue, Dec 08, 2015 at 12:21:06PM +, Elo, Matias (Nokia - FI/Espoo)
> wrote:
> >> Hi Ilya,
> >>
> >> I had completely missed your previous patch. You could also remove the
> two errno value checks in pktio_test_send_failure(). They are not defined
> in the API, so they should not be tested.
> >>
> >> -Matias
> >>
> >
> > It realise it's back-to-front, but IMO it would be better to document
> > that the errno must be set.
> >
> 
> I agree with that. There is so little set of functions, according to
> documentation, sets up errno.
> My opinion is that almost all functions should set it on errors, otherwise
> it useless.
> 
> Best regards, Ilya Maximets.


The problem with errno is that we'd need to define also a set of errno values 
and usage of those in a way that is valid for all implementations. Specifying 
errno's is easy on a single implementation but same errors may not be easily 
checked over multiple implementations.

So in this phase, I'd specify that generally ODP functions that return 
"failure" may set odp_errno with implementation specific, non-zero value. Errno 
could be logged and used for debugging, but not tested against in an 
application. App would always test e.g. ret < 0.

-Petri
 



 
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv4 0/3] TAP pktio

[Ilya Maximets]

Creates a new pktio type that allows for creating and
sending/receiving packets through TAP interface.
Detailed description in commit-message of patch
"[PATCHv4 2/3] linux-generic: pktio: add tap pktio type".

Changelog:

Version 4:
* changed error handling part in tap_pktio_send. (Stuart Haslam)

Version 3:
* return 77 (TEST_SKIPPED) if user is not root. (Stuart Haslam)

Version 2:
* Validation tests added
* Pktio tests fixed to work with real-world
  interfaces.
* MAC of pktio now is not a kernel interface's MAC
* Interfaces are UP after pktio_open()
* Fixed getting mtu, getting/setting promisc mode
* Misclenious fixes

Ilya Maximets (3):
  validation: pktio: initialize mac addresses for all packets
  linux-generic: pktio: add tap pktio type
  linux-generic: pktio: add test for tap pktio

 platform/linux-generic/Makefile.am |   2 +
 .../linux-generic/include/odp_packet_io_internal.h |   3 +
 platform/linux-generic/include/odp_packet_tap.h|  21 ++
 platform/linux-generic/pktio/io_ops.c  |   1 +
 platform/linux-generic/pktio/tap.c | 327 +
 platform/linux-generic/test/Makefile.am|   1 +
 platform/linux-generic/test/pktio/Makefile.am  |   3 +-
 platform/linux-generic/test/pktio/pktio_run_tap| 114 +++
 test/validation/pktio/pktio.c  |  46 ++-
 9 files changed, 510 insertions(+), 8 deletions(-)
 create mode 100644 platform/linux-generic/include/odp_packet_tap.h
 create mode 100644 platform/linux-generic/pktio/tap.c
 create mode 100755 platform/linux-generic/test/pktio/pktio_run_tap

-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[Ola Liljedahl]

On 8 December 2015 at 12:42, Bill Fischofer 
wrote:

> This is an interesting topic.  I'd like to discuss this a bit during
> today's ODP public call.
>
> I think the issue is that while a ring is a very useful implementation
> construct its semantics are very SW centric.
>
But isn't the use case here SW centric?


> Perhaps there's opportunity here for a new Queue type that would permit an
> implementation to implement the queue API as a ring for additional
> performance?
>
I think it is a bad idea to overload the ODP queue with another type of
usage and implied implementation. Better to define a new ODP object.

What are the real requirements of the "ring" as used by the cuckoo hash
design? Enqueue/dequeue operations. Fixed size is OK? Storing arbitrary
objects (not just ODP events)?



>   The scheduler itself could use this since its use of queues is subject
> to the same issues.
>
> On Mon, Dec 7, 2015 at 11:39 PM, HePeng  wrote:
>
>> Hi Maxim,
>> I implement a new version of cuckoo hash based on the ODP
>> buffer/pool.
>>
>> As I’ve mentioned earlier, the use of ring in cuckoo hash is like
>> to the use of
>> a container, e.g. a queue in C++ STL.  In current ODP implementation, I
>> found that
>> the ODP queue is implemented more likely a facility for transmitting
>> objects, not
>> a container to store objects. Look at the ODP queue enqueue interface:
>>
>> int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
>>
>> the *odp_event_t* is related to the events, but I only want to use
>> odp_queue to
>> storing and retrieving objects, any objects.
>>
>>
>> So I use ODP buffer/pool interfaces instead of ODP queue
>> for the new cuckoo hash implementation.
>>
>> However, compared to the previous implementation based on ring,
>> this version
>> suffers a serious performance degradation. The evaluation is carried out
>> on a Intel
>> servers. I test lookup time for 1000 lookups on a table storing 1 million
>> items.
>> The ODP buffer/pool version suffers at least a 2x performance degradation.
>>
>> This is the buffer/pool version, for 1M insert, and 1000 lookup time:
>>
>> Average insert time = 2.383836, lookup time = 0.000353,
>>
>> This is the ring version.
>>
>> Average insert time = 1.629115, lookup time = 0.98
>>
>> This performance degradation stems from the heavy implementation
>> of
>>  ODP buffer/pool. In the ring based one, all the key is stored in a big
>> array, and
>> the ring only stores the array indexes of each key. Keys are retrieved
>> using array indexes.
>> In the new one, I use ODP buffer to store the key content. Keys are
>> retrieved by
>> dereferencing a *odp_buffer_t*  handle.
>>
>> With this high performance degradation, I suggest moving ring
>> into the odp/api
>> as a container implementation, and use the previous implementation of
>> cuckoo hash.
>>
>>
>>
>>
>>
>>
>> ___
>> 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXTv6 1/7] api: buffer: add functions to alloc/free multiple buffers at once

[Ola Liljedahl]

On 3 December 2015 at 16:01, Bill Fischofer 
wrote:

>
>
> On Thu, Dec 3, 2015 at 8:30 AM, Zoltan Kiss 
> wrote:
>
>> Hi,
>>
>> I know it's a late cry, but I've found two problems while implementing
>> this for ODP-DPDK, and the apply for odp_packet_alloc_multi() as well. See
>> inline:
>>
>> On 28/10/15 15:31, Nicolas Morey-Chaisemartin wrote:
>>
>>> Signed-off-by: Nicolas Morey-Chaisemartin 
>>> Reviewed-by: Petri Savolainen 
>>> ---
>>>   include/odp/api/buffer.h | 26 ++
>>>   1 file changed, 26 insertions(+)
>>>
>>> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
>>> index aea273f..6631f47 100644
>>> --- a/include/odp/api/buffer.h
>>> +++ b/include/odp/api/buffer.h
>>> @@ -105,6 +105,20 @@ odp_pool_t odp_buffer_pool(odp_buffer_t buf);
>>>   odp_buffer_t odp_buffer_alloc(odp_pool_t pool);
>>>
>>>   /**
>>> + * Allocate multiple buffers
>>> +
>>> + * Otherwise like odp_buffer_alloc(), but allocates multiple buffers
>>> from a pool
>>> + *
>>> + * @param pool  Pool handle
>>> + * @param[out] buf  Array of buffer handles for output
>>> + * @param num   Maximum number of buffers to allocate
>>> + *
>>> + * @return Number of buffers actually allocated (0 ... num)
>>> + * @retval <0 on failure
>>>
>>
>> These two lines contradicts each other: the first says we should return
>> how much we managed to allocate, and we will always allocate at least 0
>> buffers.
>> The second says in case of error a negative value, but even if we fail
>> straight away, the first line commands us to return 0. Moreover, if we
>> managed to allocate at least some of the buffers and then we return a
>> negative value due to some error (e.g. ENOMEM, or anything else), the
>> application won't know if there is any buffer to use in the array. Either
>> we should clarify that the platform should release them in case of an
>> error, or (and I think that would be the better thing to do) we should
>> return how much we allocated.
>> Altogether, I think we should remove the "<0 on failure" statement and
>> set the errno instead. If you agree, Nicolas, would you submit a patch for
>> that?
>
>
> This is just being consistent with other multi() APIs like
> odp_queue_enq_multi().  I believe we had this discussion surrounding those
> APIs and decided to keep these semantics.  Negative RCs say the error is
> permanent.  An RC of 0 would indicate that nothing was done however the
> operation is retryable.  We don't actually make use of that RC for now,
>
"We don't actually make use of that RC for now"
I don't understand this sentence.


> so perhaps the change should be to say the RC is 1..num rather than 0..num.
>
Perhaps no known implementation returns 0 buffers but that doesn't mean we
can go and change the specification. Applications should expect and handle
odp_packet_alloc_multi() returning 0 and not (by default) treat this as a
fatal error.


>
>>
>> + */
>>> +int odp_buffer_alloc_multi(odp_pool_t pool, odp_buffer_t buf[], int
>>> num);
>>>
>>
>> 'num' should be unsigned, a negative number doesn't make sense in this
>> case. Although changing this breaks the ABI, so I'm not sure if we should
>> fix this or just leave it.
>
>
> Again this is copied directly from the other multi() APIs.  Agree they
> probably should be unsigned but I don't think it's a big deal since in the
> unlikely event a negative number was supplied you wouldn't get any buffers
> anyway.  By the same argument specifying 0 here wouldn't make sense
> semantically and yet that's a valid int and unsigned.
>
>
>>
>>
>> ___
>> 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Stuart Haslam]

On Tue, Dec 08, 2015 at 12:21:06PM +, Elo, Matias (Nokia - FI/Espoo) wrote:
> Hi Ilya,
> 
> I had completely missed your previous patch. You could also remove the two 
> errno value checks in pktio_test_send_failure(). They are not defined in the 
> API, so they should not be tested.
> 
> -Matias
> 

It realise it's back-to-front, but IMO it would be better to document
that the errno must be set.

-- 
Stuart.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 00/10] Pktio checks

[Maxim Uvarov]

On 12/08/2015 17:20, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Could you merge this into api-next ASAP. Just lost couple of hours in debugging 
these same malfunctioning tests.

-Petri


If you can merge that master and api-next I can. But for now after time 
things 2 branches out of sync in many files.


Maxim.





-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Maxim Uvarov
Sent: Tuesday, December 08, 2015 4:14 PM
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCH 00/10] Pktio checks

Merged,
Maxim.

On 11/10/2015 18:49, Nicolas Morey-Chaisemartin wrote:

This series add several tests for pktios and fixes the issue they

raised.

The main features checked are:
* RONLY pktio cannot be sent to
* WONLY pktio cannot be read from
* stopped pktio cannot be stopped
* started pktio cannot be started
* started pktio cannot be configured

Nicolas Morey-Chaisemartin (10):
linux-generic: pktio: check interface mode is compatible before
  receiving or sending
validation: pktio: add customizable out mode for pktios
validation: pktio: add tests for rrecv() on WONLY, and send on RONLY
  pktios
validation: pktio: stop interfaces before removing the default inq
validation: pktio: remove unneeded stop as interface is stopped after
  open()
validation: classification: start pktio after setting inq and stop it
  before removing it
validation: classification: stronger checks to avoid SEGV on pktio
  failure
linux-generic: pktio: check for pktio_start when started and
  pktio_stop when stopped
linux-generic: pktio: configuration functions check that interface is
  stopped
validation: pktio: add test for start when started and stop when
  stopped()

   platform/linux-generic/odp_packet_io.c |  25 -
   .../classification/odp_classification_common.c |   2 +
   .../classification/odp_classification_test_pmr.c   |  25 +++--
   test/validation/pktio/pktio.c  | 116

++---

   4 files changed, 140 insertions(+), 28 deletions(-)

___
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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] validation: pktio: fix start_stop and send_failure tests

[Stuart Haslam]

On Tue, Dec 08, 2015 at 03:17:46PM +, Savolainen, Petri (Nokia - FI/Espoo) 
wrote:
> 
> 
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Ilya Maximets
> > Sent: Tuesday, December 08, 2015 4:48 PM
> > To: Stuart Haslam; Elo, Matias (Nokia - FI/Espoo)
> > Cc: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] validation: pktio: fix start_stop and send_failure
> > tests
> > 
> > 
> > 
> > On 08.12.2015 17:38, Stuart Haslam wrote:
> > > On Tue, Dec 08, 2015 at 12:21:06PM +, Elo, Matias (Nokia - FI/Espoo)
> > wrote:
> > >> Hi Ilya,
> > >>
> > >> I had completely missed your previous patch. You could also remove the
> > two errno value checks in pktio_test_send_failure(). They are not defined
> > in the API, so they should not be tested.
> > >>
> > >> -Matias
> > >>
> > >
> > > It realise it's back-to-front, but IMO it would be better to document
> > > that the errno must be set.
> > >
> > 
> > I agree with that. There is so little set of functions, according to
> > documentation, sets up errno.
> > My opinion is that almost all functions should set it on errors, otherwise
> > it useless.
> > 
> > Best regards, Ilya Maximets.
> 
> 
> The problem with errno is that we'd need to define also a set of errno values 
> and usage of those in a way that is valid for all implementations. Specifying 
> errno's is easy on a single implementation but same errors may not be easily 
> checked over multiple implementations.
> 
> So in this phase, I'd specify that generally ODP functions that return 
> "failure" may set odp_errno with implementation specific, non-zero value. 
> Errno could be logged and used for debugging, but not tested against in an 
> application. App would always test e.g. ret < 0.
> 
> -Petri

I agree that for now specifying particular errno values is probably a
step too far, but it doesn't seem unreasonable to specify that if an API
function returns an error indication (in this case retval < 0) then it
must also set an errno.

The current test is checking only that odp_errno() != 0 on failure, and
is == 0 on success.

-- 
Stuart.
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv4 2/5] helper: table: add impl of hashtable

[Stuart Haslam]

On Thu, Dec 03, 2015 at 08:39:26AM -0500, Mike Holmes wrote:
> It does miss it apparently - just shows you we still need a human eye
> 

I have this in my ~/.gitconfig

[core]
whitespace = trailing-space,space-before-tab,indent-with-non-tab

and it warns about it:

Applying: helper: table: add impl of hashtable
odp/.git/rebase-apply/patch:361: new blank line at EOF.
+
odp/.git/rebase-apply/patch:409: new blank line at EOF.
+
odp/.git/rebase-apply/patch:500: new blank line at EOF.
+
warning: 3 lines add whitespace errors.

-- 
Stuart.

> mike@mike-desktop:~/git/odp$ git format-patch -1 a775afd
> 0001-helper-table-add-impl-of-hashtable.patch
> mike@mike-desktop:~/git/odp$ ./scripts/checkpatch.pl
> 0001-helper-table-add-impl-of-hashtable.patch
> total: 0 errors, 0 warnings, 0 checks, 473 lines checked
> 
> NOTE: Ignored message types: COMPARISON_TO_NULL DEPRECATED_VARIABLE
> NEW_TYPEDEFS SPLIT_STRING
> 
> 0001-helper-table-add-impl-of-hashtable.patch has no obvious style problems
> and is ready for submission.
> 
> 
> On 3 December 2015 at 08:16, Ivan Khoronzhuk 
> wrote:
> 
> >
> >
> > On 05.11.15 13:20, huanggaoyang wrote:
> >
> >> Signed-off-by: huanggaoyang 
> >> ---
> >>   helper/hashtable.c  | 346
> >> 
> >>   helper/odph_hashtable.h |  42 ++
> >>   helper/odph_list_internal.h |  85 +++
> >>   3 files changed, 473 insertions(+)
> >>   create mode 100644 helper/hashtable.c
> >>   create mode 100644 helper/odph_hashtable.h
> >>   create mode 100644 helper/odph_list_internal.h
> >>
> >> diff --git a/helper/hashtable.c b/helper/hashtable.c
> >> new file mode 100644
> >> index 000..0b29814
> >> --- /dev/null
> >> +++ b/helper/hashtable.c
> >> @@ -0,0 +1,346 @@
> >> +/* Copyright (c) 2015, Linaro Limited
> >> + * All rights reserved.
> >> + *
> >> + * SPDX-License-Identifier:   BSD-3-Clause
> >> + */
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "odph_hashtable.h"
> >> +#include "odph_list_internal.h"
> >> +#include "odph_debug.h"
> >> +#include 
> >> +
> >> +#defineODPH_SUCCESS0
> >> +#defineODPH_FAIL   -1
> >> +
> >>
> > .
> >
> >> +odph_table_ops_t odph_hash_table_ops = {
> >> +   odph_hash_table_create,
> >> +   odph_hash_table_lookup,
> >> +   odph_hash_table_destroy,
> >> +   odph_hash_put_value,
> >> +   odph_hash_get_value,
> >> +   odph_hash_remove_value};
> >> +
> >>
> >
> > 
> > Blank line at the end of file.
> > Need to add check in checkpatch.
> >
> > --
> > Regards,
> > Ivan Khoronzhuk
> > ___
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/lng-odp
> >
> 
> 
> 
> -- 
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv4 2/5] helper: table: add impl of hashtable

[Mike Holmes]

On 8 December 2015 at 10:49, Stuart Haslam  wrote:

> On Thu, Dec 03, 2015 at 08:39:26AM -0500, Mike Holmes wrote:
> > It does miss it apparently - just shows you we still need a human eye
> >
>
> I have this in my ~/.gitconfig
> [core]
> whitespace = trailing-space,space-before-tab,indent-with-non-tab
>
I hadwhitespace = trailing-space,sapce-before-tab,error-all

Thanks for pointer I had typo and a missing setting, I will send a patch to
the contributing section for the settings once I check what we want in a
little more detail

>
> and it warns about it:
>
> Applying: helper: table: add impl of hashtable
> odp/.git/rebase-apply/patch:361: new blank line at EOF.
> +
> odp/.git/rebase-apply/patch:409: new blank line at EOF.
> +
> odp/.git/rebase-apply/patch:500: new blank line at EOF.
> +
> warning: 3 lines add whitespace errors.
>
> --
> Stuart.
>
> > mike@mike-desktop:~/git/odp$ git format-patch -1 a775afd
> > 0001-helper-table-add-impl-of-hashtable.patch
> > mike@mike-desktop:~/git/odp$ ./scripts/checkpatch.pl
> > 0001-helper-table-add-impl-of-hashtable.patch
> > total: 0 errors, 0 warnings, 0 checks, 473 lines checked
> >
> > NOTE: Ignored message types: COMPARISON_TO_NULL DEPRECATED_VARIABLE
> > NEW_TYPEDEFS SPLIT_STRING
> >
> > 0001-helper-table-add-impl-of-hashtable.patch has no obvious style
> problems
> > and is ready for submission.
> >
> >
> > On 3 December 2015 at 08:16, Ivan Khoronzhuk  >
> > wrote:
> >
> > >
> > >
> > > On 05.11.15 13:20, huanggaoyang wrote:
> > >
> > >> Signed-off-by: huanggaoyang 
> > >> ---
> > >>   helper/hashtable.c  | 346
> > >> 
> > >>   helper/odph_hashtable.h |  42 ++
> > >>   helper/odph_list_internal.h |  85 +++
> > >>   3 files changed, 473 insertions(+)
> > >>   create mode 100644 helper/hashtable.c
> > >>   create mode 100644 helper/odph_hashtable.h
> > >>   create mode 100644 helper/odph_list_internal.h
> > >>
> > >> diff --git a/helper/hashtable.c b/helper/hashtable.c
> > >> new file mode 100644
> > >> index 000..0b29814
> > >> --- /dev/null
> > >> +++ b/helper/hashtable.c
> > >> @@ -0,0 +1,346 @@
> > >> +/* Copyright (c) 2015, Linaro Limited
> > >> + * All rights reserved.
> > >> + *
> > >> + * SPDX-License-Identifier:   BSD-3-Clause
> > >> + */
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +
> > >> +#include "odph_hashtable.h"
> > >> +#include "odph_list_internal.h"
> > >> +#include "odph_debug.h"
> > >> +#include 
> > >> +
> > >> +#defineODPH_SUCCESS0
> > >> +#defineODPH_FAIL   -1
> > >> +
> > >>
> > > .
> > >
> > >> +odph_table_ops_t odph_hash_table_ops = {
> > >> +   odph_hash_table_create,
> > >> +   odph_hash_table_lookup,
> > >> +   odph_hash_table_destroy,
> > >> +   odph_hash_put_value,
> > >> +   odph_hash_get_value,
> > >> +   odph_hash_remove_value};
> > >> +
> > >>
> > >
> > > 
> > > Blank line at the end of file.
> > > Need to add check in checkpatch.
> > >
> > > --
> > > Regards,
> > > Ivan Khoronzhuk
> > > ___
> > > lng-odp mailing list
> > > lng-odp@lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/lng-odp
> > >
> >
> >
> >
> > --
> > Mike Holmes
> > Technical Manager - Linaro Networking Group
> > Linaro.org  *│ *Open source software for ARM
> SoCs
>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 00/10] Pktio checks

[Mike Holmes]

The process states that API-NEXT takes master on master release points only.

https://docs.google.com/drawings/d/1kWkr2qBV4xbqOCXMDVsoINhdxaNeHC-8sCm6SBVFI8o/edit




On 8 December 2015 at 09:48, Maxim Uvarov  wrote:

> On 12/08/2015 17:20, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>
>> Could you merge this into api-next ASAP. Just lost couple of hours in
>> debugging these same malfunctioning tests.
>>
>> -Petri
>>
>
> If you can merge that master and api-next I can. But for now after time
> things 2 branches out of sync in many files.
>
> Maxim.
>
>
>
>
>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
>>> Maxim Uvarov
>>> Sent: Tuesday, December 08, 2015 4:14 PM
>>> To: lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] [PATCH 00/10] Pktio checks
>>>
>>> Merged,
>>> Maxim.
>>>
>>> On 11/10/2015 18:49, Nicolas Morey-Chaisemartin wrote:
>>>
 This series add several tests for pktios and fixes the issue they

>>> raised.
>>>
 The main features checked are:
 * RONLY pktio cannot be sent to
 * WONLY pktio cannot be read from
 * stopped pktio cannot be stopped
 * started pktio cannot be started
 * started pktio cannot be configured

 Nicolas Morey-Chaisemartin (10):
 linux-generic: pktio: check interface mode is compatible before
   receiving or sending
 validation: pktio: add customizable out mode for pktios
 validation: pktio: add tests for rrecv() on WONLY, and send on RONLY
   pktios
 validation: pktio: stop interfaces before removing the default inq
 validation: pktio: remove unneeded stop as interface is stopped
 after
   open()
 validation: classification: start pktio after setting inq and stop
 it
   before removing it
 validation: classification: stronger checks to avoid SEGV on pktio
   failure
 linux-generic: pktio: check for pktio_start when started and
   pktio_stop when stopped
 linux-generic: pktio: configuration functions check that interface
 is
   stopped
 validation: pktio: add test for start when started and stop when
   stopped()

platform/linux-generic/odp_packet_io.c |  25 -
.../classification/odp_classification_common.c |   2 +
.../classification/odp_classification_test_pmr.c   |  25 +++--
test/validation/pktio/pktio.c  | 116

>>> ++---
>>>
4 files changed, 140 insertions(+), 28 deletions(-)

 ___
 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 mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Maxim Uvarov]

Merged this patch.

Now only issue left is fix:
hash_main: no such file
I think something wrong in Makefile.am, not sure if CI also captures 
that issues,

but we will see. That is different issue.

Maxim.


On 12/03/2015 00:56, Bill Fischofer wrote:

Change the internal hash_name_and_kind() function to eliminate the use
of architecture-specific hash instructions. This eliminates build issues
surrounding ARM variants. Future optimizations will use the arch directory
consistent with other ODP modules.

Signed-off-by: Bill Fischofer 
---
  platform/linux-generic/odp_name_table.c | 182 +---
  1 file changed, 1 insertion(+), 181 deletions(-)

diff --git a/platform/linux-generic/odp_name_table.c 
b/platform/linux-generic/odp_name_table.c
index 10a760e..610f034 100644
--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -48,140 +48,6 @@
  
  #define SECONDARY_HASH_HISTO_PRINT  1
  
- /* #define USE_AES */

-
-#if defined __x86_64__ || defined __i386__
-
-#ifdef USE_AES
-
-typedef long long int v2di __attribute__((vector_size(16)));
-
-static const v2di HASH_CONST1 = { 0x123456, 0xFEBCDA383   };
-static const v2di HASH_CONST2 = { 0x493BA3F689, 0x102F5D73A8C };
-
-#define PLATFORM_HASH_STATE v2di
-
-#define PLATFORM_HASH32_INIT(hash_state, name_len)  \
-   ({  \
-   hash_state = HASH_CONST1;   \
-   hash_state[0] ^= name_len;  \
-   })
-
-#define PLATFORM_HASH32(hash_state, name_word) \
-   ({ \
-   v2di data; \
-  \
-   data[0]= name_word;\
-   data[1]= name_word << 1;  \
-   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
-   })
-
-#define PLATFORM_HASH32_FINISH(hash_state, kind)\
-   ({  \
-   uint64_t result;\
-   v2di data;  \
-   \
-   data[0]= name_kind; \
-   data[1]= name_kind << 7;\
-   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
-   hash_state = __builtin_ia32_aesenc128(hash_state,   \
- HASH_CONST2); \
-   hash_state = __builtin_ia32_aesenc128(hash_state,   \
- HASH_CONST1); \
-   result = (uint64_t)hash_state[0] ^ hash_state[1];   \
-   result = result ^ result >> 32; \
-   (uint32_t)result;   \
-   })
-
-#else
-
-#define PLATFORM_HASH_STATE uint64_t
-
-#define PLATFORM_HASH32_INIT(hash_state, name_len)\
-   ({\
-   hash_state  = (uint64_t)name_len; \
-   hash_state |= hash_state << 8;  \
-   hash_state |= hash_state << 16; \
-   hash_state |= hash_state << 32; \
-   })
-
-#define PLATFORM_HASH32(hash_state, name_word)  \
-   ({  \
-   uint64_t temp;  \
-   \
-   temp= ((uint64_t)name_word) * 0xFEFDFCF5;   \
-   hash_state  = hash_state * 0xFF;\
-   hash_state ^= temp ^ (uint64_t)name_word;   \
-   })
-
-#define PLATFORM_HASH32_FINISH(hash_state, kind)\
-   ({  \
-   hash_state ^= (((uint32_t)kind) << 13); \
-   hash_state  = hash_state * 0xFEFDFCF5;  \
-   hash_state  = hash_state ^ hash_state >> 32;\
-   hash_state  = hash_state % 0xFEEDDCCBBAA1;  \
-   hash_state  = hash_state ^ hash_state >> 32;\
-   (uint32_t)hash_state;   \
-   })
-
-#endif
-
-#elif defined(__tile_gx__)
-
-#define PLATFORM_HASH_STATE  uint32_t
-
-#define PLATFORM_HASH32_INIT(hash_state, name_len)  \
-   ({  \
-   hash_state = 0xFEFDFCF5;   \
-   

Re: [lng-odp] [API-NEXT PATCH v3] api: atomic: added atomic_lock_free_u64

[Ola Liljedahl]

The patch doesn't apply. It depends on this patch [API-NEXT,v3,7/7] api:
atomic: added 32 bit acquire and release


As can be seen here in the patch:
diff --git a/include/odp/api/atomic.h b/include/odp/api/atomic.h
index 316f13a..5e897c1 100644
--- a/include/odp/api/atomic.h
+++ b/include/odp/api/atomic.h
@@ -388,6 +388,54 @@ void odp_atomic_add_rls_u32(odp_atomic_u32_t *atom,
uint32_t val);
* void odp_atomic_sub_rls_u32(odp_atomic_u32_t *atom, uint32_t val);*

 /**
+ * Atomic operations
+ *
+ * Atomic operations listed in a bit field structure.

What happened to that earlier patch series (cleanup of atomics
documentation and added some new atomic operations)? I know I wasn't fond
of adding new operations with just some of the different possible ordering
models, the choice seem quite haphazard to me. I have used the same
operations for lock-less programming but with different memory orderings.
Better to expose the operations in linux-generic odp_atomic_internal.h
where the memory ordering is a parameter.


On 26 November 2015 at 09:56, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> ping.
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> > Petri Savolainen
> > Sent: Thursday, November 12, 2015 10:30 AM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [API-NEXT PATCH v3] api: atomic: added
> > atomic_lock_free_u64
> >
> > Platforms may support some uint64 operations lock-free and
> > others not. For example, inc_64 can be natively supported but
> > cas_64 (or max_64/min_64) not. User may be able to switch to
> > 32 bit variables when a 64 bit operation uses locks. The same
> > atomic operation struture could be used for platform init to guide
> > lock vs. lock-free implementation (e.g. if cas_64 is never
> > called, inc_64 can be lock-free).
> >
> > Signed-off-by: Petri Savolainen 
> > ---
> >  include/odp/api/atomic.h| 48
> > +
> >  platform/linux-generic/Makefile.am  |  1 +
> >  platform/linux-generic/odp_atomic.c | 24 +++
> >  3 files changed, 73 insertions(+)
> >  create mode 100644 platform/linux-generic/odp_atomic.c
> >
> > diff --git a/include/odp/api/atomic.h b/include/odp/api/atomic.h
> > index 316f13a..5e897c1 100644
> > --- a/include/odp/api/atomic.h
> > +++ b/include/odp/api/atomic.h
> > @@ -388,6 +388,54 @@ void odp_atomic_add_rls_u32(odp_atomic_u32_t *atom,
> > uint32_t val);
> >  void odp_atomic_sub_rls_u32(odp_atomic_u32_t *atom, uint32_t val);
> >
> >  /**
> > + * Atomic operations
> > + *
> > + * Atomic operations listed in a bit field structure.
> > + */
> > +typedef union odp_atomic_op_t {
> > + /** Operation flags */
> > + struct {
> > + uint32_t init  : 1;  /**< Init atomic variable */
> > + uint32_t load  : 1;  /**< Atomic load */
> > + uint32_t store : 1;  /**< Atomic store */
> > + uint32_t fetch_add : 1;  /**< Atomic fetch and add */
> > + uint32_t add   : 1;  /**< Atomic add */
> > + uint32_t fetch_sub : 1;  /**< Atomic fetch and substract */
> > + uint32_t sub   : 1;  /**< Atomic substract */
> > + uint32_t fetch_inc : 1;  /**< Atomic fetch and increment */
> > + uint32_t inc   : 1;  /**< Atomic increment */
> > + uint32_t fetch_dec : 1;  /**< Atomic fetch and decrement */
> > + uint32_t dec   : 1;  /**< Atomic decrement */
> > + uint32_t min   : 1;  /**< Atomic minimum */
> > + uint32_t max   : 1;  /**< Atomic maximum */
> > + uint32_t cas   : 1;  /**< Atomic compare and swap */
> > + } op;
> > +
> > + /** All bits of the bit field structure.
> > +   * Operation flag mapping is architecture specific. This field can
> > be
> > +   * used to set/clear all flags, or bitwise operations over the
> > entire
> > +   * structure. */
> > + uint32_t all_bits;
> > +} odp_atomic_op_t;
> > +
> > +/**
> > + * Query which atomic uint64 operations are lock-free
> > + *
> > + * Lock-free implementations have higher performance and scale better
> > than
> > + * implementations using locks. User can decide to use e.g. uint32
> atomic
> > + * variables instead of uint64 to optimize performance on platforms that
> > + * implement a performance critical operation using locks.
> > + *
> > + * @param atomic_op  Pointer to atomic operation structure for storing
> > + *   operation flags. All bits are initialized to zero
> > during
> > + *   the operation. The parameter is ignored when NULL.
> > + * @retval 0 None of the operations are lock-free
> > + * @retval 1 Some of the operations are lock-free
> > + * @retval 2 All operations are lock-free
> > + */
> > +int odp_atomic_lock_free_u64(odp_atomic_op_t 

[lng-odp] [PATCHv4] helper : Fix UDP checksum computation

[ion.grigore]

From: Grigore Ion 

This patch fixes the following problems:
- checksum computation for LE platforms
- checksum is computed in the CPU endianness. The returned result
must be converted to the BE ordering when it is used to update
the UDP checksum in a packet.
- checksum computation for packets having the UDP length not a
multiple of 2
- fixes the UDP checksum associated validation test

Signed-off-by: Grigore Ion 
---
v4:
- Verify checksum in CPU endianness in the associated test
(Ilya Maximets)
v3:
- fix the UDP checksum computation in the associated test
(Maxim Uvarov)
v2:
- patch updated to the last master (Maxim Uvarov)
v1:
- Move variables declaration on top of block. (Maxim Uvarov)
- Check patch with checkpatch script.  (Maxim Uvarov)
- L3 header presence is tested twice. (Alexandru Badicioiu)
- Remove unnecessary check for L3 header presence. (Bill Fischofer)
- Modify check of odp_packet_l4_offset() return. (Bill Fischofer)

 helper/include/odp/helper/udp.h | 55 +
 helper/test/odp_chksum.c|  4 +--
 2 files changed, 25 insertions(+), 34 deletions(-)

diff --git a/helper/include/odp/helper/udp.h b/helper/include/odp/helper/udp.h
index 06c439b..9e7256d 100644
--- a/helper/include/odp/helper/udp.h
+++ b/helper/include/odp/helper/udp.h
@@ -4,7 +4,6 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-
 /**
  * @file
  *
@@ -22,7 +21,6 @@ extern "C" {
 #include 
 #include 
 
-
 /** @addtogroup odph_header ODPH HEADER
  *  @{
  */
@@ -44,46 +42,39 @@ typedef struct ODP_PACKED {
  * This function uses odp packet to calc checksum
  *
  * @param pkt  calculate chksum for pkt
- * @return  checksum value
+ * @return  checksum value in CPU endianness
  */
 static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)
 {
-   uint32_t sum = 0;
-   odph_udphdr_t *udph;
-   odph_ipv4hdr_t *iph;
-   uint16_t udplen;
-   uint8_t *buf;
-
-   if (!odp_packet_l3_offset(pkt))
-   return 0;
+   odph_ipv4hdr_t  *iph;
+   odph_udphdr_t   *udph;
+   uint32_tsum;
+   uint16_tudplen, *buf;
 
-   if (!odp_packet_l4_offset(pkt))
+   if (odp_packet_l4_offset(pkt) == ODP_PACKET_OFFSET_INVALID)
return 0;
-
iph = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
-   udplen = odp_be_to_cpu_16(udph->length);
-
-   /* 32-bit sum of all 16-bit words covered by UDP chksum */
+   /* 32-bit sum of UDP pseudo-header */
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);
-
+   (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
+   odp_be_to_cpu_16(iph->proto) + udph->length;
+   udplen = odp_be_to_cpu_16(udph->length);
+   buf = (uint16_t *)((void *)udph);
+   /* 32-bit sum of UDP header (checksum field cleared) and UDP data */
+   for ( ; udplen > 1; udplen -= 2)
+   sum += *buf++;
+   /* Length is not a multiple of 2 bytes */
+   if (udplen)
+   sum += odp_be_to_cpu_16(*((uint8_t *)buf) << 8);
+   /* Fold sum to 16 bits */
+   sum = (sum & 0x) + (sum >> 16);
+   /* Add carrier (0/1) to result */
+   sum += (sum >> 16);
/* 1's complement */
sum = ~sum;
-
-   /* set computation result */
-   sum = (sum == 0x0) ? 0x : sum;
-
-   return sum;
+   /* Set computation result in CPU endianness */
+   return (sum == 0x0) ? 0x : odp_be_to_cpu_16(sum);
 }
 
 /** @internal Compile time assert */
diff --git a/helper/test/odp_chksum.c b/helper/test/odp_chksum.c
index 1d417a8..2b32111 100644
--- a/helper/test/odp_chksum.c
+++ b/helper/test/odp_chksum.c
@@ -189,14 +189,14 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
udp->dst_port = 0;
udp->length = odp_cpu_to_be_16(udat_size + ODPH_UDPHDR_LEN);
udp->chksum = 0;
-   udp->chksum = odph_ipv4_udp_chksum(test_packet);
+   udp->chksum = odp_cpu_to_be_16(odph_ipv4_udp_chksum(test_packet));
 
if (udp->chksum == 0)
return -1;
 
printf("chksum = 0x%x\n", udp->chksum);
 
-   if (udp->chksum != 0xab2d)
+   if (udp->chksum != odp_be_to_cpu_16(0x7e5a))
status = -1;
 
odp_packet_free(test_packet);
-- 
1.9.3

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv3] helper : Fix UDP checksum computation

[Ion Grigore]

Hi Ilya,

You are right, the comparison was in BE . I changed and I submitted a new patch 
(V4)

Thanks,
Grig


-Original Message-
From: Ilya Maximets [mailto:i.maxim...@samsung.com] 
Sent: Tuesday, December 08, 2015 9:47 AM
To: Grigore Ion-B17953 ; lng-odp@lists.linaro.org
Cc: Maxim Uvarov 
Subject: Re: [PATCHv3] helper : Fix UDP checksum computation

On 07.12.2015 18:43, ion.grig...@freescale.com wrote:
> From: Grigore Ion 
> 
> This patch fixes the following problems:
> - checksum computation for LE platforms
> - checksum is computed in the CPU endianness. The returned result must 
> be converted to the BE ordering when it is used to update the UDP 
> checksum in a packet.
> - checksum computation for packets having the UDP length not a 
> multiple of 2
> - fix the UDP checksum computation in the associated test
> 
> Signed-off-by: Grigore Ion 
> ---
>  v3:
>  - fix the UDP checksum computation in the associated test
>  v2:
>  - patch updated to the last master (Maxim Uvarov)
>  v1:
>  - Move variables declaration on top of block. (Maxim Uvarov)
>  - Check patch with checkpatch script.  (Maxim Uvarov)
>  - L3 header presence is tested twice. (Alexandru Badicioiu)
>  - Remove unnecessary check for L3 header presence. (Bill Fischofer)
>  - Modify check of odp_packet_l4_offset() return. (Bill Fischofer)
>  
>  helper/include/odp/helper/udp.h | 55 
> +
>  helper/test/odp_chksum.c|  4 +--
>  2 files changed, 25 insertions(+), 34 deletions(-)
> 
> diff --git a/helper/include/odp/helper/udp.h 
> b/helper/include/odp/helper/udp.h index 06c439b..9e7256d 100644
> --- a/helper/include/odp/helper/udp.h
> +++ b/helper/include/odp/helper/udp.h
> @@ -4,7 +4,6 @@
>   * SPDX-License-Identifier: BSD-3-Clause
>   */
>  
> -
>  /**
>   * @file
>   *
> @@ -22,7 +21,6 @@ extern "C" {
>  #include 
>  #include 
>  
> -
>  /** @addtogroup odph_header ODPH HEADER
>   *  @{
>   */
> @@ -44,46 +42,39 @@ typedef struct ODP_PACKED {
>   * This function uses odp packet to calc checksum
>   *
>   * @param pkt  calculate chksum for pkt
> - * @return  checksum value
> + * @return  checksum value in CPU endianness
>   */
>  static inline uint16_t odph_ipv4_udp_chksum(odp_packet_t pkt)  {
> - uint32_t sum = 0;
> - odph_udphdr_t *udph;
> - odph_ipv4hdr_t *iph;
> - uint16_t udplen;
> - uint8_t *buf;
> -
> - if (!odp_packet_l3_offset(pkt))
> - return 0;
> + odph_ipv4hdr_t  *iph;
> + odph_udphdr_t   *udph;
> + uint32_tsum;
> + uint16_tudplen, *buf;
>  
> - if (!odp_packet_l4_offset(pkt))
> + if (odp_packet_l4_offset(pkt) == ODP_PACKET_OFFSET_INVALID)
>   return 0;
> -
>   iph = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
>   udph = (odph_udphdr_t *)odp_packet_l4_ptr(pkt, NULL);
> - udplen = odp_be_to_cpu_16(udph->length);
> -
> - /* 32-bit sum of all 16-bit words covered by UDP chksum */
> + /* 32-bit sum of UDP pseudo-header */
>   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);
> -
> + (iph->dst_addr & 0x) + (iph->dst_addr >> 16) +
> + odp_be_to_cpu_16(iph->proto) + udph->length;
> + udplen = odp_be_to_cpu_16(udph->length);
> + buf = (uint16_t *)((void *)udph);
> + /* 32-bit sum of UDP header (checksum field cleared) and UDP data */
> + for ( ; udplen > 1; udplen -= 2)
> + sum += *buf++;
> + /* Length is not a multiple of 2 bytes */
> + if (udplen)
> + sum += odp_be_to_cpu_16(*((uint8_t *)buf) << 8);
> + /* Fold sum to 16 bits */
> + sum = (sum & 0x) + (sum >> 16);
> + /* Add carrier (0/1) to result */
> + sum += (sum >> 16);
>   /* 1's complement */
>   sum = ~sum;
> -
> - /* set computation result */
> - sum = (sum == 0x0) ? 0x : sum;
> -
> - return sum;
> + /* Set computation result in CPU endianness */
> + return (sum == 0x0) ? 0x : odp_be_to_cpu_16(sum);
>  }
>  
>  /** @internal Compile time assert */
> diff --git a/helper/test/odp_chksum.c b/helper/test/odp_chksum.c index 
> 1d417a8..2b32111 100644
> --- a/helper/test/odp_chksum.c
> +++ b/helper/test/odp_chksum.c
> @@ -189,14 +189,14 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
>   udp->dst_port = 0;
>   udp->length = odp_cpu_to_be_16(udat_size + ODPH_UDPHDR_LEN);
>   udp->chksum = 0;
> - udp->chksum = 

Re: [lng-odp] [API-NEXT PATCH] api: init: allow implementation to use private ways for its own configuration

[Zoltan Kiss]

Hi Petri,

Did you have time to think on this? Mike added it to tomorrow's arch 
call to discuss, unless you are happy with what I've proposed.


Zoli

On 01/12/15 11:30, Zoltan Kiss wrote:



On 01/12/15 08:38, Savolainen, Petri (Nokia - FI/Espoo) wrote:


// Fill defaults (from config file)
// max_cpu = 64, max_mhz = 1000 (on this SoC)
plat_xyz_config_init_params(_config);


Again, I strongly oppose this way. It doesn't make any sense. Any 
decent

applications should get the platform parameters through it's own config
from the user, and not try to hardcode these things.


How of those application parameters would need to be updated?
By the user, when configuring through the app's configuration 
interface. Not our concern how that happens.


Every time any of its target platforms change or add a parameter? 
Platforms may have many tuning parameters, which the application is 
*not interested* - default is fine, now and in the future.
Yes, e.g. DPDK has a lot of parameters, but it only mandates -n and -c 
(number of memory channels and cpu mask), and the latter is actually 
calculated by ODP-DPDK, so our apps need to specify -n only.




Now when application wants to change only one param trough 
plat_params, how it sets all other (100) parameters in the struct?


It really depends on platforms (that's why it's platform dependent), 
but struct is definitely not the best solution for that. Passing a 
string, or a linked list of struct, if you want something more 
elegant. That's really not our concern again, but generic 
application/API interfacing questions.
I think you're concerns are mostly rooted on the thought that 
platform_params should be a struct. It's not.




-Petri





plat_config.max_cpu = 32;
plat_config.max_mhz = 500; // 500MHz was max on the old SoC, could be

overridden with some plat specific way


___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH] linux-generic: tm: use odp_hash_crc32c() api to avoid arch issues

[Bill Fischofer]

hash_main is the binary output from compiling the hash CUnit test.  That's
should have nothing to do with TM.

On Tue, Dec 8, 2015 at 9:35 AM, Maxim Uvarov 
wrote:

> Merged this patch.
>
> Now only issue left is fix:
> hash_main: no such file
> I think something wrong in Makefile.am, not sure if CI also captures that
> issues,
> but we will see. That is different issue.
>
> Maxim.
>
>
>
> On 12/03/2015 00:56, Bill Fischofer wrote:
>
>> Change the internal hash_name_and_kind() function to eliminate the use
>> of architecture-specific hash instructions. This eliminates build issues
>> surrounding ARM variants. Future optimizations will use the arch directory
>> consistent with other ODP modules.
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>>   platform/linux-generic/odp_name_table.c | 182
>> +---
>>   1 file changed, 1 insertion(+), 181 deletions(-)
>>
>> diff --git a/platform/linux-generic/odp_name_table.c
>> b/platform/linux-generic/odp_name_table.c
>> index 10a760e..610f034 100644
>> --- a/platform/linux-generic/odp_name_table.c
>> +++ b/platform/linux-generic/odp_name_table.c
>> @@ -48,140 +48,6 @@
>> #define SECONDARY_HASH_HISTO_PRINT  1
>>   - /* #define USE_AES */
>> -
>> -#if defined __x86_64__ || defined __i386__
>> -
>> -#ifdef USE_AES
>> -
>> -typedef long long int v2di __attribute__((vector_size(16)));
>> -
>> -static const v2di HASH_CONST1 = { 0x123456, 0xFEBCDA383   };
>> -static const v2di HASH_CONST2 = { 0x493BA3F689, 0x102F5D73A8C };
>> -
>> -#define PLATFORM_HASH_STATE v2di
>> -
>> -#define PLATFORM_HASH32_INIT(hash_state, name_len)  \
>> -   ({  \
>> -   hash_state = HASH_CONST1;   \
>> -   hash_state[0] ^= name_len;  \
>> -   })
>> -
>> -#define PLATFORM_HASH32(hash_state, name_word) \
>> -   ({ \
>> -   v2di data; \
>> -  \
>> -   data[0]= name_word;\
>> -   data[1]= name_word << 1;\
>> -   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
>> -   })
>> -
>> -#define PLATFORM_HASH32_FINISH(hash_state, kind)\
>> -   ({  \
>> -   uint64_t result;\
>> -   v2di data;  \
>> -   \
>> -   data[0]= name_kind; \
>> -   data[1]= name_kind << 7;\
>> -   hash_state = __builtin_ia32_aesenc128(hash_state, data); \
>> -   hash_state = __builtin_ia32_aesenc128(hash_state,   \
>> - HASH_CONST2); \
>> -   hash_state = __builtin_ia32_aesenc128(hash_state,   \
>> - HASH_CONST1); \
>> -   result = (uint64_t)hash_state[0] ^ hash_state[1];   \
>> -   result = result ^ result >> 32; \
>> -   (uint32_t)result;   \
>> -   })
>> -
>> -#else
>> -
>> -#define PLATFORM_HASH_STATE uint64_t
>> -
>> -#define PLATFORM_HASH32_INIT(hash_state, name_len)\
>> -   ({\
>> -   hash_state  = (uint64_t)name_len; \
>> -   hash_state |= hash_state << 8;\
>> -   hash_state |= hash_state << 16;   \
>> -   hash_state |= hash_state << 32;   \
>> -   })
>> -
>> -#define PLATFORM_HASH32(hash_state, name_word)  \
>> -   ({  \
>> -   uint64_t temp;  \
>> -   \
>> -   temp= ((uint64_t)name_word) * 0xFEFDFCF5;   \
>> -   hash_state  = hash_state * 0xFF;\
>> -   hash_state ^= temp ^ (uint64_t)name_word;   \
>> -   })
>> -
>> -#define PLATFORM_HASH32_FINISH(hash_state, kind)\
>> -   ({  \
>> -   hash_state ^= (((uint32_t)kind) << 13); \
>> -   hash_state  = hash_state * 0xFEFDFCF5;  \
>> -   hash_state  = hash_state ^ hash_state >> 32;\
>> -   hash_state  = hash_state % 

[lng-odp] [PATCH] validation/config/Makefile: change install location

[Anders Roxell]

All tests should be installed under testdir variable and not in the bin
directory.

Signed-off-by: Anders Roxell 
---
 test/validation/config/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/validation/config/Makefile.am 
b/test/validation/config/Makefile.am
index 084e104..a4985f4 100644
--- a/test/validation/config/Makefile.am
+++ b/test/validation/config/Makefile.am
@@ -3,7 +3,7 @@ include ../Makefile.inc
 noinst_LTLIBRARIES = libtestconfig.la
 libtestconfig_la_SOURCES = config.c
 
-bin_PROGRAMS = config_main$(EXEEXT)
+test_PROGRAMS = config_main$(EXEEXT)
 dist_config_main_SOURCES = config_main.c
 config_main_LDADD = libtestconfig.la $(LIBCUNIT_COMMON) $(LIBODP)
 
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] api-next broken?

[Bill Fischofer]

Well, I've verified that if you do similar mods to
test/validation/pktio/pktio.c and test/validation/time/time.c then all is
good, however what this means is that we've just broken ODP API portability
because we now require that ODP applications include this #define when
compiling for linux-generic.  That's bad.

I tried putting the #define into
platform/linux-generic/include/odp/plat/time_types.h since that's where
odp_time_t is defined, but C doesn't like that.  As this is an artifact of
the linux-generic implementation of the odp_time APIs whatever magic needs
to happen strictly within linux-generic and cannot spill over to the
validation tests or other ODP applications.

On Tue, Dec 8, 2015 at 5:23 PM, Mike Holmes  wrote:

> Yep, I just compiled what I had, but it is the same root cause, just needs
> to be told to allow POSIX in that SRC.
>
> Maxim do you just want to fix in your morning, I dont have time now
> tonight so dont wait for me but you could add me as Suggested-by
>
> On 8 December 2015 at 18:17, Bill Fischofer 
> wrote:
>
>> That helps but it looks incomplete.  With that patch applied ODP compiles
>> but the CUnit tests fail:
>>
>> Making all in pktio
>> make[3]: Entering directory
>> '/home/bill/linaro/api-next/test/validation/pktio'
>>   CC   pktio.lo
>> pktio.c: In function 'queue_deq_wait_time':
>> pktio.c:339:13: error: storage size of 'wait' isn't known
>>   odp_time_t wait, end;
>>  ^
>> pktio.c:339:19: error: storage size of 'end' isn't known
>>   odp_time_t wait, end;
>>^
>> pktio.c:342:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   wait = odp_time_local_from_ns(ns);
>>   ^
>> pktio.c:343:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   end = odp_time_sum(odp_time_local(), wait);
>>   ^
>> pktio.c:343:21: error: type of formal parameter 1 is incomplete
>>   end = odp_time_sum(odp_time_local(), wait);
>>  ^
>> pktio.c:343:39: error: type of formal parameter 2 is incomplete
>>   end = odp_time_sum(odp_time_local(), wait);
>>^
>> pktio.c:348:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>>   ^
>> pktio.c:348:24: error: type of formal parameter 1 is incomplete
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>> ^
>> pktio.c:348:29: error: type of formal parameter 2 is incomplete
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>>  ^
>> pktio.c:339:19: error: unused variable 'end' [-Werror=unused-variable]
>>   odp_time_t wait, end;
>>^
>> pktio.c:339:13: error: unused variable 'wait' [-Werror=unused-variable]
>>   odp_time_t wait, end;
>>  ^
>> pktio.c: In function 'wait_for_packet':
>> pktio.c:356:13: error: storage size of 'wait_time' isn't known
>>   odp_time_t wait_time, end;
>>  ^
>> pktio.c:356:24: error: storage size of 'end' isn't known
>>   odp_time_t wait_time, end;
>> ^
>> pktio.c:362:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   wait_time = odp_time_local_from_ns(ns);
>>   ^
>> pktio.c:363:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   end = odp_time_sum(odp_time_local(), wait_time);
>>   ^
>> pktio.c:363:21: error: type of formal parameter 1 is incomplete
>>   end = odp_time_sum(odp_time_local(), wait_time);
>>  ^
>> pktio.c:363:39: error: type of formal parameter 2 is incomplete
>>   end = odp_time_sum(odp_time_local(), wait_time);
>>^
>> pktio.c:389:2: error: invalid use of incomplete typedef 'odp_time_t'
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>>   ^
>> pktio.c:389:24: error: type of formal parameter 1 is incomplete
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>> ^
>> pktio.c:389:29: error: type of formal parameter 2 is incomplete
>>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>>  ^
>> pktio.c:356:24: error: unused variable 'end' [-Werror=unused-variable]
>>   odp_time_t wait_time, end;
>> ^
>> pktio.c:356:13: error: unused variable 'wait_time'
>> [-Werror=unused-variable]
>>   odp_time_t wait_time, end;
>>  ^
>> cc1: all warnings being treated as errors
>> Makefile:504: recipe for target 'pktio.lo' failed
>> make[3]: *** [pktio.lo] Error 1
>> make[3]: Leaving directory
>> '/home/bill/linaro/api-next/test/validation/pktio'
>> Makefile:417: recipe for target 'all-recursive' failed
>> make[2]: *** [all-recursive] Error 1
>>
>>
>> On Tue, Dec 8, 2015 at 5:12 PM, Mike Holmes 
>> wrote:
>>
>>> Patch sent that works for me, it depends on the compiler in use and the
>>> c99 vs posix standard I think
>>>
>>> On 8 December 2015 at 17:14, Bill Fischofer 

Re: [lng-odp] api-next broken?

[Mike Holmes]

Patch sent that works for me, it depends on the compiler in use and the c99
vs posix standard I think

On 8 December 2015 at 17:14, Bill Fischofer 
wrote:

> git bisect shows:
>
> 3164ccfe7e6dc548852b8f6f681069cd6d524bfc is the first bad commit
> commit 3164ccfe7e6dc548852b8f6f681069cd6d524bfc
> Author: Ivan Khoronzhuk 
> Date:   Fri Dec 4 19:51:29 2015 +0200
>
> linux-generic: odp_time: don't use cpu cycle API to get time
>
> The linux-generic time API implementation shouldn't depend on cpu
> cycle API wich is not stable enough to measure time period due to
> dynamic frequency scaling.
>
> Reviewed-by: Petri Savolainen 
> Signed-off-by: Ivan Khoronzhuk 
> Signed-off-by: Maxim Uvarov 
>
> :04 04 5b252b56eaa4d7c8df9f4583d0b6e7b8db9a9fb9
> d331e32ad2a37014cdb8133a917cd660f52b6f7c M platform
>
>
> On Tue, Dec 8, 2015 at 3:55 PM, Bill Fischofer 
> wrote:
>
>> Trying to compile a fresh clone of api-next I'm seeing the following:
>>
>>   CC   odp_schedule.lo
>> odp_schedule.c: In function 'schedule_loop':
>> odp_schedule.c:589:13: error: storage size of 'next' isn't known
>>   odp_time_t next, wtime;
>>  ^
>> odp_schedule.c:589:19: error: storage size of 'wtime' isn't known
>>   odp_time_t next, wtime;
>>^
>> odp_schedule.c:606:4: error: invalid use of incomplete typedef
>> 'odp_time_t'
>> wtime = odp_time_local_from_ns(wait);
>> ^
>> odp_schedule.c:607:4: error: invalid use of incomplete typedef
>> 'odp_time_t'
>> next = odp_time_sum(odp_time_local(), wtime);
>> ^
>> odp_schedule.c:607:24: error: type of formal parameter 1 is incomplete
>> next = odp_time_sum(odp_time_local(), wtime);
>> ^
>> odp_schedule.c:607:42: error: type of formal parameter 2 is incomplete
>> next = odp_time_sum(odp_time_local(), wtime);
>>   ^
>> odp_schedule.c:612:3: error: invalid use of incomplete typedef
>> 'odp_time_t'
>>if (odp_time_cmp(next, odp_time_local()) < 0)
>>^
>> odp_schedule.c:612:20: error: type of formal parameter 1 is incomplete
>>if (odp_time_cmp(next, odp_time_local()) < 0)
>> ^
>> odp_schedule.c:612:26: error: type of formal parameter 2 is incomplete
>>if (odp_time_cmp(next, odp_time_local()) < 0)
>>   ^
>> odp_schedule.c:589:19: error: unused variable 'wtime'
>> [-Werror=unused-variable]
>>   odp_time_t next, wtime;
>>^
>> odp_schedule.c:589:13: error: unused variable 'next'
>> [-Werror=unused-variable]
>>   odp_time_t next, wtime;
>>  ^
>> cc1: all warnings being treated as errors
>> Makefile:757: recipe for target 'odp_schedule.lo' failed
>>
>>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT] add _POSIX_C_SOURCE 200809 to fix build

[Mike Holmes]

fixes api-next

  CC   odp_schedule.lo
odp_schedule.c: In function 'schedule_loop':
odp_schedule.c:589:13: error: storage size of 'next' isn't known
  odp_time_t next, wtime;
 ^

Signed-off-by: Mike Holmes 
---
 platform/linux-generic/odp_schedule.c | 2 ++
 test/performance/odp_pktio_perf.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/platform/linux-generic/odp_schedule.c 
b/platform/linux-generic/odp_schedule.c
index 3017876..c163634 100644
--- a/platform/linux-generic/odp_schedule.c
+++ b/platform/linux-generic/odp_schedule.c
@@ -4,6 +4,8 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
+#define _POSIX_C_SOURCE 200809L
+
 #include 
 #include 
 #include 
diff --git a/test/performance/odp_pktio_perf.c 
b/test/performance/odp_pktio_perf.c
index 8737bc8..59a1007 100644
--- a/test/performance/odp_pktio_perf.c
+++ b/test/performance/odp_pktio_perf.c
@@ -20,6 +20,9 @@
  * a single packet rate can be specified on the command line.
  *
  */
+
+#define _POSIX_C_SOURCE 200809L
+
 #include 
 
 #include 
-- 
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] api-next broken?

[Bill Fischofer]

That helps but it looks incomplete.  With that patch applied ODP compiles
but the CUnit tests fail:

Making all in pktio
make[3]: Entering directory
'/home/bill/linaro/api-next/test/validation/pktio'
  CC   pktio.lo
pktio.c: In function 'queue_deq_wait_time':
pktio.c:339:13: error: storage size of 'wait' isn't known
  odp_time_t wait, end;
 ^
pktio.c:339:19: error: storage size of 'end' isn't known
  odp_time_t wait, end;
   ^
pktio.c:342:2: error: invalid use of incomplete typedef 'odp_time_t'
  wait = odp_time_local_from_ns(ns);
  ^
pktio.c:343:2: error: invalid use of incomplete typedef 'odp_time_t'
  end = odp_time_sum(odp_time_local(), wait);
  ^
pktio.c:343:21: error: type of formal parameter 1 is incomplete
  end = odp_time_sum(odp_time_local(), wait);
 ^
pktio.c:343:39: error: type of formal parameter 2 is incomplete
  end = odp_time_sum(odp_time_local(), wait);
   ^
pktio.c:348:2: error: invalid use of incomplete typedef 'odp_time_t'
  } while (odp_time_cmp(end, odp_time_local()) > 0);
  ^
pktio.c:348:24: error: type of formal parameter 1 is incomplete
  } while (odp_time_cmp(end, odp_time_local()) > 0);
^
pktio.c:348:29: error: type of formal parameter 2 is incomplete
  } while (odp_time_cmp(end, odp_time_local()) > 0);
 ^
pktio.c:339:19: error: unused variable 'end' [-Werror=unused-variable]
  odp_time_t wait, end;
   ^
pktio.c:339:13: error: unused variable 'wait' [-Werror=unused-variable]
  odp_time_t wait, end;
 ^
pktio.c: In function 'wait_for_packet':
pktio.c:356:13: error: storage size of 'wait_time' isn't known
  odp_time_t wait_time, end;
 ^
pktio.c:356:24: error: storage size of 'end' isn't known
  odp_time_t wait_time, end;
^
pktio.c:362:2: error: invalid use of incomplete typedef 'odp_time_t'
  wait_time = odp_time_local_from_ns(ns);
  ^
pktio.c:363:2: error: invalid use of incomplete typedef 'odp_time_t'
  end = odp_time_sum(odp_time_local(), wait_time);
  ^
pktio.c:363:21: error: type of formal parameter 1 is incomplete
  end = odp_time_sum(odp_time_local(), wait_time);
 ^
pktio.c:363:39: error: type of formal parameter 2 is incomplete
  end = odp_time_sum(odp_time_local(), wait_time);
   ^
pktio.c:389:2: error: invalid use of incomplete typedef 'odp_time_t'
  } while (odp_time_cmp(end, odp_time_local()) > 0);
  ^
pktio.c:389:24: error: type of formal parameter 1 is incomplete
  } while (odp_time_cmp(end, odp_time_local()) > 0);
^
pktio.c:389:29: error: type of formal parameter 2 is incomplete
  } while (odp_time_cmp(end, odp_time_local()) > 0);
 ^
pktio.c:356:24: error: unused variable 'end' [-Werror=unused-variable]
  odp_time_t wait_time, end;
^
pktio.c:356:13: error: unused variable 'wait_time' [-Werror=unused-variable]
  odp_time_t wait_time, end;
 ^
cc1: all warnings being treated as errors
Makefile:504: recipe for target 'pktio.lo' failed
make[3]: *** [pktio.lo] Error 1
make[3]: Leaving directory
'/home/bill/linaro/api-next/test/validation/pktio'
Makefile:417: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1


On Tue, Dec 8, 2015 at 5:12 PM, Mike Holmes  wrote:

> Patch sent that works for me, it depends on the compiler in use and the
> c99 vs posix standard I think
>
> On 8 December 2015 at 17:14, Bill Fischofer 
> wrote:
>
>> git bisect shows:
>>
>> 3164ccfe7e6dc548852b8f6f681069cd6d524bfc is the first bad commit
>> commit 3164ccfe7e6dc548852b8f6f681069cd6d524bfc
>> Author: Ivan Khoronzhuk 
>> Date:   Fri Dec 4 19:51:29 2015 +0200
>>
>> linux-generic: odp_time: don't use cpu cycle API to get time
>>
>> The linux-generic time API implementation shouldn't depend on cpu
>> cycle API wich is not stable enough to measure time period due to
>> dynamic frequency scaling.
>>
>> Reviewed-by: Petri Savolainen 
>> Signed-off-by: Ivan Khoronzhuk 
>> Signed-off-by: Maxim Uvarov 
>>
>> :04 04 5b252b56eaa4d7c8df9f4583d0b6e7b8db9a9fb9
>> d331e32ad2a37014cdb8133a917cd660f52b6f7c M platform
>>
>>
>> On Tue, Dec 8, 2015 at 3:55 PM, Bill Fischofer > > wrote:
>>
>>> Trying to compile a fresh clone of api-next I'm seeing the following:
>>>
>>>   CC   odp_schedule.lo
>>> odp_schedule.c: In function 'schedule_loop':
>>> odp_schedule.c:589:13: error: storage size of 'next' isn't known
>>>   odp_time_t next, wtime;
>>>  ^
>>> odp_schedule.c:589:19: error: storage size of 'wtime' isn't known
>>>   odp_time_t next, wtime;
>>>^
>>> odp_schedule.c:606:4: error: invalid use of 

Re: [lng-odp] api-next broken?

[Mike Holmes]

Yep, I just compiled what I had, but it is the same root cause, just needs
to be told to allow POSIX in that SRC.

Maxim do you just want to fix in your morning, I dont have time now tonight
so dont wait for me but you could add me as Suggested-by

On 8 December 2015 at 18:17, Bill Fischofer 
wrote:

> That helps but it looks incomplete.  With that patch applied ODP compiles
> but the CUnit tests fail:
>
> Making all in pktio
> make[3]: Entering directory
> '/home/bill/linaro/api-next/test/validation/pktio'
>   CC   pktio.lo
> pktio.c: In function 'queue_deq_wait_time':
> pktio.c:339:13: error: storage size of 'wait' isn't known
>   odp_time_t wait, end;
>  ^
> pktio.c:339:19: error: storage size of 'end' isn't known
>   odp_time_t wait, end;
>^
> pktio.c:342:2: error: invalid use of incomplete typedef 'odp_time_t'
>   wait = odp_time_local_from_ns(ns);
>   ^
> pktio.c:343:2: error: invalid use of incomplete typedef 'odp_time_t'
>   end = odp_time_sum(odp_time_local(), wait);
>   ^
> pktio.c:343:21: error: type of formal parameter 1 is incomplete
>   end = odp_time_sum(odp_time_local(), wait);
>  ^
> pktio.c:343:39: error: type of formal parameter 2 is incomplete
>   end = odp_time_sum(odp_time_local(), wait);
>^
> pktio.c:348:2: error: invalid use of incomplete typedef 'odp_time_t'
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>   ^
> pktio.c:348:24: error: type of formal parameter 1 is incomplete
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
> ^
> pktio.c:348:29: error: type of formal parameter 2 is incomplete
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>  ^
> pktio.c:339:19: error: unused variable 'end' [-Werror=unused-variable]
>   odp_time_t wait, end;
>^
> pktio.c:339:13: error: unused variable 'wait' [-Werror=unused-variable]
>   odp_time_t wait, end;
>  ^
> pktio.c: In function 'wait_for_packet':
> pktio.c:356:13: error: storage size of 'wait_time' isn't known
>   odp_time_t wait_time, end;
>  ^
> pktio.c:356:24: error: storage size of 'end' isn't known
>   odp_time_t wait_time, end;
> ^
> pktio.c:362:2: error: invalid use of incomplete typedef 'odp_time_t'
>   wait_time = odp_time_local_from_ns(ns);
>   ^
> pktio.c:363:2: error: invalid use of incomplete typedef 'odp_time_t'
>   end = odp_time_sum(odp_time_local(), wait_time);
>   ^
> pktio.c:363:21: error: type of formal parameter 1 is incomplete
>   end = odp_time_sum(odp_time_local(), wait_time);
>  ^
> pktio.c:363:39: error: type of formal parameter 2 is incomplete
>   end = odp_time_sum(odp_time_local(), wait_time);
>^
> pktio.c:389:2: error: invalid use of incomplete typedef 'odp_time_t'
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>   ^
> pktio.c:389:24: error: type of formal parameter 1 is incomplete
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
> ^
> pktio.c:389:29: error: type of formal parameter 2 is incomplete
>   } while (odp_time_cmp(end, odp_time_local()) > 0);
>  ^
> pktio.c:356:24: error: unused variable 'end' [-Werror=unused-variable]
>   odp_time_t wait_time, end;
> ^
> pktio.c:356:13: error: unused variable 'wait_time'
> [-Werror=unused-variable]
>   odp_time_t wait_time, end;
>  ^
> cc1: all warnings being treated as errors
> Makefile:504: recipe for target 'pktio.lo' failed
> make[3]: *** [pktio.lo] Error 1
> make[3]: Leaving directory
> '/home/bill/linaro/api-next/test/validation/pktio'
> Makefile:417: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
>
>
> On Tue, Dec 8, 2015 at 5:12 PM, Mike Holmes 
> wrote:
>
>> Patch sent that works for me, it depends on the compiler in use and the
>> c99 vs posix standard I think
>>
>> On 8 December 2015 at 17:14, Bill Fischofer 
>> wrote:
>>
>>> git bisect shows:
>>>
>>> 3164ccfe7e6dc548852b8f6f681069cd6d524bfc is the first bad commit
>>> commit 3164ccfe7e6dc548852b8f6f681069cd6d524bfc
>>> Author: Ivan Khoronzhuk 
>>> Date:   Fri Dec 4 19:51:29 2015 +0200
>>>
>>> linux-generic: odp_time: don't use cpu cycle API to get time
>>>
>>> The linux-generic time API implementation shouldn't depend on cpu
>>> cycle API wich is not stable enough to measure time period due to
>>> dynamic frequency scaling.
>>>
>>> Reviewed-by: Petri Savolainen 
>>> Signed-off-by: Ivan Khoronzhuk 
>>> Signed-off-by: Maxim Uvarov 
>>>
>>> :04 04 5b252b56eaa4d7c8df9f4583d0b6e7b8db9a9fb9
>>> d331e32ad2a37014cdb8133a917cd660f52b6f7c M platform
>>>
>>>
>>> On Tue, 

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[HePeng]

> 在 2015年12月8日，下午9:34，Ola Liljedahl  写道：
> 
> On 8 December 2015 at 12:42, Bill Fischofer  > wrote:
> This is an interesting topic.  I'd like to discuss this a bit during today's 
> ODP public call.  
> 
> I think the issue is that while a ring is a very useful implementation 
> construct its semantics are very SW centric.
> But isn't the use case here SW centric?
>  
> Perhaps there's opportunity here for a new Queue type that would permit an 
> implementation to implement the queue API as a ring for additional 
> performance?
> I think it is a bad idea to overload the ODP queue with another type of usage 
> and implied implementation. Better to define a new ODP object.
> 
> What are the real requirements of the "ring" as used by the cuckoo hash 
> design? Enqueue/dequeue operations. Fixed size is OK? Storing arbitrary 
> objects (not just ODP events)?

The real requirement is use the ring as a sort of container. 
Fixed Size is OK. And the ring should be used to 
store any ODP events, since it is used as a container, 
like vector in C++ STL. 


> 
>  
>   The scheduler itself could use this since its use of queues is subject to 
> the same issues.
> 
> On Mon, Dec 7, 2015 at 11:39 PM, HePeng  > wrote:
> Hi Maxim,
> I implement a new version of cuckoo hash based on the ODP buffer/pool.
> 
> As I’ve mentioned earlier, the use of ring in cuckoo hash is like to 
> the use of
> a container, e.g. a queue in C++ STL.  In current ODP implementation, I found 
> that
> the ODP queue is implemented more likely a facility for transmitting objects, 
> not
> a container to store objects. Look at the ODP queue enqueue interface:
> 
> int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
> 
> the *odp_event_t* is related to the events, but I only want to use odp_queue 
> to
> storing and retrieving objects, any objects.
> 
> 
> So I use ODP buffer/pool interfaces instead of ODP queue
> for the new cuckoo hash implementation.
> 
> However, compared to the previous implementation based on ring, this 
> version
> suffers a serious performance degradation. The evaluation is carried out on a 
> Intel
> servers. I test lookup time for 1000 lookups on a table storing 1 million 
> items.
> The ODP buffer/pool version suffers at least a 2x performance degradation.
> 
> This is the buffer/pool version, for 1M insert, and 1000 lookup time:
> 
> Average insert time = 2.383836, lookup time = 0.000353,
> 
> This is the ring version.
> 
> Average insert time = 1.629115, lookup time = 0.98
> 
> This performance degradation stems from the heavy implementation of
>  ODP buffer/pool. In the ring based one, all the key is stored in a big 
> array, and
> the ring only stores the array indexes of each key. Keys are retrieved using 
> array indexes.
> In the new one, I use ODP buffer to store the key content. Keys are retrieved 
> by
> dereferencing a *odp_buffer_t*  handle.
> 
> With this high performance degradation, I suggest moving ring into 
> the odp/api
> as a container implementation, and use the previous implementation of cuckoo 
> hash.
> 
> 
> 
> 
> 
> 
> ___
> 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[HePeng]

Let me further explain this. 

Cuckoo hash is a hash table, and as a hash table, it needs to store the 
key-value paris.
For any input, e.g. a key ( a byte string with some size), a hash table needs 
to 
calculate the hash value from the key, find the right bucket, and compare 
the input key with the keys stored in the bucket. If the two keys are equal, 
then 
return the value of the key. 

So any hash table needs to manage some memory to store the keys. 
In the previous implementation, the hash table will allocate a big 
array for storing every keys, and the ring is used to store the index of 
all the empty array slot. If you need to insert a new key, the hash table will
firstly dequeue an index from the ring, and then calculate the address 
of the empty slot (base_ptr + index * key_size), and memcpy the key into 
the array slot. 

So this is why I say the ring is used as a container, it is just used as a 
container to 
store key indices. It is quite similar to ODP buffer/pool. And this is the 
reason 
I use ODP buffer/pool to store all the keys in the new implementation.   


> 在 2015年12月9日，下午1:31，HePeng  写道：
> 
>> 
>> 在 2015年12月8日，下午9:34，Ola Liljedahl > > 写道：
>> 
>> On 8 December 2015 at 12:42, Bill Fischofer > > wrote:
>> This is an interesting topic.  I'd like to discuss this a bit during today's 
>> ODP public call.  
>> 
>> I think the issue is that while a ring is a very useful implementation 
>> construct its semantics are very SW centric.
>> But isn't the use case here SW centric?
>>  
>> Perhaps there's opportunity here for a new Queue type that would permit an 
>> implementation to implement the queue API as a ring for additional 
>> performance?
>> I think it is a bad idea to overload the ODP queue with another type of 
>> usage and implied implementation. Better to define a new ODP object.
>> 
>> What are the real requirements of the "ring" as used by the cuckoo hash 
>> design? Enqueue/dequeue operations. Fixed size is OK? Storing arbitrary 
>> objects (not just ODP events)?
> 
> The real requirement is use the ring as a sort of container. 
> Fixed Size is OK. And the ring should be used to 
> store any ODP events, since it is used as a container, 
> like vector in C++ STL. 
> 
> 
>> 
>>  
>>   The scheduler itself could use this since its use of queues is subject to 
>> the same issues.
>> 
>> On Mon, Dec 7, 2015 at 11:39 PM, HePeng > > wrote:
>> Hi Maxim,
>> I implement a new version of cuckoo hash based on the ODP 
>> buffer/pool.
>> 
>> As I’ve mentioned earlier, the use of ring in cuckoo hash is like to 
>> the use of
>> a container, e.g. a queue in C++ STL.  In current ODP implementation, I 
>> found that
>> the ODP queue is implemented more likely a facility for transmitting 
>> objects, not
>> a container to store objects. Look at the ODP queue enqueue interface:
>> 
>> int odp_queue_enq(odp_queue_t queue, odp_event_t ev);
>> 
>> the *odp_event_t* is related to the events, but I only want to use odp_queue 
>> to
>> storing and retrieving objects, any objects.
>> 
>> 
>> So I use ODP buffer/pool interfaces instead of ODP queue
>> for the new cuckoo hash implementation.
>> 
>> However, compared to the previous implementation based on ring, this 
>> version
>> suffers a serious performance degradation. The evaluation is carried out on 
>> a Intel
>> servers. I test lookup time for 1000 lookups on a table storing 1 million 
>> items.
>> The ODP buffer/pool version suffers at least a 2x performance degradation.
>> 
>> This is the buffer/pool version, for 1M insert, and 1000 lookup time:
>> 
>> Average insert time = 2.383836, lookup time = 0.000353,
>> 
>> This is the ring version.
>> 
>> Average insert time = 1.629115, lookup time = 0.98
>> 
>> This performance degradation stems from the heavy implementation of
>>  ODP buffer/pool. In the ring based one, all the key is stored in a big 
>> array, and
>> the ring only stores the array indexes of each key. Keys are retrieved using 
>> array indexes.
>> In the new one, I use ODP buffer to store the key content. Keys are 
>> retrieved by
>> dereferencing a *odp_buffer_t*  handle.
>> 
>> With this high performance degradation, I suggest moving ring into 
>> the odp/api
>> as a container implementation, and use the previous implementation of cuckoo 
>> hash.
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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 
>> 

Re: [lng-odp] [PATCHv2] doc: userguide: add application programming section

[Mike Holmes]

Using patch:
lng-odp_PATCHv2_doc_userguide_add_application_programming_section.mbox
  Trying to apply patch
  Patch applied
Applying: doc: userguide: add application programming section
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:446:
indent with spaces.
odp_event_t ev;
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:613:
indent with spaces.
odp_init_local();
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:616:
indent with spaces.
while (1) {
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:617:
indent with spaces.
   ev = odp_schedule(_q, ODP_SCHED_WAIT);
warning: 4 lines add whitespace errors.
0001-doc-userguide-add-application-programming-section.patch: unified diff
output, UTF-8 Unicode text


On 7 December 2015 at 13:05, Bill Fischofer 
wrote:

> Continue the refinement of the user guide,


This text does not add value, all work is ongoing as patches are added,
better to list what changed



> completing the reformatting to
> standard asciidoc style and expanding the ODP Applicaition


Application


> Programming
> section, including a reorganized and expanded discussion of ODP queues.
>
> Signed-off-by: Bill Fischofer 
> ---
>  doc/users-guide/users-guide.adoc | 451
> +++
>  1 file changed, 359 insertions(+), 92 deletions(-)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index cf77fa0..d660fb8 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -8,16 +8,19 @@ OpenDataPlane (ODP)  Users-Guide
>  Abstract
>  
>  This document is intended to guide a new ODP application developer.
> -Further details about ODP may be found at the http://opendataplane.org[ODP]
> home page.
> +Further details about ODP may be found at the http://opendataplane.org
> [ODP]
> +home page.
>
>  .Overview of a system running ODP applications
>  image::../images/overview.png[align="center"]
>
> -ODP is an API specification that allows many implementations to provide
> platform independence, automatic hardware acceleration and CPU scaling to
> high performance networking  applications.
> -This document describes how to write an application that can successfully
> take advantage of the API.
> +ODP is an API specification that allows many implementations to provide
> +platform independence, automatic hardware acceleration and CPU scaling to
> +high performance networking  applications. This document describes how to
> +write an application that can successfully take advantage of the API.
>
>  :numbered:
> -== Introduction ==
> +== Introduction
>  .OpenDataPlane Components
>  image::../images/odp_components.png[align="center"]
>
> @@ -42,7 +45,7 @@ ODP API specification--that is the responsibility of
> each ODP implementation.
>  * Application-centric.  Covers functional needs of data plane
> applications.
>  * Ensures portability by specifying the functional behavior of ODP.
>  * Defined jointly and openly by application writers and platform
> implementers.
> -* Archiected to be implementable on a wide range of platforms efficiently
> +* Architected to be implementable on a wide range of platforms efficiently
>  * Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
>
>  .ODP Implementations
> @@ -68,7 +71,7 @@ where the application will run on a target platform
> chosen by someone else.
>  * One size does not fit all--supporting multiple implementations allows
> ODP
>  to adapt to widely differing internals among platforms.
>  * Anyone can create an ODP implementation tailored to their platform
> -* Distribution and mainteinance of each implementation is as owner wishes
> +* Distribution and maintenance of each implementation is as owner wishes
>- Open source or closed source as business needs determine
>- Have independent release cycles and service streams
>  * Allows HW and SW innovation in how ODP APIs are implemented on each
> platform.
> @@ -100,7 +103,7 @@ drivers supported by DPDK.
>  they are derived from a reference implementation.
>
>  .ODP Validation Test Suite
> -Third, to enure consistency between different ODP implementations, ODP
> +Third, to ensure consistency between different ODP implementations, ODP
>  consists of a validation suite that verifies that any given
> implementation of
>  ODP faithfully provides the specified functional behavior of each ODP API.
>  As a separate open source component, the validation suite may be used by
> @@ -115,16 +118,16 @@ ODP API specification.
>  * Key to ensuring application portability across all ODP implementations
>  * Tests that ODP implementations conform to the specified functional
> behavior
>  of ODP APIs.
> -* Can be run at any time by users and vendors to validat implementations
> -od ODP.
> +* Can be run at any time by users and vendors to validate implementations

Re: [lng-odp] api-next broken?

[Bill Fischofer]

git bisect shows:

3164ccfe7e6dc548852b8f6f681069cd6d524bfc is the first bad commit
commit 3164ccfe7e6dc548852b8f6f681069cd6d524bfc
Author: Ivan Khoronzhuk 
Date:   Fri Dec 4 19:51:29 2015 +0200

linux-generic: odp_time: don't use cpu cycle API to get time

The linux-generic time API implementation shouldn't depend on cpu
cycle API wich is not stable enough to measure time period due to
dynamic frequency scaling.

Reviewed-by: Petri Savolainen 
Signed-off-by: Ivan Khoronzhuk 
Signed-off-by: Maxim Uvarov 

:04 04 5b252b56eaa4d7c8df9f4583d0b6e7b8db9a9fb9
d331e32ad2a37014cdb8133a917cd660f52b6f7c M platform


On Tue, Dec 8, 2015 at 3:55 PM, Bill Fischofer 
wrote:

> Trying to compile a fresh clone of api-next I'm seeing the following:
>
>   CC   odp_schedule.lo
> odp_schedule.c: In function 'schedule_loop':
> odp_schedule.c:589:13: error: storage size of 'next' isn't known
>   odp_time_t next, wtime;
>  ^
> odp_schedule.c:589:19: error: storage size of 'wtime' isn't known
>   odp_time_t next, wtime;
>^
> odp_schedule.c:606:4: error: invalid use of incomplete typedef 'odp_time_t'
> wtime = odp_time_local_from_ns(wait);
> ^
> odp_schedule.c:607:4: error: invalid use of incomplete typedef 'odp_time_t'
> next = odp_time_sum(odp_time_local(), wtime);
> ^
> odp_schedule.c:607:24: error: type of formal parameter 1 is incomplete
> next = odp_time_sum(odp_time_local(), wtime);
> ^
> odp_schedule.c:607:42: error: type of formal parameter 2 is incomplete
> next = odp_time_sum(odp_time_local(), wtime);
>   ^
> odp_schedule.c:612:3: error: invalid use of incomplete typedef 'odp_time_t'
>if (odp_time_cmp(next, odp_time_local()) < 0)
>^
> odp_schedule.c:612:20: error: type of formal parameter 1 is incomplete
>if (odp_time_cmp(next, odp_time_local()) < 0)
> ^
> odp_schedule.c:612:26: error: type of formal parameter 2 is incomplete
>if (odp_time_cmp(next, odp_time_local()) < 0)
>   ^
> odp_schedule.c:589:19: error: unused variable 'wtime'
> [-Werror=unused-variable]
>   odp_time_t next, wtime;
>^
> odp_schedule.c:589:13: error: unused variable 'next'
> [-Werror=unused-variable]
>   odp_time_t next, wtime;
>  ^
> cc1: all warnings being treated as errors
> Makefile:757: recipe for target 'odp_schedule.lo' failed
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] api-next broken?

[Bill Fischofer]

Trying to compile a fresh clone of api-next I'm seeing the following:

  CC   odp_schedule.lo
odp_schedule.c: In function 'schedule_loop':
odp_schedule.c:589:13: error: storage size of 'next' isn't known
  odp_time_t next, wtime;
 ^
odp_schedule.c:589:19: error: storage size of 'wtime' isn't known
  odp_time_t next, wtime;
   ^
odp_schedule.c:606:4: error: invalid use of incomplete typedef 'odp_time_t'
wtime = odp_time_local_from_ns(wait);
^
odp_schedule.c:607:4: error: invalid use of incomplete typedef 'odp_time_t'
next = odp_time_sum(odp_time_local(), wtime);
^
odp_schedule.c:607:24: error: type of formal parameter 1 is incomplete
next = odp_time_sum(odp_time_local(), wtime);
^
odp_schedule.c:607:42: error: type of formal parameter 2 is incomplete
next = odp_time_sum(odp_time_local(), wtime);
  ^
odp_schedule.c:612:3: error: invalid use of incomplete typedef 'odp_time_t'
   if (odp_time_cmp(next, odp_time_local()) < 0)
   ^
odp_schedule.c:612:20: error: type of formal parameter 1 is incomplete
   if (odp_time_cmp(next, odp_time_local()) < 0)
^
odp_schedule.c:612:26: error: type of formal parameter 2 is incomplete
   if (odp_time_cmp(next, odp_time_local()) < 0)
  ^
odp_schedule.c:589:19: error: unused variable 'wtime'
[-Werror=unused-variable]
  odp_time_t next, wtime;
   ^
odp_schedule.c:589:13: error: unused variable 'next'
[-Werror=unused-variable]
  odp_time_t next, wtime;
 ^
cc1: all warnings being treated as errors
Makefile:757: recipe for target 'odp_schedule.lo' failed
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp