Re: [lng-odp] IPsec API finialization

[Nikhil Agarwal]

On 7 September 2017 at 14:09, Peltonen, Janne (Nokia - FI/Espoo) <
janne.pelto...@nokia.com> wrote:

> Hi,
>
> Comments below:
>
> Bill Fischofer wrote:
> > As discussed during today's ARCH call, we need to close on the
> > remaining IPsec confusion surrounding the definition of
> > odp_ipsec_sa_disable().
> >
> > The main scenario that this API is designed to address, from an
> > application standpoint is as follows:
> >
> > - Application has one or more active SAs that are receiving inline RX
> > IPsec traffic.
> >
> > - An active SA needs to be deactivated / destroyed for some reason
> >
> > - Application needs to be sure that "in flight" events that it is not
> > yet aware of are in a defined state.
> >
> > odp_ipsec_sa_disable() allows the application to tell the ODP
> > implementation that it wants to deactivate an SA so that it can be
> > destroyed. In response to this the implementation is expected to:
> >
> > - Stop making internal use of this SA
> >
> > - Tell the application when the SA is quiesced as far as the
> > implementation is concerned.
> >
> > As currently defined, the way this second step is communicated to the
> > application is via a status event posted to the event queue associated
> > with the SA.
> >
> > The main point of the discussion is that NXP HW does not have a direct
> > analog to this API. As Nikhil explained it, the "quiescing" function
> > is assumed to be an application responsibility such that by the time
> > an application calls odp_ipsec_sa_destroy() it already knows that the
> > SA is inactive.
> >
> > When an application is using IPsec in lookaside mode this is a not
> > unreasonable requirement, as the application explicitly invokes every
> > IPsec operation, so it knows which operations are in flight.
>
> Yes, except that with fragmentation offload combined with IPsec
> offload the application cannot easily know when it has received all
> the result packets generated by single IPsec operation. If there
> were always one result packet per operation, simple SA reference
> counting in the application would work.
>
> We discussed this with Petri when designing the API and considered
> various options but concluded that the disable completion event
> is a simple solution with low overhead when an SA is not being
> disabled. And since event queues are a central concept of ODP and
> of its asynchronous APIs, informing the disable completion through
> an event seems natural.
>
> Other options that do not work that well:
>
> - Application inspects the result fragments to see when it has got
>   them all. This would require almost the same work as fragment
>   reassembly and it would introduce state that would have to be
>   synchronized between multiple threads (since the result packets
>   may get scheduled to different threads).
>
> - ODP implementation marks the last result fragment with a special
>   bit. This may perhaps be nasty for some HW implementations that
>   parallelize the processing and do not know which of the fragments
>   gets queued the last. If the application reference counts the
>   SAs (as it most likely has to do to safely destroy the SA and
>   safely delete its own state for the SA), it can unref and SA
>   when it sees the marked "last" result fragment but only after
>   it has processed the other fragments. This imposes synchronization
>   overhead (e.g. ordered lock if the SA queue is ordered and
>   scheduled) for the normal processing path when the SA is not
>   being deleted.
>
> - Variations of the above (e.g. returning the total number of result
>   fragments for one IPsec operation in all the results) have
>   similar problems regarding parallelization in the implementation
>   and synchronization need in the application.
>
> The disable completion event also requires synchronization (e.g.
> in the form of an ordered lock but only when the SA is being deleted)
>
> >
> > For inline processing, however, it's less clear what the application
> > can do since packets may be in process that the application has yet to
> > see. If an application calls odp_ipsec_sa_destroy() the implementation
> > can pick a point after which all packets matching that SA are
> > ignored/dropped, but the issue is what about packets that have been
> > processed and are sitting in event queues that the application is not
> > yet aware of?
> >
> > If an application receives an event that was processed under a
> > destroyed SA, the concern is that it not segfault or experience some
> > other anomaly trying to access any application context that it had
> > associated with that now-defunct SA.
> >
> > The solution proposed in PR #109[1] is that odp_ipsec_sa_disable() be
> > allowed to complete synchronously rather than asynchronously, which
> > means that the NXP implementation can treat it as an effective NOP
> > since it doesn't map to any HW function. While this solves one
> > problem, there is still the problem of how to deal with events that
> > are already enqueue

Re: [lng-odp] [API-NEXTv4 1/3] api: classification: add support for packet hashing in classification

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
Balasubramanian Manoharan
Sent: Thursday, July 20, 2017 8:07 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXTv4 1/3] api: classification: add support for packet 
hashing in classification

Enable packet hashing per CoS to be able to distribute incoming packets to 
multiple queues linked with a CoS.

Signed-off-by: Balasubramanian Manoharan 
---
v4: incorporates review comments from Petri

 include/odp/api/spec/classification.h | 83 ---
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/include/odp/api/spec/classification.h 
b/include/odp/api/spec/classification.h
index 39831b2..315afaa 100644
--- a/include/odp/api/spec/classification.h
+++ b/include/odp/api/spec/classification.h
@@ -4,7 +4,6 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-
 /**
  * @file
  *
@@ -19,12 +18,13 @@
 extern "C" {
 #endif
 
+#include 
+#include 
 /** @defgroup odp_classification ODP CLASSIFICATION
  *  Classification operations.
  *  @{
  */
 
-
 /**
  * @typedef odp_cos_t
  * ODP Class of service handle
@@ -126,6 +126,13 @@ typedef struct odp_cls_capability_t {
/** Maximum number of CoS supported */
unsigned max_cos;
 
+   /** Maximun number of queue supported per CoS
+* if the value is 1, then hashing is not supported*/
+   unsigned max_hash_queues;
+
+   /** Protocol header combination supported for Hashing */
+   odp_pktin_hash_proto_t hash_protocols;
+
/** A Boolean to denote support of PMR range */
odp_bool_t pmr_range_supported;
 } odp_cls_capability_t;
@@ -164,9 +171,33 @@ typedef enum {
  * 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_cls_drop_t drop_policy; /**< Drop policy associated with CoS */
+   /* Number of queues to be linked to this CoS.
+* If the number is greater than 1 then hashing has to be
+* configured. If number is equal to 1 then hashing is disabled
+* and queue has to be configured by the application.
+* When hashing is enabled the queues are created by the implementation
+* then application need not configure any queue to the class of service
+* Depening on the implementation this number might be rounded-off to
+* nearest supported value (e.g power of 2)
+* */
+   uint32_t num_queue;
+
+   /** Queue parameters */
+   odp_queue_param_t queue_param;
+
+   /* Protocol header fields which are included in packet input
+* hash calculation */
+   odp_pktin_hash_proto_t hash_proto;
+
+   /* If hashing is disabled, then application has to configure
+* this queue and packets are delivered to this queue */
+   odp_queue_t queue;
+
+   /* Pool associated with CoS */
+   odp_pool_t pool;
+
+   /* Drop policy associated with CoS */
+   odp_cls_drop_t drop_policy;
 } odp_cls_cos_param_t;
 
 /**
@@ -209,6 +240,23 @@ int odp_cls_capability(odp_cls_capability_t *capability);  
odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t *param);
 
 /**
+ * Queue hash result
+ * Returns the queue within a CoS in which a particular packet will be 
+enqueued
+ * based on the packet parameters and hash protocol field configured 
+with the
+ * class of service.
+ *
+ * @param  cos class of service
+ * @param  packet  Packet handle
+ *
+ * @retval Returns the queue handle on which this packet will be
+ * enqueued.
+ * @retval ODP_QUEUE_INVALID for error case
+ *
+ * @note The packet has to be updated with valid header pointers L2, L3 and L4.
+ */
+odp_queue_t odp_queue_hash_result(odp_cos_t cos, odp_packet_t packet);
What is the purpose of the API? Why and how it will be useful for applications? 
Application may use the calculated HASH values for different purposes but queue 
handle?
+
+/**
  * Discard a class-of-service along with all its associated resources
  *
  * @param[in]  cos_id  class-of-service instance.
@@ -245,6 +293,31 @@ int odp_cos_queue_set(odp_cos_t cos_id, odp_queue_t 
queue_id);  odp_queue_t odp_cos_queue(odp_cos_t cos_id);
 
 /**
+ * Get the number of queues linked with the specific class-of-service
+ *
+ * @param  cos_id  class-of-service instance.
+ *
+ * @return Number of queues linked with the 
class-of-service.
+ */
+uint32_t odp_cos_num_queue(odp_cos_t cos_id);
+
+/**
+ * Get the list of queue associated with the specific class-of-service
+ *
+ * @param[in]  cos_id  class-of-service instance.
+ *
+ * @param[out] queue   Array of queue handles associated
+ * with the class-of-service.
+ *
+ * @param[in]  num Maximum n

Re: [lng-odp] [API-NEXT PATCH] api: ipsec: add warning status event

[Nikhil Agarwal]

Reviewed-by: Nikhil Agarwal 

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Friday, July 14, 2017 6:14 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH] api: ipsec: add warning status event

Add status ID for warning messages. Outbound inline soft lifetime expiration is 
currently the only source of these events. API spec keeps simple when the same 
warning structure is shared with IPSEC packet and status events.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
de126c37..7085bc0d 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -1123,8 +1123,26 @@ typedef struct odp_ipsec_packet_result_t {
  * IPSEC status ID
  */
 typedef enum odp_ipsec_status_id_t {
-   /** Response to SA disable command */
-   ODP_IPSEC_STATUS_SA_DISABLE = 0
+   /** Response to SA disable command
+*
+*  Following status event (odp_ipsec_status_t) fields have valid
+*  content, other fields must be ignored:
+*  - sa:   The SA that was requested to be disabled
+*  - result:   Operation result
+*/
+   ODP_IPSEC_STATUS_SA_DISABLE = 0,
+
+   /** Warning from inline IPSEC processing
+*
+*  Following status event (odp_ipsec_status_t) fields have valid
+*  content, other fields must be ignored:
+*  - sa:   The SA that caused the warning
+*  - warn: The warning(s) reported by this event
+*
+*  This status event is generated only for outbound SAs in
+*  ODP_IPSEC_OP_MODE_INLINE mode.
+*/
+   ODP_IPSEC_STATUS_WARN
 
 } odp_ipsec_status_id_t;
 
@@ -1135,15 +1153,18 @@ typedef struct odp_ipsec_status_t {
/** IPSEC status ID */
odp_ipsec_status_id_t id;
 
-   /** Return value from the operation
+   /** IPSEC SA that was target of the operation */
+   odp_ipsec_sa_t sa;
+
+   /** Result of the operation
 *
 *   0:Success
 *  <0:Failure
 */
-   int ret;
+   int result;
 
-   /** IPSEC SA that was target of the operation */
-   odp_ipsec_sa_t sa;
+   /** Warnings of an ODP_IPSEC_STATUS_WARN status event */
+   odp_ipsec_warn_t warn;
 
 } odp_ipsec_status_t;
 
--
2.13.0

Re: [lng-odp] [API-NEXT PATCH v3 1/9] api: ipsec: add salt parameter

[Nikhil Agarwal]

For the series:
Reviewed-by: Nikhil Agarwal 

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Wednesday, July 12, 2017 7:25 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 1/9] api: ipsec: add salt parameter

Added a parameter for passing salt/nonce for algorithms that need it. 
Currently, only AES GCM needs it with 4 bytes of salt. Later on, other cipher 
(or auth) algorithms may need also salt/nonce data.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
e602e4b8..9f061961 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -378,6 +378,15 @@ typedef struct odp_ipsec_crypto_param_t {
/** Cipher key */
odp_crypto_key_t cipher_key;
 
+   /** Extra keying material for cipher key
+*
+*  Additional data used as salt or nonce if the algorithm requires it,
+*  other algorithms ignore this field. These algorithms require this
+*  field set:
+*  - AES_GCM: 4 bytes of salt
+**/
+   odp_crypto_key_t cipher_key_extra;
+
/** Authentication algorithm */
odp_auth_alg_t auth_alg;
 
--
2.13.0

Re: [lng-odp] [API-NEXT PATCH v3] api: pool: additional packet length configuration

[Nikhil Agarwal]

This concept for sub-pools within a pool is adding unnecessary complexity to 
pool configurations. What is the purpose of this? We don't support having 
multiple size buffers in same pool. In case application wants to attach 
multiple pools to same pktio, we can introduce an API to attach pool to pktio. 
In case of sub-pools there will be ambiguity that which sub-pool is used for 
odp_packet_alloc.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Thursday, June 15, 2017 7:51 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3] api: pool: additional packet length 
configuration

Added packet pool parameters for more fine grained pool configuration. The 
basic usage of the parameters is not changed, except that implementation may 
now round up 'num' by default.
Application can limit the round up with new 'max_num' parameter.
Another new parameter (opt) allows application give hints and requirements 
about e.g. memory to be used for a pool (or parts of the pool).

Additionally, pool configuration may be extended with a table of num/len/opt 
values. This gives application more flexibility to specify requirements for 
various packet sizes.

For example, the new specification allows to create this kind of
pool:

^
|
max_num | - - - - - - - -
|
|   *
NUM |   * *
|   * * *
| o * * * *
| o * * * * *
+--->
  LEN

o == small number of short packets into fast memory
* == all other packets into DDR

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/pool.h | 132 +++-
 1 file changed, 118 insertions(+), 14 deletions(-)

diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h index 
6fc5b6b4..6b4e7495 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -41,6 +41,9 @@ extern "C" {
  * Maximum pool name length in chars including null char
  */
 
+/** Maximum number of packet pool subparameters */ #define 
+ODP_POOL_PKT_SUB_MAX  7
+
 /**
  * Pool capabilities
  */
@@ -156,6 +159,30 @@ typedef struct odp_pool_capability_t {  int 
odp_pool_capability(odp_pool_capability_t *capa);
 
 /**
+ * Pool memory type
+ */
+typedef enum odp_pool_mem_type_t {
+   /** Default memory type */
+   ODP_POOL_MEM_DEFAULT = 0,
+
+   /** Fast memory. Some implementations may have a restricted amount of
+*  (e.g. chip internal) pool memory that is faster access than the
+*  default memory type. */
+   ODP_POOL_MEM_FAST
+
+} odp_pool_mem_type_t;
+
+/**
+ * Additional options for packet pool creation  */ typedef struct 
+odp_pool_pkt_opt_t {
+   /** Pool memory type. Hint which memory type should be used for the
+*  pool or a subset of the pool. */
+   odp_pool_mem_type_t mem_type;
+
+} odp_pool_pkt_opt_t;
+
+/**
  * Pool parameters
  * Used to communicate pool creation options.
  * @note A single thread may not be able to allocate all 'num' elements @@ 
-185,35 +212,96 @@ typedef struct odp_pool_param_t {
 
/** Parameters for packet pools */
struct {
-   /** The number of packets that the pool must provide
-   that are packet length 'len' bytes or smaller.
-   The maximum value is defined by pool capability
-   pkt.max_num. */
+   /** The minimum number of packets that are packet length
+*  'len' bytes or smaller. The maximum value is defined
+*  by pool capability pkt.max_num. An implementation
+*  may round up the value, as long as the 'max_num'
+*  parameter below is not violated.
+*/
uint32_t num;
 
-   /** Minimum packet length that the pool must provide
-   'num' packets. The number of packets may be less
-   than 'num' when packets are larger than 'len'.
-   The maximum value is defined by pool capability
-   pkt.max_len. Use 0 for default. */
+   /** The minimum packet length that at least 'num'
+*  packets are required. The maximum value is defined
+*  by pool capability pkt.max_len. Use 0 for default.
+*/
uint32_t len;
 
+   /** Packet pool options
+*
+*  Options contain additional hints and requirements,
+*  which quide implementation e.g. to select correct
+*  memory type for the pool.
+*/
+   odp_pool_pkt_opt_t opt;
+
+ 

Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event

[Nikhil Agarwal]

For the series:
Reviewed-by: Nikhil Agarwal 

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Wednesday, June 21, 2017 6:58 PM
To: Petri Savolainen 
Cc: lng-odp-forward 
Subject: Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event

For the series:
Reviewed-by: Balasubramanian Manoharan 

On 16 June 2017 at 16:19, Petri Savolainen 
wrote:

> Applies on top of: "[API-NEXT PATCH v2 0/2] IPsec API update"
>
> Input and output of IPSEC operations are packets. Parameter and result 
> structures are cleaner when packet arrays are direct parameters to 
> functions. Also API is more flexible for application or API pipelining 
> when output is packets with additional metadata. Application or API 
> pipeline stages which do not care about IPSEC results may work on 
> basic packet metadata.
>
> v3:
>   * typo corrected (Bill)
>
> v2:
>   * Introduce event subtype
> * event type "packet" is the same for all packets
> * event subtype "packet_ipsec" indicates that a packet contain 
> IPSEC results
>   * Added output packet format description, which was accidentally left out
> from previous version (moved text from deleted result type to
> odp_ipsec_in() / odp_ipsec_out() documentation)
>
>
> Petri Savolainen (3):
>   api: event: add subtype to expand event type
>   api: ipsec: change IPSEC result to packet
>   api: ipsec: disable event is the last event
>
>  include/odp/api/spec/event.h   |  80 +++-
>  include/odp/api/spec/ipsec.h   | 417
> -
>  include/odp/arch/default/api/abi/event.h   |   9 +-
>  .../include/odp/api/plat/event_types.h |   8 +-
>  platform/linux-generic/odp_ipsec.c |  67 +++-
>  5 files changed, 372 insertions(+), 209 deletions(-)
>
> --
> 2.13.0
>
>

Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event

[Nikhil Agarwal]

Some queries:

- Now since IPSEC, and simple IPSEC packets are delivered through same 
ODP_EVENT_TYPE_PACKET, how does application knows whether L2_HEADER was valid?? 
Does application always have to check on subtype?
- Also, do we need separate odp_ipsec_packet_to_event APIs(and vice versa) now? 
If yes, it will defeat the purpose of subtypes.
- Does error in IPSEC operation affects, packet error flags??
- Since IN/OUT params for IPSEC operations are different, does NUM_SA=0 is a 
valid input for out_sa_params?
- ODP_EVENT_IPSEC_STATUS events are delivered on SA queues or default queue?
- Will per packet checksum override work in conjunction with IPSEC_SA settings 
as well?

Regards
Nikhil



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill 
Fischofer
Sent: Saturday, June 17, 2017 3:46 AM
To: Petri Savolainen 
Cc: lng-odp-forward 
Subject: Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event

This should still be reviewed by Bala and Nikhil with respect to their HW, but 
these changes resolve all of the concerns I had with the original version. For 
his series:

Reviewed-by: Bill Fischofer 

On Fri, Jun 16, 2017 at 5:49 AM, Petri Savolainen  
wrote:
> Applies on top of: "[API-NEXT PATCH v2 0/2] IPsec API update"
>
> Input and output of IPSEC operations are packets. Parameter and result 
> structures are cleaner when packet arrays are direct parameters to 
> functions. Also API is more flexible for application or API pipelining 
> when output is packets with additional metadata. Application or API 
> pipeline stages which do not care about IPSEC results may work on 
> basic packet metadata.
>
> v3:
>   * typo corrected (Bill)
>
> v2:
>   * Introduce event subtype
> * event type "packet" is the same for all packets
> * event subtype "packet_ipsec" indicates that a packet contain IPSEC 
> results
>   * Added output packet format description, which was accidentally left out
> from previous version (moved text from deleted result type to
> odp_ipsec_in() / odp_ipsec_out() documentation)
>
>
> Petri Savolainen (3):
>   api: event: add subtype to expand event type
>   api: ipsec: change IPSEC result to packet
>   api: ipsec: disable event is the last event
>
>  include/odp/api/spec/event.h   |  80 +++-
>  include/odp/api/spec/ipsec.h   | 417 
> -
>  include/odp/arch/default/api/abi/event.h   |   9 +-
>  .../include/odp/api/plat/event_types.h |   8 +-
>  platform/linux-generic/odp_ipsec.c |  67 +++-
>  5 files changed, 372 insertions(+), 209 deletions(-)
>
> --
> 2.13.0
>

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Honnappa 
Nagarahalli
Sent: Friday, June 16, 2017 12:51 AM
To: Bala Manoharan 
Cc: lng-odp-forward 
Subject: Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

On 15 June 2017 at 13:02, Bala Manoharan  wrote:
>
>
> Regards,
> Bala
>
> On 15 June 2017 at 23:20, Honnappa Nagarahalli 
>  wrote:
>>
>> On 15 June 2017 at 10:58, Bala Manoharan 
>> wrote:
>> > On 15 June 2017 at 20:00, Francois Ozog 
>> > wrote:
>> >
>> >> I wonder then how packet receive in HW driven packet buffers is 
>> >> handled, may be with device memory
>> >>
>> >> Can you explain the cases of packet receive with ODP application 
>> >> supplied (through packetio open) mempools?
>> >>
>> >
>> > There needs to be atleast one pool linked to a pktio interface and there
>> > can be more than one if application wants to configure different pools
>> > for
>> > different flows. The configuration of the pool is given by the
>> > application
>> > so that any traffic burst in a single flow does not overload the entire
>> > system processing for other flows.
>> >
>> > So when application configures a packet pool we allocate internal shared
>> > memory and pool allocator and link it to  the pktio interface. When
>> > packet
>> > is received in the pktio interface the packet is allocated from the
>> > linked
>> > pool.
>>
>> When you say 'internal shared memory', do you mean the memory is
>> shared between the CPU cores and the hardware accelerators? I did not
>> understand the 'pool allocator'. My understanding from your earlier
>> email is that the pool is created (and all the packet buffers
>> instantiated) when odp_pool_create API is called and pool is linked to
>> the pktio in odp_pktio_open call.
>
>
> 'pool allocator' is a HW module which basically holds list of pointers from
> a memory location and provides pointers when someone calls alloc from the
> pool.
> pool is created when you call odp_pool_create().
> pktio is created with odp_pktio_open() which takes pool as an input
> argument.
> pool is linked to the pktio when you call odp_pktio_start()
> Hope its clear.
>

Thanks Bala. That is clear. Is the internal memory shared between CPUs
and pktio device?

Yes. Pool is the interface between them. Whoever needs buffer(pktio or CPU), 
will  ask buffer pool to provide a buffer.
> Regards,
> Bala
>>
>>
>> >
>> > Does this answer your question?
>> >
>> > Regards,
>> > Bala
>> >
>> >>
>> >> FF
>> >>
>> >> On 15 June 2017 at 15:42, Bala Manoharan 
>> >> wrote:
>> >>
>> >>> Add on. It is also possible that the pool might not be linked to any
>> >>> pktio
>> >>> eg buffer pools, hence in implementation we can not wait for the pool
>> >>> to
>> >>> be
>> >>> linked to pktio.
>> >>>
>> >>> Regards,
>> >>> Bala
>> >>>
>> >>> On 15 June 2017 at 18:11, Bill Fischofer 
>> >>> wrote:
>> >>>
>> >>> > A pool may be associated with a pktio at open time, but this
>> >>> > association is not exclusive. In theory an ODP implementation could
>> >>> > defer actual pool creation until it was first used, but such an
>> >>> > approach would be unlikely to yield any real benefits while creating
>> >>> > a
>> >>> > lot of complications along the way since odp_pool_create() is the
>> >>> > only
>> >>> > opportunity the implementation has to fail the pool creation in a
>> >>> > defined manner.
>> >>> >
>> >>> > On Thu, Jun 15, 2017 at 2:29 AM, Bala Manoharan
>> >>> >  wrote:
>> >>> > > Same here. Pool is created during odp_pool_create API.
>> >>> > >
>> >>> > >
>> >>> > > Regards,
>> >>> > > Bala
>> >>> > >
>> >>> > > On 15 June 2017 at 12:36, Nikhil Agarwal 
>> >>> wrote:
>> >>> > >
>> >>> > >> Pool is created at odp_pool_create only. You can allocate packets
>> >>> form
>> >>> > it
>> >>&

Re: [lng-odp] Mem pool creation in Cavium/NXP implementations

[Nikhil Agarwal]

Pool is created at odp_pool_create only. You can allocate packets form it even 
before pktio_open.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Honnappa 
Nagarahalli
Sent: Thursday, June 15, 2017 9:27 AM
To: lng-odp-forward 
Subject: [lng-odp] Mem pool creation in Cavium/NXP implementations

Hi Bala/Nikhil,
I was wondering when is the memory pool created in your implementation of 
ODP? The programming model is that the application creates the memory pool and 
passes that pool to the pkt I/O during packet I/O open call. Do you actually 
create the pool when the application calls odp_pool_create? Or is the pool 
created during packet I/O open?

Appreciate your answers.

Thank you,
Honnappa

Re: [lng-odp] [API-NEXT PATCH v2 2/2] api: ipsec: add max number of cos capability

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Friday, June 02, 2017 3:08 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v2 2/2] api: ipsec: add max number of cos 
capability

Added capability for maximum number of different CoS in CLS pipelining.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
24f9fb18..ed4a470e 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -262,6 +262,12 @@ typedef struct odp_ipsec_capability_t {
 */
odp_support_t pipeline_cls;
 
+   /** Maximum number of different destination CoSes in classification
+*  pipelining. The same CoS may be used for many SAs. This is equal or
+*  less than 'max_cos' capability in classifier API.
+*/
+   uint32_t max_cls_cos;
+
We discussed to add maximum number of IPSEC queues as well.
/** Soft expiry limit in seconds support
 *
 *  0: Limit is not supported
@@ -679,7 +685,8 @@ typedef struct odp_ipsec_sa_param_t {
 *  classification through this CoS. Other result events are sent to
 *  'dest_queue'. This field is considered only when 'pipeline' is
 *  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
+*  interface default CoS. The maximum number of different CoS supported
+*  is defined by IPsec capability max_cls_cos.
 */
odp_cos_t dest_cos;
 
--
2.11.0

[lng-odp] [API-NEXT v3] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/ipsec.h | 64 ++--
 include/odp/api/spec/packet_io.h | 16 ++
 2 files changed, 44 insertions(+), 36 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index e83494d..90ba004 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -59,8 +59,12 @@ typedef enum odp_ipsec_op_mode_t {
/** Inline IPSEC operation
  *
  * Packet input/output is connected directly to IPSEC inbound/outbound
- * processing. Application uses asynchronous or inline IPSEC
- * operations.
+ * processing. Packet post IPSEC operations are delivered to virtual
+ * PKTIO interface corresponding to the PKTIO on which packet was 
+ * recieved. Further classification/Hashing(inbound) will be applied to
+ * packet post IPSEC as defined in PKTIO configuration of virtual
+ * interface.
+ * Application may use asynchronous IPSEC operations as well.
  */
ODP_IPSEC_OP_MODE_INLINE,
 
@@ -226,6 +230,24 @@ typedef struct odp_ipsec_outbound_config_t {
 
 } odp_ipsec_outbound_config_t;
 
+typedef union odp_ipsec_protocols_t {
+   /** Cipher algorithms */
+   struct {
+   /** ODP_IPSEC_ESP */
+   uint32_t esp: 1;
+
+   /** ODP_IPSEC_AH */
+   uint32_t ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+*
+* This field can be used to set/clear all flags, or bitwise
+* operations over the entire structure. */
+   uint32_t all_bits;
+} odp_ipsec_protocols_t;
+
 /**
  * IPSEC capability
  */
@@ -264,6 +286,9 @@ typedef struct odp_ipsec_capability_t {
 */
uint8_t hard_limit_sec;
 
+   /** Supported ipsec Protocols */
+   odp_ipsec_protocols_t protocols;
+
/** Supported cipher algorithms */
odp_crypto_cipher_algos_t ciphers;
 
@@ -554,21 +579,6 @@ typedef enum odp_ipsec_lookup_mode_t {
 } odp_ipsec_lookup_mode_t;
 
 /**
- * Result event pipeline configuration
- */
-typedef enum odp_ipsec_pipeline_t {
-   /** Do not pipeline */
-   ODP_IPSEC_PIPELINE_NONE = 0,
-
-   /** Send IPSEC result events to the classifier.
-*
-*  IPSEC capability 'pipeline_cls' determines if pipelined
-*  classification is supported. */
-   ODP_IPSEC_PIPELINE_CLS
-
-} odp_ipsec_pipeline_t;
-
-/**
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
@@ -632,31 +642,13 @@ typedef struct odp_ipsec_sa_param_t {
 */
uint32_t mtu;
 
-   /** Select pipelined destination for IPSEC result events
-*
-*  Asynchronous and inline modes generate result events. Select where
-*  those events are sent. Inbound SAs may choose to use pipelined
-*  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
-*/
-   odp_ipsec_pipeline_t pipeline;
-
/** Destination queue for IPSEC events
 *
-*  Operations in asynchronous or inline mode enqueue resulting events
+*  Operations in asynchronous mode enqueue resulting events
 *  into this queue.
 */
odp_queue_t dest_queue;
 
-   /** Classifier destination CoS for IPSEC result events
-*
-*  Result events for successfully decapsulated packets are sent to
-*  classification through this CoS. Other result events are sent to
-*  'dest_queue'. This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
-*/
-   odp_cos_t dest_cos;
-
/** User defined SA context pointer
 *
 *  User defined context pointer associated with the SA.
diff --git a/include/odp/api/spec/packet_io.h b/include/odp/api/spec/packet_io.h
index 8802089..0270b56 100644
--- a/include/odp/api/spec/packet_io.h
+++ b/include/odp/api/spec/packet_io.h
@@ -1136,6 +1136,22 @@ uint64_t odp_pktin_ts_res(odp_pktio_t pktio);
  * @return Packet input timestamp
  */
 odp_time_t odp_pktin_ts_from_ns(odp_pktio_t pktio, uint64_t ns);
+/**
+ * Returns virtual IPSEC PKTIO for a given PKTIO interface when inbound_ipsec 
is
+ * enabled on PKTIO interface.
+ *
+ * Inline processed IPSEC packets will be delivered to this virtual PKTIO 
interface
+ * User can enable classification/Hashing on this interface in same manner as 
on
+ * normal PKTIO interface. L2 classification rules will not apply to this pktio
+ * as only valid L3 packet are delivered on this interface.
+ *
+ * @param  pktio   Packet IO handle
+ *
+ * @return virtual IPSEC PKT IO handle. returns ODP_PKTIO_INVALID in case IPSec
+ * is not enabled on the PKTIO.
+ */
+odp_pktio_t odp_pktio_ipsec_pktio(odp_pktio_t pktio, uint64_t ns);
+
 
 /**
  * @}
-- 
2.9.3

Re: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

Hi Janne,

Thanks for your inputs. I have updated API descriptions/comments in v3 of the 
patch.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Peltonen, 
Janne (Nokia - FI/Espoo)
Sent: Friday, April 28, 2017 12:59 PM
To: Nikhil Agarwal ; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support 
sNIC implementation.

Hi,

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Nikhil Agarwal
> Sent: Friday, April 28, 2017 9:50 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to 
> support sNIC implementation.
> 
> Signed-off-by: Nikhil Agarwal 
> ---
>  include/odp/api/spec/ipsec.h | 62 
> +---
>  include/odp/api/spec/packet_io.h | 10 +++
>  2 files changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/include/odp/api/spec/ipsec.h 
> b/include/odp/api/spec/ipsec.h index e83494d..a2624ff 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -59,8 +59,10 @@ typedef enum odp_ipsec_op_mode_t {
>   /** Inline IPSEC operation
> *
> * Packet input/output is connected directly to IPSEC inbound/outbound
> -   * processing. Application uses asynchronous or inline IPSEC
> -   * operations.
> +   * processing. Application may use asynchronous IPSEC operations.
> +   * Packet post IPSEC operations are delivered to PKTIO queues. Further
> +   * classification/Hashing(inbound) will be applicaed to packet post 
> IPSEC as
> +   * defined in PKTIO configuration.
> */
>   ODP_IPSEC_OP_MODE_INLINE,

The added comment is not valid for asynchronously processed packets which are 
also allowed in the inline operating mode. So maybe the inline-specific comment 
should be reformulated or located elsewhere.

> 
> @@ -226,6 +228,24 @@ typedef struct odp_ipsec_outbound_config_t {
> 
>  } odp_ipsec_outbound_config_t;
> 
> +typedef union odp_ipsec_protocols_t {
> + /** Cipher algorithms */
> + struct {
> + /** ODP_IPSEC_ESP */
> + uint32_t esp: 1;
> +
> + /** ODP_IPSEC_AH */
> + uint32_t ah : 1;
> +
> + } bit;
> +
> + /** All bits of the bit field structure
> +  *
> +  * This field can be used to set/clear all flags, or bitwise
> +  * operations over the entire structure. */
> + uint32_t all_bits;
> +} odp_ipsec_protocols_t;
> +
>  /**
>   * IPSEC capability
>   */
> @@ -264,6 +284,9 @@ typedef struct odp_ipsec_capability_t {
>*/
>   uint8_t hard_limit_sec;
> 
> + /** Supported ipsec Protocols */
> + odp_ipsec_protocols_t protocols;
> +
>   /** Supported cipher algorithms */
>   odp_crypto_cipher_algos_t ciphers;
> 
> @@ -554,21 +577,6 @@ typedef enum odp_ipsec_lookup_mode_t {  } 
> odp_ipsec_lookup_mode_t;
> 
>  /**
> - * Result event pipeline configuration
> - */
> -typedef enum odp_ipsec_pipeline_t {
> - /** Do not pipeline */
> - ODP_IPSEC_PIPELINE_NONE = 0,
> -
> - /** Send IPSEC result events to the classifier.
> -  *
> -  *  IPSEC capability 'pipeline_cls' determines if pipelined
> -  *  classification is supported. */
> - ODP_IPSEC_PIPELINE_CLS
> -
> -} odp_ipsec_pipeline_t;
> -
> -/**
>   * IPSEC Security Association (SA) parameters
>   */
>  typedef struct odp_ipsec_sa_param_t { @@ -632,31 +640,13 @@ typedef 
> struct odp_ipsec_sa_param_t {
>*/
>   uint32_t mtu;
> 
> - /** Select pipelined destination for IPSEC result events
> -  *
> -  *  Asynchronous and inline modes generate result events. Select where
> -  *  those events are sent. Inbound SAs may choose to use pipelined
> -  *  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
> -  */
> - odp_ipsec_pipeline_t pipeline;
> -

So for asynchronously processed packets this proposal removes the possibility 
of ODP distributing the packets decapsulated from one fat tunnel to multiple 
queues for better parallelism.

>   /** Destination queue for IPSEC events
>*
> -  *  Operations in asynchronous or inline mode enqueue resulting events
> +  *  Operations in asynchronous mode enqueue resulting events
>*  into this queue.
>*/
>   odp_queue_t dest_queue;

So where do the inline processed packets end up? After this patch the API would 
not say it.

> 
> - /** Classifier destination CoS for IPSEC result events
> -  *
> -  *  Result event

[lng-odp] [API_NEXT v2] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/ipsec.h | 62 +---
 include/odp/api/spec/packet_io.h | 10 +++
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index e83494d..a2624ff 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -59,8 +59,10 @@ typedef enum odp_ipsec_op_mode_t {
/** Inline IPSEC operation
  *
  * Packet input/output is connected directly to IPSEC inbound/outbound
- * processing. Application uses asynchronous or inline IPSEC
- * operations.
+ * processing. Application may use asynchronous IPSEC operations.
+ * Packet post IPSEC operations are delivered to PKTIO queues. Further
+ * classification/Hashing(inbound) will be applicaed to packet post 
IPSEC as
+ * defined in PKTIO configuration.
  */
ODP_IPSEC_OP_MODE_INLINE,
 
@@ -226,6 +228,24 @@ typedef struct odp_ipsec_outbound_config_t {
 
 } odp_ipsec_outbound_config_t;
 
+typedef union odp_ipsec_protocols_t {
+   /** Cipher algorithms */
+   struct {
+   /** ODP_IPSEC_ESP */
+   uint32_t esp: 1;
+
+   /** ODP_IPSEC_AH */
+   uint32_t ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+*
+* This field can be used to set/clear all flags, or bitwise
+* operations over the entire structure. */
+   uint32_t all_bits;
+} odp_ipsec_protocols_t;
+
 /**
  * IPSEC capability
  */
@@ -264,6 +284,9 @@ typedef struct odp_ipsec_capability_t {
 */
uint8_t hard_limit_sec;
 
+   /** Supported ipsec Protocols */
+   odp_ipsec_protocols_t protocols;
+
/** Supported cipher algorithms */
odp_crypto_cipher_algos_t ciphers;
 
@@ -554,21 +577,6 @@ typedef enum odp_ipsec_lookup_mode_t {
 } odp_ipsec_lookup_mode_t;
 
 /**
- * Result event pipeline configuration
- */
-typedef enum odp_ipsec_pipeline_t {
-   /** Do not pipeline */
-   ODP_IPSEC_PIPELINE_NONE = 0,
-
-   /** Send IPSEC result events to the classifier.
-*
-*  IPSEC capability 'pipeline_cls' determines if pipelined
-*  classification is supported. */
-   ODP_IPSEC_PIPELINE_CLS
-
-} odp_ipsec_pipeline_t;
-
-/**
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
@@ -632,31 +640,13 @@ typedef struct odp_ipsec_sa_param_t {
 */
uint32_t mtu;
 
-   /** Select pipelined destination for IPSEC result events
-*
-*  Asynchronous and inline modes generate result events. Select where
-*  those events are sent. Inbound SAs may choose to use pipelined
-*  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
-*/
-   odp_ipsec_pipeline_t pipeline;
-
/** Destination queue for IPSEC events
 *
-*  Operations in asynchronous or inline mode enqueue resulting events
+*  Operations in asynchronous mode enqueue resulting events
 *  into this queue.
 */
odp_queue_t dest_queue;
 
-   /** Classifier destination CoS for IPSEC result events
-*
-*  Result events for successfully decapsulated packets are sent to
-*  classification through this CoS. Other result events are sent to
-*  'dest_queue'. This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
-*/
-   odp_cos_t dest_cos;
-
/** User defined SA context pointer
 *
 *  User defined context pointer associated with the SA.
diff --git a/include/odp/api/spec/packet_io.h b/include/odp/api/spec/packet_io.h
index 8802089..0744b1a 100644
--- a/include/odp/api/spec/packet_io.h
+++ b/include/odp/api/spec/packet_io.h
@@ -1136,6 +1136,16 @@ uint64_t odp_pktin_ts_res(odp_pktio_t pktio);
  * @return Packet input timestamp
  */
 odp_time_t odp_pktin_ts_from_ns(odp_pktio_t pktio, uint64_t ns);
+/**
+ * Returns virtual IPSEC PKTIO for a given PKTIO interface.
+ *
+ * @param  pktio   Packet IO handle
+ *
+ * @return virtual IPSEC PKT IO handle. returns ODP_PKTIO_INVALID in case IPSec
+ * is not enabled on the PKTIO.
+ */
+odp_pktio_t odp_pktio_ipsec_pktio(odp_pktio_t pktio, uint64_t ns);
+
 
 /**
  * @}
-- 
2.9.3

Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

CoS will be applicable in case of inline  mode and packets will follow default 
pktio CoS.

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bogdan 
Pricope
Sent: Friday, April 07, 2017 5:10 PM
To: Verma, Shally 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support 
sNIC implementation.

Hi Nikhil,

Let me see if I understand the limitations:

Inbound IPsec processing - pkt/status destination may be:
  For lookaside async mode
   - SA queue: OK for pkts, OK for status
   - pktio queue: not applicable
   - COS: OK (for pkts)
  For inline mode: -
   - SA queue: NOK for pkts, OK for status
   - pktio queue: OK (for pkts)
   - COS: NOK (for pkts)

Is this correct?

Maybe we should keep the "pipeline" but add more capability flags:

uint8_t async_pipeline_cls;
uint8_t inline_pipeline_cls;
uint8_t inline_pipeline_sa_queue;

/Bogdan

On 7 April 2017 at 14:15, Verma, Shally  wrote:
>
>
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Nikhil Agarwal
> Sent: 07 April 2017 15:30
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC 
> implementation.
>
> Signed-off-by: Nikhil Agarwal 
> ---
>  include/odp/api/spec/ipsec.h | 62 
> +++-
>  1 file changed, 26 insertions(+), 36 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h 
> b/include/odp/api/spec/ipsec.h index b3dc0ca..d39e65d 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -58,8 +58,10 @@ typedef enum odp_ipsec_op_mode_t {
> /** Inline IPSEC operation
>   *
>   * Packet input/output is connected directly to IPSEC 
> inbound/outbound
> - * processing. Application uses asynchronous or inline IPSEC
> - * operations.
> + * processing. Application may use asynchronous IPSEC operations.
> + * Packet post IPSEC operations are delivered to PKTIO queues. 
> Further
> + * classification/Hashing(inbound) will be applicaed to packet post 
> IPSEC as
> + * defined in PKTIO configuration.
>   */
> ODP_IPSEC_OP_MODE_INLINE,
>
> @@ -225,6 +227,24 @@ typedef struct odp_ipsec_outbound_config_t {
>
>  } odp_ipsec_outbound_config_t;
>
> +typedef union odp_ipsec_protocols_t {
> +   /** Cipher algorithms */
> +   struct {
> +   /** ODP_IPSEC_ESP */
> +   uint32_t esp: 1;
> +
> +   /** ODP_IPSEC_AH */
> +   uint32_t ah : 1;
> +
> +   } bit;
> +
> +   /** All bits of the bit field structure
> +*
> +* This field can be used to set/clear all flags, or bitwise
> +* operations over the entire structure. */
> +   uint32_t all_bits;
> +} odp_ipsec_protocols_t;
> +
>  /**
>   * IPSEC capability
>   */
> @@ -279,6 +299,9 @@ typedef struct odp_ipsec_capability_t {
>  */
> uint8_t hard_limit_sec;
>
> +   /** Supported ipsec Protocols */
> +   odp_ipsec_protocols_t protocols;
> +
> /** Supported cipher algorithms */
> odp_crypto_cipher_algos_t ciphers;
>
> @@ -568,21 +591,6 @@ typedef enum odp_ipsec_lookup_mode_t {  } 
> odp_ipsec_lookup_mode_t;
>
>  /**
> - * Result event pipeline configuration
> - */
> -typedef enum odp_ipsec_pipeline_t {
> -   /** Do not pipeline */
> -   ODP_IPSEC_PIPELINE_NONE = 0,
> -
> -   /** Send IPSEC result events to the classifier.
> -*
> -*  IPSEC capability 'pipeline_cls' determines if pipelined
> -*  classification is supported. */
> -   ODP_IPSEC_PIPELINE_CLS
> -
> -} odp_ipsec_pipeline_t;
> -
> -/**
>   * IPSEC Security Association (SA) parameters
>   */
>  typedef struct odp_ipsec_sa_param_t { @@ -646,31 +654,13 @@ typedef 
> struct odp_ipsec_sa_param_t {
>  */
> uint32_t mtu;
>
> -   /** Select pipelined destination for IPSEC result events
> -*
> -*  Asynchronous and inline modes generate result events. Select where
> -*  those events are sent. Inbound SAs may choose to use pipelined
> -*  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
> -*/
> -   odp_ipsec_pipeline_t pipeline;
> -
> /** Destination queue for IPSEC events
>  *
> -*  Operations in asynchronous or inline mode enqueue resulting events
> +*  Operations in asynchronous mode enqueue resulting events
>  *  into this queue.
>  */
> odp_queue_t dest_queue;
&g

Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Verma, 
Shally
Sent: Friday, April 07, 2017 4:45 PM
To: Nikhil Agarwal ; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support 
sNIC implementation.



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil 
Agarwal
Sent: 07 April 2017 15:30
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC 
implementation.

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/ipsec.h | 62 +++-
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
b3dc0ca..d39e65d 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -58,8 +58,10 @@ typedef enum odp_ipsec_op_mode_t {
/** Inline IPSEC operation
  *
  * Packet input/output is connected directly to IPSEC inbound/outbound
- * processing. Application uses asynchronous or inline IPSEC
- * operations.
+ * processing. Application may use asynchronous IPSEC operations.
+ * Packet post IPSEC operations are delivered to PKTIO queues. Further
+ * classification/Hashing(inbound) will be applicaed to packet post 
IPSEC as
+ * defined in PKTIO configuration.
  */
ODP_IPSEC_OP_MODE_INLINE,
 
@@ -225,6 +227,24 @@ typedef struct odp_ipsec_outbound_config_t {
 
 } odp_ipsec_outbound_config_t;
 
+typedef union odp_ipsec_protocols_t {
+   /** Cipher algorithms */
+   struct {
+   /** ODP_IPSEC_ESP */
+   uint32_t esp: 1;
+
+   /** ODP_IPSEC_AH */
+   uint32_t ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+*
+* This field can be used to set/clear all flags, or bitwise
+* operations over the entire structure. */
+   uint32_t all_bits;
+} odp_ipsec_protocols_t;
+
 /**
  * IPSEC capability
  */
@@ -279,6 +299,9 @@ typedef struct odp_ipsec_capability_t {
 */
uint8_t hard_limit_sec;
 
+   /** Supported ipsec Protocols */
+   odp_ipsec_protocols_t protocols;
+
/** Supported cipher algorithms */
odp_crypto_cipher_algos_t ciphers;
 
@@ -568,21 +591,6 @@ typedef enum odp_ipsec_lookup_mode_t {  } 
odp_ipsec_lookup_mode_t;
 
 /**
- * Result event pipeline configuration
- */
-typedef enum odp_ipsec_pipeline_t {
-   /** Do not pipeline */
-   ODP_IPSEC_PIPELINE_NONE = 0,
-
-   /** Send IPSEC result events to the classifier.
-*
-*  IPSEC capability 'pipeline_cls' determines if pipelined
-*  classification is supported. */
-   ODP_IPSEC_PIPELINE_CLS
-
-} odp_ipsec_pipeline_t;
-
-/**
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
@@ -646,31 +654,13 @@ typedef struct odp_ipsec_sa_param_t {
 */
uint32_t mtu;
 
-   /** Select pipelined destination for IPSEC result events
-*
-*  Asynchronous and inline modes generate result events. Select where
-*  those events are sent. Inbound SAs may choose to use pipelined
-*  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
-*/
-   odp_ipsec_pipeline_t pipeline;
-
/** Destination queue for IPSEC events
 *
-*  Operations in asynchronous or inline mode enqueue resulting events
+*  Operations in asynchronous mode enqueue resulting events
 *  into this queue.
 */
odp_queue_t dest_queue;
 Shally - enque in order-of-completion or in-order-submission? What does this 
mean in-context of ipsec?
In general, there is bit of confusion when we are using terms async in ODP 
context here. 
It imply that queue is used to output events. an async implementation can queue 
events in order of their completion (which may be different from order of their 
submission). 
If we are queuing events in-order-of submission, then it is actually a 
"Synchronous queued operation" (as we block outputs until previous ones are 
complete).
Can we make it bit more explicit.

It is order of submission. I  think it is mentioned in some API documentation, 
will update it here as well.
Thanks
Shally

-   /** Classifier destination CoS for IPSEC result events
-*
-*  Result events for successfully decapsulated packets are sent to
-*  classification through this CoS. Other result events are sent to
-*  'dest_queue'. This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
-*/
-   odp_cos_t dest_cos;
-
/** User defined SA context pointer
 *
 * 

[lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/ipsec.h | 62 +++-
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
index b3dc0ca..d39e65d 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -58,8 +58,10 @@ typedef enum odp_ipsec_op_mode_t {
/** Inline IPSEC operation
  *
  * Packet input/output is connected directly to IPSEC inbound/outbound
- * processing. Application uses asynchronous or inline IPSEC
- * operations.
+ * processing. Application may use asynchronous IPSEC operations.
+ * Packet post IPSEC operations are delivered to PKTIO queues. Further
+ * classification/Hashing(inbound) will be applicaed to packet post 
IPSEC as
+ * defined in PKTIO configuration.
  */
ODP_IPSEC_OP_MODE_INLINE,
 
@@ -225,6 +227,24 @@ typedef struct odp_ipsec_outbound_config_t {
 
 } odp_ipsec_outbound_config_t;
 
+typedef union odp_ipsec_protocols_t {
+   /** Cipher algorithms */
+   struct {
+   /** ODP_IPSEC_ESP */
+   uint32_t esp: 1;
+
+   /** ODP_IPSEC_AH */
+   uint32_t ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+*
+* This field can be used to set/clear all flags, or bitwise
+* operations over the entire structure. */
+   uint32_t all_bits;
+} odp_ipsec_protocols_t;
+
 /**
  * IPSEC capability
  */
@@ -279,6 +299,9 @@ typedef struct odp_ipsec_capability_t {
 */
uint8_t hard_limit_sec;
 
+   /** Supported ipsec Protocols */
+   odp_ipsec_protocols_t protocols;
+
/** Supported cipher algorithms */
odp_crypto_cipher_algos_t ciphers;
 
@@ -568,21 +591,6 @@ typedef enum odp_ipsec_lookup_mode_t {
 } odp_ipsec_lookup_mode_t;
 
 /**
- * Result event pipeline configuration
- */
-typedef enum odp_ipsec_pipeline_t {
-   /** Do not pipeline */
-   ODP_IPSEC_PIPELINE_NONE = 0,
-
-   /** Send IPSEC result events to the classifier.
-*
-*  IPSEC capability 'pipeline_cls' determines if pipelined
-*  classification is supported. */
-   ODP_IPSEC_PIPELINE_CLS
-
-} odp_ipsec_pipeline_t;
-
-/**
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
@@ -646,31 +654,13 @@ typedef struct odp_ipsec_sa_param_t {
 */
uint32_t mtu;
 
-   /** Select pipelined destination for IPSEC result events
-*
-*  Asynchronous and inline modes generate result events. Select where
-*  those events are sent. Inbound SAs may choose to use pipelined
-*  classification. The default value is ODP_IPSEC_PIPELINE_NONE.
-*/
-   odp_ipsec_pipeline_t pipeline;
-
/** Destination queue for IPSEC events
 *
-*  Operations in asynchronous or inline mode enqueue resulting events
+*  Operations in asynchronous mode enqueue resulting events
 *  into this queue.
 */
odp_queue_t dest_queue;
 
-   /** Classifier destination CoS for IPSEC result events
-*
-*  Result events for successfully decapsulated packets are sent to
-*  classification through this CoS. Other result events are sent to
-*  'dest_queue'. This field is considered only when 'pipeline' is
-*  ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio
-*  interface default CoS.
-*/
-   odp_cos_t dest_cos;
-
/** User defined SA context pointer
 *
 *  User defined context pointer associated with the SA.
-- 
2.9.3

Re: [lng-odp] [API-NEXT PATCH v3 2/4] api: ipsec: add inline IPSEC support

[Nikhil Agarwal]

-- Since the Inline IPSEC is part of sNIC capability (at least for NXP), we 
cannot deliver packets to user specified queues. It will be delivered on pktio 
queues itself. On pktio then you can define the hashing/classification rules to 
distribute packet to different queues. For classification it will be delivered 
to pktio default CoS only.

-- In case user wants to retain the packet header, we cannot remove them from 
packet and put it somewhere else, hence parsing will be based on retained 
headers.

-- ESP/AH are different protocols, either of them can be optionally supported, 
shall be part of capability.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Friday, March 24, 2017 8:35 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 2/4] api: ipsec: add inline IPSEC support

Added support for inline IPSEC processing on packet input and output. Inline 
mode IPSEC and traffic manager cannot be enabled
(currently) on the same pktio interface.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 355 ---
 include/odp/api/spec/packet_io.h |  32 
 2 files changed, 360 insertions(+), 27 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
d3e51bc..2e7e1e4 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -19,6 +19,8 @@ extern "C" {
 #endif
 
 #include 
+#include 
+#include 
 
 /** @defgroup odp_ipsec ODP IPSEC
  *  Operations of IPSEC API.
@@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
  * Application uses asynchronous IPSEC operations,
  * which return results via events.
  */
-   ODP_IPSEC_OP_MODE_ASYNC
+   ODP_IPSEC_OP_MODE_ASYNC,
+
+   /** Inline IPSEC operation
+ *
+ * Packet input/output is connected directly to IPSEC inbound/outbound
+ * processing. Application uses asynchronous or inline IPSEC
+ * operations.
+ */
+   ODP_IPSEC_OP_MODE_INLINE,
+
+   /** IPSEC is disabled in inbound / outbound direction */
+   ODP_IPSEC_OP_MODE_DISABLED
 
 } odp_ipsec_op_mode_t;
 
 /**
+ * Protocol layers in IPSEC configuration  */ typedef enum 
+odp_ipsec_proto_layer_t {
+   /** No layers */
+   ODP_IPSEC_LAYER_NONE = 0,
+
+   /** Layer L2 protocols (Ethernet, VLAN, etc) */
+   ODP_IPSEC_LAYER_L2,
+
+   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSEC, etc) */
+   ODP_IPSEC_LAYER_L3,
+
+   /** Layer L4 protocols (UDP, TCP, SCTP) */
+   ODP_IPSEC_LAYER_L4,
+
+   /** All layers */
+   ODP_IPSEC_LAYER_ALL
+
+} odp_ipsec_proto_layer_t;
+
+/**
  * Configuration options for IPSEC inbound processing
  */
 typedef struct odp_ipsec_inbound_config_t { @@ -81,9 +115,110 @@ typedef 
struct odp_ipsec_inbound_config_t {
 
} spi_lookup;
 
+   /** Retain outer headers
+*
+*  Select up to which protocol layer (at least) outer headers are
+*  retained in inbound inline processing. Default value is
+*  ODP_IPSEC_LAYER_NONE.
+*
+*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
+*headers to be retained.
+*
+*  ODP_IPSEC_LAYER_L2:   Retain headers up to layer 2.
+*
+*  ODP_IPSEC_LAYER_L3:   Retain headers up to layer 3, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_L4:   Retain headers up to layer 4, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_ALL:  In tunnel mode, all headers before IPSEC are
+*retained. In transport mode, all headers
+*before IP (carrying IPSEC) are retained.
+*
+*/
+   odp_ipsec_proto_layer_t retain_outer;
+
+   /** Parse packet headers after IPSEC transformation
+*
+*  Select header parsing level after inbound processing. Headers of the
+*  resulting packet must be parsed (at least) up to this level. Parsing
+*  starts from IP (layer 3). Each successfully transformed packet has
+*  a valid value for L3 offset regardless of the parse configuration.
+*  Default value is ODP_IPSEC_LAYER_NONE.
+*/
+   odp_ipsec_proto_layer_t parse;
+
+   /** Flags to control IPSEC payload data checks up to the selected parse
+*  level. */
+   union {
+   struct {
+   /** Check IPv4 header checksum in IPSEC payload.
+*  Default value is 0. */
+   uint32_t ipv4_chksum   : 1;
+
+   /** Check UDP checksum in IPSEC payload.
+*  Default value is 0. */
+   uint32_t udp_chksum: 1;
+
+

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Nikhil Agarwal]

Few initial comments:

- For Mixing inline and async processing must maintain same SA context in HW 
and implementation. In that case, we should shift to async SA creation so that 
while creating an SA, HWinterface can return the context to sw and Async 
processing can be done for that context.
- Why we want to add different level of header retention, we can add retain 
header or discard.
- Why parsing is optional and layer wise. Parsing should be same as on the 
pktio interface. Even in the lookaside APIs L3 parsing was mandatory. Otherwise 
application will have to do the parsing on its own. Moreover, application will 
never know L3 protocol if there are no parse results.
- In case outer headers are retained in the packet, hardware will parse packet 
based outer headers not inner. Same goes for classification.
- Checksum configuration (For inbound as well as outbound) can be per flow 
basis, as requirement can be different for different flows.
- Support for ESP/AH and Tunnel/Transport mode should be exposed via capability.
- Inline SA lookup should also support 3 tuple lookups (SIP, DIP, SPI).
- Why there are separate lookup prams in SA, when SA tunnel params already 
include SIP and DIP?
- What about enabling HASH distribution post IPSEC for FAT tunnel use case.
- In per SA params, if dest_mode is ODP_IPSEC_DEST_CLS, why output is to a new 
CoS, why not to default CoS of that pktio. Are we saying that we will have two 
level of classification on that oktio, one before IPsec and one after that?
- Who holds the responsibility of freeing the l2hdr in 
odp_ipsec_inline_op_param_t post transmission? IUs it mandated to be inside the 
packet? The why not just use l2_offset?

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Tuesday, March 21, 2017 7:47 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

Added support for inline IPSEC processing on packet input and output. Inline 
mode IPSEC and traffic manager cannot be enabled
(currently) on the same pktio interface.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 348 ---
 include/odp/api/spec/packet_io.h |  32 
 2 files changed, 355 insertions(+), 25 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
e951e49..23d02cf 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -19,6 +19,8 @@ extern "C" {
 #endif
 
 #include 
+#include 
+#include 
 
 /** @defgroup odp_ipsec ODP IPSEC
  *  Operations of IPSEC API.
@@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
  * Application uses asynchronous IPSEC operations,
  * which return results via events.
  */
-   ODP_IPSEC_OP_MODE_ASYNC
+   ODP_IPSEC_OP_MODE_ASYNC,
+
+   /** Inline IPSEC operation
+ *
+ * Packet input/output is connected directly to IPSEC inbound/outbound
+ * processing. Application uses asynchronous or inline IPSEC
+ * operations.
+ */
+   ODP_IPSEC_OP_MODE_INLINE,
+
+   /** IPSEC is disabled in inbound / outbound direction */
+   ODP_IPSEC_OP_MODE_DISABLED
 
 } odp_ipsec_op_mode_t;
 
 /**
+ * Protocol layers in IPSEC configuration  */ typedef enum 
+odp_ipsec_proto_layer_t {
+   /** No layers */
+   ODP_IPSEC_LAYER_NONE = 0,
+
+   /** Layer L2 protocols (Ethernet, VLAN, etc) */
+   ODP_IPSEC_LAYER_L2,
+
+   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */
+   ODP_IPSEC_LAYER_L3,
+
+   /** Layer L4 protocols (UDP, TCP, SCTP) */
+   ODP_IPSEC_LAYER_L4,
+
+   /** All layers */
+   ODP_IPSEC_LAYER_ALL
+
+} odp_ipsec_proto_layer_t;
+
+/**
  * Configuration options for IPSEC inbound processing
  */
 typedef struct odp_ipsec_inbound_config_t { @@ -77,9 +111,113 @@ typedef 
struct odp_ipsec_inbound_config_t {
uint32_t max;
} spi;
 
+   /** Retain outer headers
+*
+*  Select up to which protocol layer (at least) outer headers are
+*  retained in inbound inline processing. Default value is
+*  ODP_IPSEC_LAYER_NONE.
+*
+*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
+*headers to be retained.
+*
+*  ODP_IPSEC_LAYER_L2:   Retain headers up to layer 2.
+*
+*  ODP_IPSEC_LAYER_L3:   Retain headers up to layer 3, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_L4:   Retain headers up to layer 4, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_ALL:  In tunnel mode, all headers before IPSEC are
+*retained. In transport mode, all headers
+*before IP (ca

Re: [lng-odp] [RFC, API-NEXT v1 1/1] comp:compression interface

[Nikhil Agarwal]

Moreover, if both modes need to be added it is better to follow IPSEC APIs 
approach instead of crypto APIs, where SYNC and ASYNC APIs are different and 
user explicitly control mode of operation based on capabilities.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Tuesday, March 21, 2017 4:18 PM
To: Mahipal Challa 
Cc: prasad.athr...@cavium.com; faisal.mas...@cavium.com; Mahipal Challa 
; mcha...@cavium.com; lng-odp-forward 

Subject: Re: [lng-odp] [RFC, API-NEXT v1 1/1] comp:compression interface

Hi,

This proposal supports both sync and async compression offload in a single API 
following the crypto model, IMO We can separate SYNC and ASYNC compression 
offload as two different APIs and only add ASYNC compression offload in the 
first version and if required we can add SYNC compression mode as a later 
enhancement.

By following this approach we can simplify the module and will be easier to 
adapt.

Regards,
Bala

On 17 March 2017 at 17:50, Mahipal Challa 
wrote:

> From: Shally Verma 
>
> An API set to add compression/decompression support in ODP interface.
>
> Signed-off-by: Shally Verma 
> Signed-off-by: Mahipal Challa 
> ---
>  include/odp/api/spec/comp.h | 668 ++
> ++
>  1 file changed, 668 insertions(+)
>
> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h 
> new file mode 100644 index 000..d8f6c68
> --- /dev/null
> +++ b/include/odp/api/spec/comp.h
> @@ -0,0 +1,668 @@
> +/* Copyright (c) 2017, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier:BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * ODP Compression
> + */
> +
> +#ifndef ODP_API_COMP_H_
> +#define ODP_API_COMP_H_
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** @defgroup odp_compression ODP COMP
> + *  ODP Compression defines interface to compress/decompress and
> authenticate
> + *  data.
> + *
> + *  Compression here implicilty refer to both compression and
> decompression.
> + *  Example, compression algo 'deflate' mean both 'deflate' and 'inflate'.
> + *
> + *  if opcode = ODP_COMP_COMPRESS, then it will Compress,
> + *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress.
> + *
> + *  Current version of Interface allow Compression 
> + ONLY,Authentication
> ONLY or
> + *  both Compression + Auth ONLY sessions.
> + *
> + *  Macros, enums, types and operations to utilise compression.
> + *  @{
> + */
> +
> +/**
> + * @def ODP_COMP_SESSION_INVALID
> + * Invalid session handle
> + */
> +
> +/**
> + * @typedef odp_comp_session_t (platform dependent)
> + * Comp API opaque session handle
> + */
> +
> +/**
> + * @typedef odp_comp_compl_t
> +* Compression API completion event (platform dependent) */
> +
> +/**
> + * Compression API operation mode
> + */
> +typedef enum {
> +   /** Synchronous, return results immediately */
> +   ODP_COMP_SYNC,
> +   /** Asynchronous, return results via event */
> +   ODP_COMP_ASYNC,
> +} odp_comp_op_mode_t;
> +
> +/**
> + * Comp API operation type
> + */
> +typedef enum {
> +   /** Compress and/or Compute ICV  */
> +   ODP_COMP_OP_COMPRESS,
> +   /** Decompress and/or Compute ICV */
> +   ODP_COMP_OP_DECOMPRESS,
> +} odp_comp_op_t;
> +
> +/**
> + * Comp API compression algorithm
> + *
> + *  Enum listing support Compression algo. Currently one
> + *  Compressor corresponds to 1 compliant decompressor.
> + *
> + */
> +typedef enum {
> +   /** No algorithm specified */
> +   ODP_COMP_ALG_NULL,
> +   /** DEFLATE -
> +   *
> +   * implicit Inflate in case of decode operation
> +   *
> +   */
> +   ODP_COMP_ALG_DEFLATE,
> +   /** ZLIB */
> +   ODP_COMP_ALG_ZLIB,
> +   /** LZS*/
> +   ODP_COMP_ALG_LZS,
> +   /** SHA1
> +   *
> +   * When given, imply Authentication ONLY operation
> +   *
> +   */
> +   ODP_COMP_ALG_SHA1,
> +   /** SHA256
> +   *
> +   * When given, imply Authentication ONLY operation
> +   *
> +   */
> +   ODP_COMP_ALG_SHA256,
> +   /** DEFLATE+SHA1  */
> +   ODP_COMP_ALG_DEFLATE_SHA1,
> +   /** DEFLATE+SHA256   */
> +   ODP_COMP_ALG_DEFLATE_SHA256,
> +   /** ZLIB+SHA  */
> +   ODP_COMP_ALG_ZLIB_SHA1,
> +   /** ZLIB+SHA256 */
> +   ODP_COMP_ALG_ZLIB_SHA256,
> +   /** LZS+SHA1   */
> +   ODP_COMP_ALG_LZS_SHA1,
> +   /** LZS+SHA256 */
> +   ODP_COMP_ALG_LZS_SHA256
> +} odp_comp_alg_t;
> +
> +/**
> + * Comp API session creation return code  */ typedef enum {
> +   /** Session created */
> +   ODP_COMP_SES_CREATE_ERR_NONE,
> +   /** Creation failed, no resources */
> +   ODP_COMP_SES_CREATE_ERR_ENOMEM,
> +   /** Creation failed, bad compression params */
> +   ODP_COMP_SES_CREATE_ERR_INV_COMP,
> +   /** Creation failed,requested configuration not supported*/
> +   ODP_COMP_SES_CR

[lng-odp] [PATCHv3] example:ipsec_offload: Adding ipsec_offload example

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 example/Makefile.am  |   1 +
 example/ipsec_offload/.gitignore |   1 +
 example/ipsec_offload/Makefile.am|  19 +
 example/ipsec_offload/odp_ipsec_offload.c| 872 +++
 example/ipsec_offload/odp_ipsec_offload_cache.c  | 148 
 example/ipsec_offload/odp_ipsec_offload_cache.h  |  78 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.c | 223 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.h | 198 +
 example/ipsec_offload/odp_ipsec_offload_misc.h   | 384 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.c  | 361 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.h  | 126 
 example/ipsec_offload/odp_ipsec_offload_sp_db.c  | 166 +
 example/ipsec_offload/odp_ipsec_offload_sp_db.h  |  72 ++
 example/ipsec_offload/run_left   |  14 +
 example/ipsec_offload/run_right  |  14 +
 example/m4/configure.m4  |   1 +
 16 files changed, 2678 insertions(+)
 create mode 100644 example/ipsec_offload/.gitignore
 create mode 100644 example/ipsec_offload/Makefile.am
 create mode 100644 example/ipsec_offload/odp_ipsec_offload.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_misc.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.h
 create mode 100644 example/ipsec_offload/run_left
 create mode 100644 example/ipsec_offload/run_right

diff --git a/example/Makefile.am b/example/Makefile.am
index dfc07b6..24b9e52 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -2,6 +2,7 @@ SUBDIRS = classifier \
  generator \
  hello \
  ipsec \
+ ipsec_offload \
  l2fwd_simple \
  l3fwd \
  packet \
diff --git a/example/ipsec_offload/.gitignore b/example/ipsec_offload/.gitignore
new file mode 100644
index 000..2fc73aa
--- /dev/null
+++ b/example/ipsec_offload/.gitignore
@@ -0,0 +1 @@
+odp_ipsec_offload
diff --git a/example/ipsec_offload/Makefile.am 
b/example/ipsec_offload/Makefile.am
new file mode 100644
index 000..a61b923
--- /dev/null
+++ b/example/ipsec_offload/Makefile.am
@@ -0,0 +1,19 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_ipsec_offload$(EXEEXT)
+odp_ipsec_offload_LDFLAGS = $(AM_LDFLAGS) -static
+odp_ipsec_offload_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_cache.h 
\
+ 
$(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_fwd_db.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_misc.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sa_db.h 
\
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sp_db.h 
\
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_ipsec_offload_SOURCES = odp_ipsec_offload.c \
+odp_ipsec_offload_sa_db.c \
+odp_ipsec_offload_sp_db.c \
+odp_ipsec_offload_fwd_db.c \
+odp_ipsec_offload_cache.c
diff --git a/example/ipsec_offload/odp_ipsec_offload.c 
b/example/ipsec_offload/odp_ipsec_offload.c
new file mode 100644
index 000..ebf70d7
--- /dev/null
+++ b/example/ipsec_offload/odp_ipsec_offload.c
@@ -0,0 +1,872 @@
+/* Copyright (c) 2017, Linaro Limited
+ * Copyright (C) 2017 NXP
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example odp_ipsec_offload.c  ODP basic packet IO cross connect with IPsec
+ * test application
+ */
+
+#define _DEFAULT_SOURCE
+/* enable strtok */
+#define _POSIX_C_SOURCE 200112L
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_WORKERS 32   /**< maximum number of worker threads */
+
+/**
+ * Parsed command line application arguments
+ */
+typedef struct {
+   int cpu_count;
+   int flows;
+   int if_count;   /**< Number of interfaces to be used */
+   char **if_names;/**< Array of pointers to interface names */
+   char *if_str;   /**< Storage for interface names */
+   int queue_type; /**< Queue synchronization type*/

[lng-odp] [PATCHv2] example:ipsec_offload: Adding ipsec_offload example

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 example/Makefile.am  |   1 +
 example/ipsec_offload/.gitignore |   1 +
 example/ipsec_offload/Makefile.am|  19 +
 example/ipsec_offload/odp_ipsec_offload.c| 871 +++
 example/ipsec_offload/odp_ipsec_offload_cache.c  | 148 
 example/ipsec_offload/odp_ipsec_offload_cache.h  |  78 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.c | 223 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.h | 198 ++
 example/ipsec_offload/odp_ipsec_offload_misc.h   | 384 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.c  | 361 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.h  | 126 
 example/ipsec_offload/odp_ipsec_offload_sp_db.c  | 166 +
 example/ipsec_offload/odp_ipsec_offload_sp_db.h  |  72 ++
 example/ipsec_offload/run_left   |  14 +
 example/ipsec_offload/run_right  |  14 +
 example/m4/configure.m4  |   1 +
 16 files changed, 2677 insertions(+)
 create mode 100644 example/ipsec_offload/.gitignore
 create mode 100644 example/ipsec_offload/Makefile.am
 create mode 100644 example/ipsec_offload/odp_ipsec_offload.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_misc.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.h
 create mode 100644 example/ipsec_offload/run_left
 create mode 100644 example/ipsec_offload/run_right

diff --git a/example/Makefile.am b/example/Makefile.am
index dfc07b6..24b9e52 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -2,6 +2,7 @@ SUBDIRS = classifier \
  generator \
  hello \
  ipsec \
+ ipsec_offload \
  l2fwd_simple \
  l3fwd \
  packet \
diff --git a/example/ipsec_offload/.gitignore b/example/ipsec_offload/.gitignore
new file mode 100644
index 000..2fc73aa
--- /dev/null
+++ b/example/ipsec_offload/.gitignore
@@ -0,0 +1 @@
+odp_ipsec_offload
diff --git a/example/ipsec_offload/Makefile.am 
b/example/ipsec_offload/Makefile.am
new file mode 100644
index 000..a61b923
--- /dev/null
+++ b/example/ipsec_offload/Makefile.am
@@ -0,0 +1,19 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_ipsec_offload$(EXEEXT)
+odp_ipsec_offload_LDFLAGS = $(AM_LDFLAGS) -static
+odp_ipsec_offload_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_cache.h 
\
+ 
$(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_fwd_db.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_misc.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sa_db.h 
\
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sp_db.h 
\
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_ipsec_offload_SOURCES = odp_ipsec_offload.c \
+odp_ipsec_offload_sa_db.c \
+odp_ipsec_offload_sp_db.c \
+odp_ipsec_offload_fwd_db.c \
+odp_ipsec_offload_cache.c
diff --git a/example/ipsec_offload/odp_ipsec_offload.c 
b/example/ipsec_offload/odp_ipsec_offload.c
new file mode 100644
index 000..4a494d0
--- /dev/null
+++ b/example/ipsec_offload/odp_ipsec_offload.c
@@ -0,0 +1,871 @@
+/* Copyright (c) 2017, Linaro Limited
+ * Copyright (C) 2017 NXP
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example odp_ipsec_offload.c  ODP basic packet IO cross connect with IPsec
+ * test application
+ */
+
+#define _DEFAULT_SOURCE
+/* enable strtok */
+#define _POSIX_C_SOURCE 200112L
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_WORKERS 32   /**< maximum number of worker threads */
+
+/**
+ * Parsed command line application arguments
+ */
+typedef struct {
+   int cpu_count;
+   int flows;
+   int if_count;   /**< Number of interfaces to be used */
+   char **if_names;/**< Array of pointers to interface names */
+   char *if_str;   /**< Storage for interface names */
+   int queue_type; /**< Queue synchronization type*/

[lng-odp] [PATCH] example:ipsec_offload: Adding ipsec_offload example

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 example/Makefile.am  |   1 +
 example/ipsec_offload/.gitignore |   1 +
 example/ipsec_offload/Makefile.am|  18 +
 example/ipsec_offload/odp_ipsec_offload.c| 871 +++
 example/ipsec_offload/odp_ipsec_offload_cache.c  | 148 
 example/ipsec_offload/odp_ipsec_offload_cache.h  |  78 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.c | 223 ++
 example/ipsec_offload/odp_ipsec_offload_fwd_db.h | 198 ++
 example/ipsec_offload/odp_ipsec_offload_misc.h   | 384 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.c  | 361 ++
 example/ipsec_offload/odp_ipsec_offload_sa_db.h  | 126 
 example/ipsec_offload/odp_ipsec_offload_sp_db.c  | 166 +
 example/ipsec_offload/odp_ipsec_offload_sp_db.h  |  72 ++
 example/ipsec_offload/run_left   |  14 +
 example/ipsec_offload/run_right  |  14 +
 15 files changed, 2675 insertions(+)
 create mode 100644 example/ipsec_offload/.gitignore
 create mode 100644 example/ipsec_offload/Makefile.am
 create mode 100644 example/ipsec_offload/odp_ipsec_offload.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_cache.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_fwd_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_misc.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sa_db.h
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.c
 create mode 100644 example/ipsec_offload/odp_ipsec_offload_sp_db.h
 create mode 100644 example/ipsec_offload/run_left
 create mode 100644 example/ipsec_offload/run_right

diff --git a/example/Makefile.am b/example/Makefile.am
index dfc07b6..24b9e52 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -2,6 +2,7 @@ SUBDIRS = classifier \
  generator \
  hello \
  ipsec \
+ ipsec_offload \
  l2fwd_simple \
  l3fwd \
  packet \
diff --git a/example/ipsec_offload/.gitignore b/example/ipsec_offload/.gitignore
new file mode 100644
index 000..2fc73aa
--- /dev/null
+++ b/example/ipsec_offload/.gitignore
@@ -0,0 +1 @@
+odp_ipsec_offload
diff --git a/example/ipsec_offload/Makefile.am 
b/example/ipsec_offload/Makefile.am
new file mode 100644
index 000..ec66030
--- /dev/null
+++ b/example/ipsec_offload/Makefile.am
@@ -0,0 +1,18 @@
+include $(top_srcdir)/example/Makefile.inc
+
+odp_ipsec_offload_LDFLAGS = $(AM_LDFLAGS) -static
+odp_ipsec_offload_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_cache.h 
\
+ 
$(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_fwd_db.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_misc.h \
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sa_db.h 
\
+ $(top_srcdir)/example/ipsec_offload/odp_ipsec_offload_sp_db.h 
\
+ $(top_srcdir)/example/example_debug.h
+
+dist_odp_ipsec_offload_SOURCES = odp_ipsec_offload.c \
+odp_ipsec_offload_sa_db.c \
+odp_ipsec_offload_sp_db.c \
+odp_ipsec_offload_fwd_db.c \
+odp_ipsec_offload_cache.c
diff --git a/example/ipsec_offload/odp_ipsec_offload.c 
b/example/ipsec_offload/odp_ipsec_offload.c
new file mode 100644
index 000..4a494d0
--- /dev/null
+++ b/example/ipsec_offload/odp_ipsec_offload.c
@@ -0,0 +1,871 @@
+/* Copyright (c) 2017, Linaro Limited
+ * Copyright (C) 2017 NXP
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * @example odp_ipsec_offload.c  ODP basic packet IO cross connect with IPsec
+ * test application
+ */
+
+#define _DEFAULT_SOURCE
+/* enable strtok */
+#define _POSIX_C_SOURCE 200112L
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_WORKERS 32   /**< maximum number of worker threads */
+
+/**
+ * Parsed command line application arguments
+ */
+typedef struct {
+   int cpu_count;
+   int flows;
+   int if_count;   /**< Number of interfaces to be used */
+   char **if_names;/**< Array of pointers to interface names */
+   char *if_str;   /**< Storage for interface names */
+   int queue_type; /**< Queue synchronization type*/
+} appl_args_t;
+/**
+ * Grouping of both parsed CL args and thread specific args - alloc together
+ */

Re: [lng-odp] FW: odp-crypto operations for segmented packets.

[Nikhil Agarwal]

On 18 February 2017 at 04:02, Bill Fischofer 
wrote:

> On Fri, Feb 17, 2017 at 3:14 PM, Verma, Shally 
> wrote:
> > Hi
> >
> > I was looking at linux-generic/odp_crypto.c implementation and it looks
> like that each odp_crypto_operation() call assumes that each Packet is
> contained within 1-segment or user passing either packet or segment len,
> whichever is smaller.
> >
> > As I understand ODP Packet structure, it is scattered across segments
> and that segments may not be contiguous. So  let's say if App sets Segment
> Length as 32k and pass packet of length 64k with cipher_range.len = 64K,
> then current linux-generic/ODP_Crypto implementation may not work correct.
>
> It appears you are correct. +cc Nikhil to confirm. Sounds like this is
> a bug. Crypto operations should work on multi-segment packets.
> However, if we want to restrict crypto ops to single-segment packets
> then these routines need to fail rather than risk segfaults when
> passed multi-segment packets.
>
> Yes this seems to be a BUG wih Linux-generic implementation.

> >
> > Could anyone please confirm it? Or Am I missing any baseline assumption
> here on how packets are supposed to pass for linux-generic/crypto ops?
> >
> > Thanks
> > Shally
>

Re: [lng-odp] [PATCH] [RFC] API:update odp_schedle_multi to return events from multiple queues.

[Nikhil Agarwal]

On 7 February 2017 at 18:58, Bill Fischofer 
wrote:

> On Tue, Feb 7, 2017 at 7:22 AM, Nikhil Agarwal
>  wrote:
> > On 3 February 2017 at 19:20, Ola Liljedahl 
> wrote:
> >
> >> Do we have any performance comparison between using this new API
> >> compared to using the existing API and the SW behind
> >> odp_schedule_multi() sorts the events (if necessary) and only returns
> >> events for one queue at a time (keeping the others as prescheduled
> >> events)?
> >>
> > Keeping highest priority packets on-hold while other cores are free to
> > process them may add significant latency as you are not sure when the
> > particular thread will call odp_schedule again.
>
> How would these other cores be prevented from processing them? If they
> call odp_schedule() or odp_schedule_multi() they are going to be given
> packet(s) to process.
>

Since different threads may be configured for different scheduler groups
you cannot give packet buffered for one thread to other.(Unless some
scheduling logic is also introduced in software). will have to buffer
different pre-scheduled events for different threads.

>
> >
> >>
> >> If we don't know that this new API actually improves performance
> >> (significantly) compared to using the existing API enhanced with some
> >> under-the-hood fixup, I don't think we have a good case for changing
> >> the API.
> >>
> > Comparing one packet per call vs multiple(8 packets) gives a boost of
> > around ~30% in performance.
>
> We already have odp_schedule_multi() that can process multiple packets
> in one call. The issue here is how often these packets are coming from
> multiple queues and other cores aren't available to process them?
>
If we don't use classifier generally hashing is used to distribute packets
among multiple queues of a pktio. So packet will arrive from multiple
queues most often.

>
> >
> >
> >>
> >>
> >> On 3 February 2017 at 12:50, Nikhil Agarwal 
> >> wrote:
> >> > Signed-off-by: Nikhil Agarwal 
> >> > ---
> >> >  include/odp/api/spec/schedule.h | 36 ++
> >> +-
> >> >  1 file changed, 31 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/include/odp/api/spec/schedule.h b/include/odp/api/spec/
> >> schedule.h
> >> > index f8fed17..6e8d759 100644
> >> > --- a/include/odp/api/spec/schedule.h
> >> > +++ b/include/odp/api/spec/schedule.h
> >> > @@ -118,8 +118,8 @@ odp_event_t odp_schedule(odp_queue_t *from,
> uint64_t
> >> wait);
> >> >   * originate from the same source queue and share the same scheduler
> >> >   * synchronization context.
> >> >   *
> >> > - * @param fromOutput parameter for the source queue (where the
> >> event was
> >> > - *dequeued from). Ignored if NULL.
> >> > + * @param fromOutput parameter for the source queues array (where
> >> the event
> >> > + *   were dequeued from). Ignored if NULL.
> >> >   * @param waitMinimum time to wait for an event. Waits
> infinitely,
> >> if set to
> >> >   *ODP_SCHED_WAIT. Does not wait, if set to
> >> ODP_SCHED_NO_WAIT.
> >> >   *Use odp_schedule_wait_time() to convert time to
> other
> >> wait
> >> > @@ -129,7 +129,7 @@ odp_event_t odp_schedule(odp_queue_t *from,
> uint64_t
> >> wait);
> >> >   *
> >> >   * @return Number of events outputted (0 ... num)
> >> >   */
> >> > -int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t
> >> events[],
> >> > +int odp_schedule_multi(odp_queue_t from[], uint64_t wait, odp_event_t
> >> events[],
> >> >int num);
> >> >
> >> >  /**
> >> > @@ -170,6 +170,17 @@ void odp_schedule_resume(void);
> >> >  void odp_schedule_release_atomic(void);
> >> >
> >> >  /**
> >> > + * Release the atomic context associated with the events specified by
> >> evnets[].
> >> > + *
> >> > + * This call is similar to odp_schedule_release_atomic call which
> >> releases context
> >> > + * associated with the events defined by events.
> >> > + * @param events  Input event array for which atomic context is to be
> >> released
> >> > + * @param num Number of events
> >> > + *
&g

Re: [lng-odp] [PATCH] [RFC] API:update odp_schedle_multi to return events from multiple queues.

[Nikhil Agarwal]

On 3 February 2017 at 19:20, Ola Liljedahl  wrote:

> Do we have any performance comparison between using this new API
> compared to using the existing API and the SW behind
> odp_schedule_multi() sorts the events (if necessary) and only returns
> events for one queue at a time (keeping the others as prescheduled
> events)?
>
Keeping highest priority packets on-hold while other cores are free to
process them may add significant latency as you are not sure when the
particular thread will call odp_schedule again.

>
> If we don't know that this new API actually improves performance
> (significantly) compared to using the existing API enhanced with some
> under-the-hood fixup, I don't think we have a good case for changing
> the API.
>
Comparing one packet per call vs multiple(8 packets) gives a boost of
around ~30% in performance.


>
>
> On 3 February 2017 at 12:50, Nikhil Agarwal 
> wrote:
> > Signed-off-by: Nikhil Agarwal 
> > ---
> >  include/odp/api/spec/schedule.h | 36 ++
> +-
> >  1 file changed, 31 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/odp/api/spec/schedule.h b/include/odp/api/spec/
> schedule.h
> > index f8fed17..6e8d759 100644
> > --- a/include/odp/api/spec/schedule.h
> > +++ b/include/odp/api/spec/schedule.h
> > @@ -118,8 +118,8 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t
> wait);
> >   * originate from the same source queue and share the same scheduler
> >   * synchronization context.
> >   *
> > - * @param fromOutput parameter for the source queue (where the
> event was
> > - *dequeued from). Ignored if NULL.
> > + * @param fromOutput parameter for the source queues array (where
> the event
> > + *   were dequeued from). Ignored if NULL.
> >   * @param waitMinimum time to wait for an event. Waits infinitely,
> if set to
> >   *ODP_SCHED_WAIT. Does not wait, if set to
> ODP_SCHED_NO_WAIT.
> >   *Use odp_schedule_wait_time() to convert time to other
> wait
> > @@ -129,7 +129,7 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t
> wait);
> >   *
> >   * @return Number of events outputted (0 ... num)
> >   */
> > -int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t
> events[],
> > +int odp_schedule_multi(odp_queue_t from[], uint64_t wait, odp_event_t
> events[],
> >int num);
> >
> >  /**
> > @@ -170,6 +170,17 @@ void odp_schedule_resume(void);
> >  void odp_schedule_release_atomic(void);
> >
> >  /**
> > + * Release the atomic context associated with the events specified by
> evnets[].
> > + *
> > + * This call is similar to odp_schedule_release_atomic call which
> releases context
> > + * associated with the events defined by events.
> > + * @param events  Input event array for which atomic context is to be
> released
> > + * @param num Number of events
> > + *
> > + */
> > +void odp_schedule_release_atomic_contexts(odp_event_t events[], num);
> > +
> > +/**
> >   * Release the current ordered context
> >   *
> >   * This call is valid only for source queues with ordered
> synchronization. It
> > @@ -187,6 +198,17 @@ void odp_schedule_release_atomic(void);
> >  void odp_schedule_release_ordered(void);
> >
> >  /**
> > + * Release the ordered context associated with the events specified by
> evnets[].
> > + *
> > + * This call is similar to odp_schedule_release_ordered call which
> releases context
> > + * associated with the events defined by events.
> > + * @param events  Input event array for which ordered context is to be
> released
> > + * @param num Number of events
> > + *
> > + */
> > +void odp_schedule_release_ordered_contexts(odp_event_t events[], num);
> > +
> > +/**
> >   * Prefetch events for next schedule call
> >   *
> >   * Hint the scheduler that application is about to finish processing
> the current
> > @@ -348,11 +370,13 @@ int odp_schedule_group_info(odp_schedule_group_t
> group,
> >   * allowing order to maintained on a more granular basis. If an ordered
> lock
> >   * is used multiple times in the same ordered context results are
> undefined.
> >   *
> > + * @param source_queue Queue handle from which event is recieved and
> lock to be
> > + *aquired.
> >   * @param lock_index Index of the ordered lock in the current context
> to be
> >   *   acquired. Must be in the range
&

[lng-odp] [PATCH] [RFC] API:update odp_schedle_multi to return events from multiple queues.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/schedule.h | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/include/odp/api/spec/schedule.h b/include/odp/api/spec/schedule.h
index f8fed17..6e8d759 100644
--- a/include/odp/api/spec/schedule.h
+++ b/include/odp/api/spec/schedule.h
@@ -118,8 +118,8 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t wait);
  * originate from the same source queue and share the same scheduler
  * synchronization context.
  *
- * @param fromOutput parameter for the source queue (where the event was
- *dequeued from). Ignored if NULL.
+ * @param fromOutput parameter for the source queues array (where the event
+ *   were dequeued from). Ignored if NULL.
  * @param waitMinimum time to wait for an event. Waits infinitely, if set 
to
  *ODP_SCHED_WAIT. Does not wait, if set to ODP_SCHED_NO_WAIT.
  *Use odp_schedule_wait_time() to convert time to other wait
@@ -129,7 +129,7 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t wait);
  *
  * @return Number of events outputted (0 ... num)
  */
-int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t events[],
+int odp_schedule_multi(odp_queue_t from[], uint64_t wait, odp_event_t events[],
   int num);
 
 /**
@@ -170,6 +170,17 @@ void odp_schedule_resume(void);
 void odp_schedule_release_atomic(void);
 
 /**
+ * Release the atomic context associated with the events specified by evnets[].
+ *
+ * This call is similar to odp_schedule_release_atomic call which releases 
context
+ * associated with the events defined by events.
+ * @param events  Input event array for which atomic context is to be released
+ * @param num Number of events
+ *
+ */
+void odp_schedule_release_atomic_contexts(odp_event_t events[], num);
+
+/**
  * Release the current ordered context
  *
  * This call is valid only for source queues with ordered synchronization. It
@@ -187,6 +198,17 @@ void odp_schedule_release_atomic(void);
 void odp_schedule_release_ordered(void);
 
 /**
+ * Release the ordered context associated with the events specified by 
evnets[].
+ *
+ * This call is similar to odp_schedule_release_ordered call which releases 
context
+ * associated with the events defined by events.
+ * @param events  Input event array for which ordered context is to be released
+ * @param num Number of events
+ *
+ */
+void odp_schedule_release_ordered_contexts(odp_event_t events[], num);
+
+/**
  * Prefetch events for next schedule call
  *
  * Hint the scheduler that application is about to finish processing the 
current
@@ -348,11 +370,13 @@ int odp_schedule_group_info(odp_schedule_group_t group,
  * allowing order to maintained on a more granular basis. If an ordered lock
  * is used multiple times in the same ordered context results are undefined.
  *
+ * @param source_queue Queue handle from which event is recieved and lock to be
+ *aquired.
  * @param lock_index Index of the ordered lock in the current context to be
  *   acquired. Must be in the range 0..odp_queue_lock_count()
  *   - 1
  */
-void odp_schedule_order_lock(unsigned lock_index);
+void odp_schedule_order_lock(odp_queue_t source_queue, unsigned lock_index);
 
 /**
  * Release ordered context lock
@@ -360,12 +384,14 @@ void odp_schedule_order_lock(unsigned lock_index);
  * This call is valid only when holding an ordered synchronization context.
  * Release a previously locked ordered context lock.
  *
+ * @param source_queue Queue handle from which event is recieved and lock to be
+ *aquired.
  * @param lock_index Index of the ordered lock in the current context to be
  *   released. Results are undefined if the caller does not
  *   hold this lock. Must be in the range
  *   0..odp_queue_lock_count() - 1
  */
-void odp_schedule_order_unlock(unsigned lock_index);
+void odp_schedule_order_unlock(odp_queue_t source_queue, unsigned lock_index);
 
 /**
  * @}
-- 
2.9.3

Re: [lng-odp] schedule_multi returning tasks from multiple queues

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill 
Fischofer
Sent: Tuesday, January 24, 2017 1:15 AM
To: Nikhil Agarwal 
Cc: Kevin Wang ; lng-odp-forward 
; Yi He 
Subject: Re: [lng-odp] schedule_multi returning tasks from multiple queues

Moving this discussion on the ODP mailing list rather than the Internal list as 
that way it will be archived.

The existing ODP controls over scheduling include schedule groups as well as 
queue priorities. The former is a strict requirement (threads can only receive 
events from queues that belong to a matching scheduler group). Queues can 
belong to only a single scheduler group that is set at odp_queue_create() time 
and is fixed for the life of the queue. Threads can belong to multiple 
scheduler groups and may change membership in these groups dynamically via the
odp_schedule_group_join() and odp_schedule_group_leave() APIs.

The latter (queue priority) is advisory. It is expected that in general threads 
will receive events originating on higher-priority queues ahead of those on 
lower-priority queues, but the default scheduler takes other factors into 
consideration to avoid starvation, etc. The "strict priority" (SP) scheduler 
makes priorities strict, so higher priority queues will always be scheduled 
ahead of lower priority queues even at the risk of starvation.

What other scheduling controls are needed / desired?

With regard to receiving events from multiple queues in response to
odp_schedule_multi() there are several points that need clarification:

1. What is the use case for this capability? How many different events/queues 
would one expect to be eligible to be returned in a single call? Presumably 
this is a relatively small number (< 10). How does this compare with having 
multiple threads running in parallel servicing events from individual queues?

This will give benefit of burst processing and improve performance. Generally 
we does burst processing of 8 packets. This will reduce 16 hardware 
interactions (in forwarding scenario, 8 RX and 8 TX) to 2 and gives significant 
boost in performance. Even the DPDK event scheduler gives such flexibility.

2. While semantically this would work for parallel queues, since the scheduler 
provides no synchronization context for events originating from parallel 
queues, is it acceptable / useful to have this restriction in the API?  If not, 
then it's not obvious how multiple atomic or ordered contexts are expected to 
be maintained in any coherent fashion. This would seem to add significant 
complexity to any scheduler design, so we'd need a convincing use case to 
justify this.

IMO,  it should not be restricted to parallel queues only. It should be 
available to all queue types. For release context APIs we should pass event(or 
list of events) as arguments to cater to  context release requirements.  
Even in current APIs if application want release ordered context for a 
particular event (so that all later events can be processed), there is no API 
for that. DPDK takes care of the problem in similar way.

Regards
Nikhil

On Mon, Jan 23, 2017 at 11:05 AM, Nikhil Agarwal  
wrote:
> Adding internal mailing list..
>
> On 23 January 2017 at 22:23, Honnappa Nagarahalli 
>  wrote:
>>
>> Hi Nikhil,
>> I think it was a good discussion today on schedule_multi. I am 
>> also of the opinion that this API is really restrictive in terms of 
>> returning events from multiple queues in a single call.
>>
>> From today's call it looks to me that there is a lack of 
>> understanding of the use case for such as API. I think it will be 
>> useful to get a consensus on the use case as a first step and then 
>> talk about design/API.
>>
>> The current API seems to be designed with the thinking that the cores 
>> will always process only the highest priority packets, which is not 
>> correct. The fact that SoCs exist that support different scheduling 
>> algorithms and they are being used in deployment indicates the 
>> necessity of the new API.
>>
>> Thank you,
>> Honnappa
>
>

Re: [lng-odp] [API-NEXT PATCH 1/4] validation: crypto: fix hw cipher/auth algorithm check

[Nikhil Agarwal]

Can we add sync/Async in capabilities and add similar check before running 
synchronous and asynchronous suites?

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Matias Elo
Sent: Tuesday, January 10, 2017 5:39 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH 1/4] validation: crypto: fix hw cipher/auth 
algorithm check

Some algorithms may be implemented using hardware and some using software.
All supported algorithms should be set in capacity.auths /capacity.ciphers 
independent of implementation types.

Signed-off-by: Matias Elo 
---
 .../validation/api/crypto/odp_crypto_test_inp.c| 69 ++
 1 file changed, 31 insertions(+), 38 deletions(-)

diff --git a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c 
b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
index de9d6e4..db58344 100644
--- a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
+++ b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
@@ -47,7 +47,7 @@ static void alg_test(odp_crypto_op_t op,
 uint32_t digest_len)
 {
odp_crypto_session_t session;
-   odp_crypto_capability_t capability;
+   odp_crypto_capability_t capa;
int rc;
odp_crypto_ses_create_err_t status;
odp_bool_t posted;
@@ -63,50 +63,43 @@ static void alg_test(odp_crypto_op_t op,
int num, i;
int found;
 
-   rc = odp_crypto_capability(&capability);
+   rc = odp_crypto_capability(&capa);
CU_ASSERT(!rc);
 
-   if (capability.hw_ciphers.all_bits) {
-   if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
-   !(capability.hw_ciphers.bit.trides_cbc))
-   rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
-   !(capability.hw_ciphers.bit.aes_cbc))
-   rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
-   !(capability.hw_ciphers.bit.aes_gcm))
-   rc = -1;
-   } else {
-   if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
-   !(capability.ciphers.bit.trides_cbc))
-   rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
-   !(capability.ciphers.bit.aes_cbc))
-   rc = -1;
-   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
-   !(capability.ciphers.bit.aes_gcm))
-   rc = -1;
-   }
+   if (cipher_alg == ODP_CIPHER_ALG_3DES_CBC &&
+   !(capa.ciphers.bit.trides_cbc))
+   rc = -1;
+   if (cipher_alg == ODP_CIPHER_ALG_AES_CBC &&
+   !(capa.ciphers.bit.aes_cbc))
+   rc = -1;
+   if (cipher_alg == ODP_CIPHER_ALG_AES_GCM &&
+   !(capa.ciphers.bit.aes_gcm))
+   rc = -1;
+   if (cipher_alg == ODP_CIPHER_ALG_DES &&
+   !(capa.ciphers.bit.des))
+   rc = -1;
+   if (cipher_alg == ODP_CIPHER_ALG_NULL &&
+   !(capa.ciphers.bit.null))
+   rc = -1;
 
CU_ASSERT(!rc);
+   CU_ASSERT((~capa.ciphers.all_bits & capa.hw_ciphers.all_bits) == 0);
 
-   if (capability.hw_auths.all_bits) {
-   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
-   !(capability.hw_auths.bit.aes_gcm))
-   rc = -1;
-   if (auth_alg == ODP_AUTH_ALG_NULL &&
-   !(capability.hw_auths.bit.null))
-   rc = -1;
-   } else {
-   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
-   !(capability.auths.bit.aes_gcm))
-   rc = -1;
-   if (auth_alg == ODP_AUTH_ALG_NULL &&
-   !(capability.auths.bit.null))
-   rc = -1;
-   }
+   if (auth_alg == ODP_AUTH_ALG_AES_GCM &&
+   !(capa.auths.bit.aes_gcm))
+   rc = -1;
+   if (auth_alg == ODP_AUTH_ALG_MD5_HMAC &&
+   !(capa.auths.bit.md5_hmac))
+   rc = -1;
+   if (auth_alg == ODP_AUTH_ALG_NULL &&
+   !(capa.auths.bit.null))
+   rc = -1;
+   if (auth_alg == ODP_AUTH_ALG_SHA256_HMAC &&
+   !(capa.auths.bit.sha256_hmac))
+   rc = -1;
 
CU_ASSERT(!rc);
+   CU_ASSERT((~capa.auths.all_bits & capa.hw_auths.all_bits) == 0);
 
num = odp_crypto_cipher_capability(cipher_alg, cipher_capa,
   MAX_ALG_CAPA);
--
2.7.4

Re: [lng-odp] [API-NEXT PATCH 4/4] validation: crypto: check auth options support before running tests

[Nikhil Agarwal]

For the series:

Reviewed-by: Nikhil Agarwal 

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Matias Elo
Sent: Tuesday, January 10, 2017 5:39 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH 4/4] validation: crypto: check auth options 
support before running tests

Skip running test if authentication options are not supported.

Signed-off-by: Matias Elo 
---
 .../validation/api/crypto/odp_crypto_test_inp.c| 72 ++
 1 file changed, 72 insertions(+)

diff --git a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c 
b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
index 426f842..43ddb2f 100644
--- a/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
+++ b/test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
@@ -21,6 +21,22 @@ struct suite_context_s {
 
 static struct suite_context_s suite_context;
 
+static const char *auth_alg_name(odp_auth_alg_t auth) {
+   switch (auth) {
+   case ODP_AUTH_ALG_NULL:
+   return "ODP_AUTH_ALG_NULL";
+   case ODP_AUTH_ALG_MD5_HMAC:
+   return "ODP_AUTH_ALG_MD5_HMAC";
+   case ODP_AUTH_ALG_SHA256_HMAC:
+   return "ODP_AUTH_ALG_SHA256_HMAC";
+   case ODP_AUTH_ALG_AES_GCM:
+   return "ODP_AUTH_ALG_AES_GCM";
+   default:
+   return "Unknown";
+   }
+}
+
 static const char *cipher_alg_name(odp_cipher_alg_t cipher)  {
switch (cipher) {
@@ -365,6 +381,41 @@ static int check_cipher_options(odp_cipher_alg_t cipher, 
uint32_t key_len,
return 1;
 }
 
+/**
+ * Check if given authentication options are supported
+ *
+ * @param authAuthentication algorithm
+ * @param key_len Key length
+ * @param digest_len  Digest length
+ *
+ * @retval non-zero if both authentication options are supported
+ * @retval 0 if both options are not supported  */ static int 
+check_auth_options(odp_auth_alg_t auth, uint32_t key_len,
+ uint32_t digest_len)
+{
+   int i;
+   int num;
+   odp_crypto_auth_capability_t capa[MAX_ALG_CAPA];
+
+   num = odp_crypto_auth_capability(auth, capa, MAX_ALG_CAPA);
+   CU_ASSERT_FATAL(num >= 1);
+
+   for (i = 0; i < num; i++) {
+   if (key_len == capa[i].key_len &&
+   digest_len == capa[i].digest_len)
+   break;
+   }
+
+   if (i == num) {
+   printf("\nUnsupported: alg=%s, key_len=%" PRIu32 ", "
+  "digest_len=%" PRIu32 "\n", auth_alg_name(auth), key_len,
+  digest_len);
+   return 0;
+   }
+   return 1;
+}
+
 static int check_alg_3des_cbc(void)
 {
return check_alg_support(ODP_CIPHER_ALG_3DES_CBC, ODP_AUTH_ALG_NULL); 
@@ -546,6 +597,9 @@ void crypto_test_enc_alg_aes128_gcm(void)
if (!check_cipher_options(ODP_CIPHER_ALG_AES_GCM,
  cipher_key.length, iv.length))
continue;
+   if (!check_auth_options(ODP_AUTH_ALG_AES_GCM,
+   auth_key.length, AES128_GCM_CHECK_LEN))
+   continue;
 
alg_test(ODP_CRYPTO_OP_ENCODE,
 ODP_CIPHER_ALG_AES_GCM,
@@ -586,6 +640,9 @@ void crypto_test_enc_alg_aes128_gcm_ovr_iv(void)
if (!check_cipher_options(ODP_CIPHER_ALG_AES_GCM,
  cipher_key.length, iv.length))
continue;
+   if (!check_auth_options(ODP_AUTH_ALG_AES_GCM,
+   auth_key.length, AES128_GCM_CHECK_LEN))
+   continue;
 
alg_test(ODP_CRYPTO_OP_ENCODE,
 ODP_CIPHER_ALG_AES_GCM,
@@ -629,6 +686,9 @@ void crypto_test_dec_alg_aes128_gcm(void)
if (!check_cipher_options(ODP_CIPHER_ALG_AES_GCM,
  cipher_key.length, iv.length))
continue;
+   if (!check_auth_options(ODP_AUTH_ALG_AES_GCM,
+   auth_key.length, AES128_GCM_CHECK_LEN))
+   continue;
 
alg_test(ODP_CRYPTO_OP_DECODE,
 ODP_CIPHER_ALG_AES_GCM,
@@ -670,6 +730,9 @@ void crypto_test_dec_alg_aes128_gcm_ovr_iv(void)
if (!check_cipher_options(ODP_CIPHER_ALG_AES_GCM,
  cipher_key.length, iv.length))
continue;
+   if (!check_auth_options(ODP_AUTH_ALG_AES_GCM,
+   auth_key.length, AES128_GCM_CHECK_LEN))
+   continue;
 
alg_test(ODP_CRYPTO_OP_DECODE,
 ODP_CIPHER_ALG_AES_GCM,
@@ -870,6

Re: [lng-odp] [API-NEXT PATCH] api: ipsec: packet transformation follows RFCs

[Nikhil Agarwal]

Reviewed-by: Nikhil Agarwal 

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Thursday, January 12, 2017 8:16 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH] api: ipsec: packet transformation follows 
RFCs

Add explicit requirement that IPSEC in-/outbound operations transform packet 
headers according to the standards (RFCs).

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
255bb79..66222d8 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -726,9 +726,6 @@ typedef struct odp_ipsec_op_result_t {
 * @see odp_packet_l3_offset(), odp_packet_l4_offset(),
 *  odp_packet_has_ipv4(), odp_packet_has_ipv6(),
 *  odp_packet_has_ipfrag(), odp_packet_has_ipsec()
-*
-* @note The amount and content of packet data before the IP header is
-*   implementation specific.
 */
odp_packet_t *pkt;
 
@@ -770,6 +767,14 @@ typedef struct odp_ipsec_op_result_t {
  * input 'pkt' array to output 'pkt' array. Packet order is not guaranteed
  * between calling threads.
  *
+ * Input packets must not be IP fragments.
+ *
+ * The operation does packet transformation according to IPSEC 
+ standards (see
+ * e.g. RFC 4302 and 4303). Resulting packets are well formed, 
+ reconstructed
+ * original IP packets, with IPSEC headers removed and valid header 
+ field values
+ * restored. The amount and content of packet data before the IP header 
+ is
+ * undefined.
+ *
  * @param input   Operation input parameters
  * @param[out]output  Operation results
  *
@@ -804,6 +809,11 @@ int odp_ipsec_in(const odp_ipsec_op_param_t *input,
  * input 'pkt' array to output 'pkt' array. Packet order is not guaranteed
  * between calling threads.
  *
+ * The operation does packet transformation according to IPSEC 
+ standards (see
+ * e.g. RFC 4302 and 4303). Resulting packets are well formed IP 
+ packets
+ * with IPSEC, etc headers constructed according to the standards. The 
+ amount
+ * and content of packet data before the IP header is undefined.
+ *
  * @param input   Operation input parameters
  * @param[out]output  Operation results
  *
--
2.8.1

[lng-odp] Pktio Queue scheduling configuration

[Nikhil Agarwal]

Hi,

In the current ODP API ODP_PKTIN_QUEUE_CONFIG, to configure input queues to 
Pktio, there is only one set of input queue_param in structure 
odp_pktin_queue_param_t while num_queues can be more than 1. If I want to 
attach different queues of a pktio to different scheduler groups, I did not 
find an option to configure the same. This seems to be a valid configuration.

Am I missing something here?

Regards
Nikhil

Re: [lng-odp] [API-NEXT PATCH v3 00/10] crypto key length capability

[Nikhil Agarwal]

For the series
Reviewed-by: Nikhil Agarwal 


-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Thursday, December 08, 2016 7:35 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 00/10] crypto key length capability

Various cipher and authentication algorithms support multiple key/IV/digest 
lengths. It's not a scalable solution to define these lengths as part of 
algorithm enumeration. This patch set deprecates enumerations (e.g. 
ODP_CIPHER_ALG_AES128_CBC) with length definitions. Those are still supported 
but will be removed in next API version. New enumerations define only algorithm 
names, with the exception of SHA-2 family of algorithms which are commonly 
referred with their digest length (such as SHA-256). The supported 
key/IV/digest lengths are requested with two new functions
odp_crypto_cipher_capa() and odp_crypto_auth_capa(). Usage of HMAC is included 
into authentication algorithm name (it used to be implicit). Only currently 
supported and validation tested algorithms are defined, but later on e.g. MD5 
or SHA-256 (without HMAC) may be defined as well as a set of new algorithms.

Supported key/IV/digest lengths are set to values that pass current validation 
test suite. Some tests may need to be updated with their key/IV/digest length 
usage. For example, AES-GCM authentication test uses key length of zero bytes 
(since it's paired with AES-GCM cipher).


v2:
  * deprecate _params_t and use _param_t instead
  * rename cipher/auth_capa_t to _capability_t
  * rename cipher/auth_capa() to _capability()


Petri Savolainen (10):
  api: crypto: rename _params_t to _param_t
  linux-gen: crypto: rename params to param
  api: crypto: decouple key length from algorithm enumeration
  linux-gen: crypto: add algo capability functions
  linux-gen: crypto: add support to new enumerations
  api: crypto: added session param init
  api: crypto: documentation clean up
  test: crypto: use odp_crypto_session_param_init
  validation: crypto: use algorithm capability
  example: ipsec: use op_param_t instead of op_params_t

 example/ipsec/odp_ipsec.c  |   6 +-
 example/ipsec/odp_ipsec_cache.c|   4 +-
 include/odp/api/spec/crypto.h  | 441 ++-
 .../linux-generic/include/odp_crypto_internal.h|  21 +-
 platform/linux-generic/odp_crypto.c| 489 +
 test/common_plat/performance/odp_crypto.c  |   9 +-
 .../validation/api/crypto/odp_crypto_test_inp.c| 120 +++--
 7 files changed, 744 insertions(+), 346 deletions(-)

--
2.8.1

Re: [lng-odp] [PATCHv2 1/1] validation: classification: fix TCP/UDP checksum update

[Nikhil Agarwal]

Reviewed-by: Nikhil Agarwal 

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
Balasubramanian Manoharan
Sent: Thursday, October 27, 2016 6:31 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCHv2 1/1] validation: classification: fix TCP/UDP 
checksum update

Fixes https://bugs.linaro.org/show_bug.cgi?id=2512

Signed-off-by: Balasubramanian Manoharan 
---
v2: Incorporates review comments
 .../api/classification/odp_classification_common.c | 14 +-
 .../api/classification/odp_classification_test_pmr.c   |  3 +++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git 
a/test/common_plat/validation/api/classification/odp_classification_common.c 
b/test/common_plat/validation/api/classification/odp_classification_common.c
index 7a42ac7..2923a71 100644
--- a/test/common_plat/validation/api/classification/odp_classification_common.c
+++ b/test/common_plat/validation/api/classification/odp_classification_
+++ common.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "test_debug.h"
 
 typedef struct cls_test_packet {
odp_u32be_t magic;
@@ -291,6 +292,8 @@ odp_packet_t create_packet_len(odp_pool_t pool, bool vlan,
parse_ipv4_string(CLS_DEFAULT_SADDR, &addr, &mask);
ip->src_addr = odp_cpu_to_be_32(addr);
ip->ver_ihl = ODPH_IPV4 << 4 | ODPH_IPV4HDR_IHL_MIN;
+   odp_packet_has_ipv4_set(pkt, 1);
+
if (flag_udp)
ip->tot_len = odp_cpu_to_be_16(ODPH_UDPHDR_LEN + payload_len +
   ODPH_IPV4HDR_LEN);
@@ -318,14 +321,23 @@ odp_packet_t create_packet_len(odp_pool_t pool, bool vlan,
udp->dst_port = odp_cpu_to_be_16(CLS_DEFAULT_DPORT);
udp->length = odp_cpu_to_be_16(payload_len + ODPH_UDPHDR_LEN);
udp->chksum = 0;
+   odp_packet_has_udp_set(pkt, 1);
+   if (odph_udp_tcp_chksum(pkt, ODPH_CHKSUM_GENERATE, NULL) != 0) {
+   LOG_ERR("odph_udp_tcp_chksum failed\n");
+   return ODP_PACKET_INVALID;
+   }
} else {
odp_packet_l4_offset_set(pkt, offset);
tcp = (odph_tcphdr_t *)odp_packet_l4_ptr(pkt, NULL);
tcp->src_port = odp_cpu_to_be_16(CLS_DEFAULT_SPORT);
tcp->dst_port = odp_cpu_to_be_16(CLS_DEFAULT_DPORT);
tcp->hl = ODPH_TCPHDR_LEN / 4;
-   /* TODO: checksum field has to be updated */
tcp->cksm = 0;
+   odp_packet_has_tcp_set(pkt, 1);
+   if (odph_udp_tcp_chksum(pkt, ODPH_CHKSUM_GENERATE, NULL) != 0) {
+   LOG_ERR("odph_udp_tcp_chksum failed\n");
+   return ODP_PACKET_INVALID;
+   }
}
 
/* set pkt sequence number */
diff --git 
a/test/common_plat/validation/api/classification/odp_classification_test_pmr.c 
b/test/common_plat/validation/api/classification/odp_classification_test_pmr.c
index c8bbf50..88fbf8f 100644
--- 
a/test/common_plat/validation/api/classification/odp_classification_test_pmr.c
+++ b/test/common_plat/validation/api/classification/odp_classification_
+++ test_pmr.c
@@ -717,6 +717,7 @@ void classification_test_pmr_term_dmac(void)
 
/* Other packets delivered to default queue */
pkt = create_packet(pkt_pool, false, &seq, false);
+   CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
memset(eth->dst.addr, 0, ODPH_ETHADDR_LEN);
CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID); @@ -1102,6 +1103,7 @@ 
static void classification_test_pmr_term_daddr(void)
/* packet with dst ip address matching PMR rule to be
received in the CoS queue*/
pkt = create_packet(pkt_pool, false, &seq, false);
+   CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
odp_pktio_mac_addr(pktio, eth->src.addr, ODPH_ETHADDR_LEN);
odp_pktio_mac_addr(pktio, eth->dst.addr, ODPH_ETHADDR_LEN); @@ -1122,6 
+1124,7 @@ static void classification_test_pmr_term_daddr(void)
 
/* Other packets delivered to default queue */
pkt = create_packet(pkt_pool, false, &seq, false);
+   CU_ASSERT_FATAL(pkt != ODP_PACKET_INVALID);
seqno = cls_pkt_get_seq(pkt);
CU_ASSERT(seqno != TEST_SEQ_INVALID);
eth = (odph_ethhdr_t *)odp_packet_l2_ptr(pkt, NULL);
--
1.9.1

Re: [lng-odp] [API-NEXT PATCH v3] api: ipsec: added IPSEC API

[Nikhil Agarwal]

Reviewed-by: Nikhil Agarwal


On 12/1/2016 2:47 PM, Petri Savolainen wrote:

Added definitions for a look-a-side IPSEC offload API. In addition to
IPSEC packet transformations, it also supports:
* inbound SA look up
* outbound IP fragmentation

Signed-off-by: Petri Savolainen 
---

Changes in v3:
* Reword packet ordering specification

Changes in v2:
* Specify that synchronous calls cannot process all packets
   if output.num_pkt < input.num_pkt
* Specify that resulting event must be freed before calling using packets
* Added soft/hard sec limit capability
* Improved packet order specification

Changes in v1:
* renamed odp_ipsec_proto_t to renamed odp_ipsec_protocol_t
* specify that lifetime sec limit is from the SA creation
* added odp_ipsec_sa_context()
* pool for output packets is the same as packet input pool
* added antireplay check and protocol error codes
* specified which input / output packet offsets and flags are set
* moved sync/async mode selection to global config (odp_ipsec_config())
* added IPSEC capability to aid mode selection
* specify that also packet user area is copied from input to output packet


  include/odp/api/spec/event.h   |   2 +-
  include/odp/api/spec/ipsec.h   | 883 +
  include/odp_api.h  |   1 +
  platform/Makefile.inc  |   1 +
  platform/linux-generic/Makefile.am |   2 +
  platform/linux-generic/include/odp/api/ipsec.h |  36 +
  .../include/odp/api/plat/event_types.h |   1 +
  .../include/odp/api/plat/ipsec_types.h |  39 +
  8 files changed, 964 insertions(+), 1 deletion(-)
  create mode 100644 include/odp/api/spec/ipsec.h
  create mode 100644 platform/linux-generic/include/odp/api/ipsec.h
  create mode 100644 platform/linux-generic/include/odp/api/plat/ipsec_types.h

diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h
index fdfa52d..75c0bbc 100644
--- a/include/odp/api/spec/event.h
+++ b/include/odp/api/spec/event.h
@@ -39,7 +39,7 @@ extern "C" {
   * @typedef odp_event_type_t
   * ODP event types:
   * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
- * ODP_EVENT_CRYPTO_COMPL
+ * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT
   */
  
  /**

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
new file mode 100644
index 000..86f66e6
--- /dev/null
+++ b/include/odp/api/spec/ipsec.h
@@ -0,0 +1,883 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP IPSEC API
+ */
+
+#ifndef ODP_API_IPSEC_H_
+#define ODP_API_IPSEC_H_
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @defgroup odp_ipsec ODP IPSEC
+ *  Operations of IPSEC API.
+ *  @{
+ */
+
+/**
+ * @typedef odp_ipsec_sa_t
+ * IPSEC Security Association (SA)
+ */
+
+ /**
+ * @def ODP_IPSEC_SA_INVALID
+ * Invalid IPSEC SA
+ */
+
+/**
+ * IPSEC operation mode
+ */
+typedef enum odp_ipsec_op_mode_t {
+   /** Synchronous IPSEC operation
+ *
+ * Application uses synchronous IPSEC operations,
+ * which output all results on function return.
+ */
+   ODP_IPSEC_OP_MODE_SYNC = 0,
+
+   /** Asynchronous IPSEC operation
+ *
+ * Application uses asynchronous IPSEC operations,
+ * which return results via events.
+ */
+   ODP_IPSEC_OP_MODE_ASYNC
+
+} odp_ipsec_op_mode_t;
+
+/**
+ * IPSEC capability
+ */
+typedef struct odp_ipsec_capability_t {
+   /** Maximum number of IPSEC SAs */
+   uint32_t max_num_sa;
+
+   /** Synchronous IPSEC operation mode (ODP_IPSEC_OP_MODE_SYNC) support
+*
+*  0: Synchronous mode is not supported
+*  1: Synchronous mode is supported
+*  2: Synchronous mode is supported and preferred
+*/
+   uint8_t op_mode_sync;
+
+   /** Asynchronous IPSEC operation mode (ODP_IPSEC_OP_MODE_ASYNC) support
+*
+*  0: Asynchronous mode is not supported
+*  1: Asynchronous mode is supported
+*  2: Asynchronous mode is supported and preferred
+*/
+   uint8_t op_mode_async;
+
+   /** Soft expiry limit in seconds support
+*
+*  0: Limit is not supported
+*  1: Limit is supported
+*/
+   uint8_t soft_limit_sec;
+
+   /** Hard expiry limit in seconds support
+*
+*  0: Limit is not supported
+*  1: Limit is supported
+*/
+   uint8_t hard_limit_sec;
+
+   /** Supported cipher algorithms */
+   odp_crypto_cipher_algos_t ciphers;
+
+   /** Supported authentication algorithms */
+   odp_crypto_auth_algos_t   auths;
+
+} odp_ipsec_capability_t;
+
+/**
+ * IPSEC configuration options
+ */
+typedef struct odp_ipsec_config_t {
+   /** IPSEC operation mode. Application selects which mode (sync or async)
+

Re: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API

[Nikhil Agarwal]

-Original Message-
From: Savolainen, Petri (Nokia - FI/Espoo) 
[mailto:petri.savolai...@nokia-bell-labs.com] 
Sent: Friday, November 25, 2016 6:40 PM
To: Nikhil Agarwal ; lng-odp@lists.linaro.org
Subject: RE: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API



> -Original Message-
> From: Nikhil Agarwal [mailto:nikhil.agar...@nxp.com]
> Sent: Friday, November 25, 2016 1:22 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)  labs.com>; lng-odp@lists.linaro.org
> Subject: RE: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API
> 
> 
> 
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of 
> Petri Savolainen
> Sent: Wednesday, November 23, 2016 4:10 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API
> 
> Added definitions for a look-a-side IPSEC offload API. In addition to 
> IPSEC packet transformations, it also supports:
> * inbound SA look up
> * outbound IP fragmentation
> 
> Signed-off-by: Petri Savolainen 
> ---
> 
> Changes to draft:
> * renamed odp_ipsec_proto_t to renamed odp_ipsec_protocol_t
> * specify that lifetime sec limit is from the SA creation
> * added odp_ipsec_sa_context()
> * pool for output packets is the same as packet input pool
> * added antireplay check and protocol error codes
> * specified which input / output packet offsets and flags are set
> * moved sync/async mode selection to global config 
> (odp_ipsec_config())
> * added IPSEC capability to aid mode selection
> * specify that also packet user area is copied from input to output 
> packet
> 
> 
>  include/odp/api/spec/event.h   |   2 +-
>  include/odp/api/spec/ipsec.h   | 856
> +
>  include/odp_api.h  |   1 +
>  platform/Makefile.inc  |   1 +
>  platform/linux-generic/Makefile.am |   2 +
>  platform/linux-generic/include/odp/api/ipsec.h |  36 +
>  .../include/odp/api/plat/event_types.h |   1 +
>  .../include/odp/api/plat/ipsec_types.h |  39 +
>  8 files changed, 937 insertions(+), 1 deletion(-)  create mode 100644 
> include/odp/api/spec/ipsec.h  create mode 100644 platform/linux- 
> generic/include/odp/api/ipsec.h  create mode 100644 platform/linux- 
> generic/include/odp/api/plat/ipsec_types.h


> +
> +/**
> + * IPSEC capability
> + */
> +typedef struct odp_ipsec_capability_t {
> Capability should expose fragmentation options and SA lifetime options 
> as well.
> Lookup modes capability may also be exposed.


Which kind of options? What lacking HW features cannot be filled in with 
(reasonable amount of) additional SW ?

For example, if HW cannot do
* pre-fragmentation: implementation can do that first in SW and then send 
fragments to HW
* SPI lookup: implementation can have e.g. a vector instruction optimized data 
base of that
* time limit calculation: implementation may use CPU local time source to check 
against limit on every (few) calls
As for time limit, usually control plane applications(like strongswan) already 
runs a timer for SA life time. It would be overhead to run two timers(one in 
application other in SW implementation) in case hardware does not provide such 
functionalities. There would be no way for application to know whether 
functionality is in HW or SW, so that application may choose the optimal design.
* byte limit: implementation may use atomic instructions, which may be costly 
on high contention SA, but application would do the same

If too many things are optional (in capability), application have to implement 
lot of things in SW - which is often less efficient and degrade the value of 
the common API.


> +/**
> + * Outbound asynchronous IPSEC operation
> + *
> + * This operation does outbound IPSEC processing in asynchronous mode
> + * (ODP_IPSEC_OP_MODE_ASYNC). It processes packets otherwise 
> +identically to
> + * odp_ipsec_out(), but outputs all results through one or multiple
> + * ODP_EVENT_IPSEC_RESULT events.
> + *
> + * Packets are processed in the input order. Packet order is 
> +maintained from
> + * input 'pkt' array to 'pkt' array of each resulting event. 
> +Resulting events
> + * of the same SA should be enqueued in order and all packets within 
> +the same
> + * event must be in order.
> Ordering Cannot be assured for cases where packets from multiple 
> session are input because accelerators have multiple engines running 
> in Parallel. Packets from same session may be serialized but not all.

If I enqueue with single call: pkt1/SA1, pkt1/SA2, pkt2/SA1, pkt2/SA2. Both SAs 
have the same dest queue.

For example, these would be acceptable events: 

Re: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Wednesday, November 23, 2016 4:10 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH] api: ipsec: added IPSEC API

Added definitions for a look-a-side IPSEC offload API. In addition to IPSEC 
packet transformations, it also supports:
* inbound SA look up
* outbound IP fragmentation

Signed-off-by: Petri Savolainen 
---

Changes to draft:
* renamed odp_ipsec_proto_t to renamed odp_ipsec_protocol_t
* specify that lifetime sec limit is from the SA creation
* added odp_ipsec_sa_context()
* pool for output packets is the same as packet input pool
* added antireplay check and protocol error codes
* specified which input / output packet offsets and flags are set
* moved sync/async mode selection to global config (odp_ipsec_config())
* added IPSEC capability to aid mode selection
* specify that also packet user area is copied from input to output packet 


 include/odp/api/spec/event.h   |   2 +-
 include/odp/api/spec/ipsec.h   | 856 +
 include/odp_api.h  |   1 +
 platform/Makefile.inc  |   1 +
 platform/linux-generic/Makefile.am |   2 +
 platform/linux-generic/include/odp/api/ipsec.h |  36 +
 .../include/odp/api/plat/event_types.h |   1 +
 .../include/odp/api/plat/ipsec_types.h |  39 +
 8 files changed, 937 insertions(+), 1 deletion(-)  create mode 100644 
include/odp/api/spec/ipsec.h  create mode 100644 
platform/linux-generic/include/odp/api/ipsec.h
 create mode 100644 platform/linux-generic/include/odp/api/plat/ipsec_types.h

diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h index 
fdfa52d..75c0bbc 100644
--- a/include/odp/api/spec/event.h
+++ b/include/odp/api/spec/event.h
@@ -39,7 +39,7 @@ extern "C" {
  * @typedef odp_event_type_t
  * ODP event types:
  * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
- * ODP_EVENT_CRYPTO_COMPL
+ * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT
  */
 
 /**
diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h new 
file mode 100644 index 000..63603f4
--- /dev/null
+++ b/include/odp/api/spec/ipsec.h
@@ -0,0 +1,856 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP IPSEC API
+ */
+
+#ifndef ODP_API_IPSEC_H_
+#define ODP_API_IPSEC_H_
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @defgroup odp_ipsec ODP IPSEC
+ *  Operations of IPSEC API.
+ *  @{
+ */
+
+/**
+ * @typedef odp_ipsec_sa_t
+ * IPSEC Security Association (SA)
+ */
+
+ /**
+ * @def ODP_IPSEC_SA_INVALID
+ * Invalid IPSEC SA
+ */
+
+/**
+ * IPSEC operation mode
+ */
+typedef enum odp_ipsec_op_mode_t {
+   /** Synchronous IPSEC operation
+ *
+ * Application uses synchronous IPSEC operations,
+ * which output all results on function return.
+ */
+   ODP_IPSEC_OP_MODE_SYNC = 0,
+
+   /** Asynchronous IPSEC operation
+ *
+ * Application uses asynchronous IPSEC operations,
+ * which return results via events.
+ */
+   ODP_IPSEC_OP_MODE_ASYNC
+
+} odp_ipsec_op_mode_t;
+
+/**
+ * IPSEC capability
+ */
+typedef struct odp_ipsec_capability_t {
Capability should expose fragmentation options and SA lifetime options as well.
Lookup modes capability may also be exposed.

+   /** Maximum number of IPSEC SAs */
+   uint32_t max_num_sa;
+
+   /** Synchronous IPSEC operation mode (ODP_IPSEC_OP_MODE_SYNC) support
+*
+*  0: Synchronous mode is not supported
+*  1: Synchronous mode is supported
+*  2: Synchronous mode is supported and preferred
+*/
+   int op_mode_sync;
+
+   /** Asynchronous IPSEC operation mode (ODP_IPSEC_OP_MODE_ASYNC) support
+*
+*  0: Asynchronous mode is not supported
+*  1: Asynchronous mode is supported
+*  2: Asynchronous mode is supported and preferred
+*/
+   int op_mode_async;
+
+   /** Supported cipher algorithms */
+   odp_crypto_cipher_algos_t ciphers;
+
+   /** Supported authentication algorithms */
+   odp_crypto_auth_algos_t   auths;
+
+} odp_ipsec_capability_t;
+
+/**
+ * IPSEC configuration options
+ */
+typedef struct odp_ipsec_config_t {
+   /** IPSEC operation mode. Application selects which mode (sync or async)
+*  will be used for IPSEC operations.
+*
+*  @see odp_ipsec_in(), odp_ipsec_in_enq()
+*/
+   odp_ipsec_op_mode_t op_mode;
+
+} odp_ipsec_config_t;
+
+/**
+ * IPSEC SA direction
+ */
+typedef enum odp_ipsec_dir_t {
+   /** Inbound IPSEC SA */
+   ODP_IPSEC_DIR_INBOUND = 0,
+
+   /** Outbound IPSEC SA */
+   ODP_IPSEC_DIR_OUTBOUND
+
+} odp_ipsec_dir_t;
+
+/**
+ * IPS

Re: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

[Nikhil Agarwal]

Few comments.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Tuesday, November 15, 2016 2:18 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT DRAFT] api: ipsec: added IPSEC API

Added definitions for a look-a-side IPSEC offload API. In addition to IPSEC 
packet transformations, it also supports:
* inbound SA look up
* outbound IP fragmentation

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/event.h   |   2 +-
 include/odp/api/spec/ipsec.h   | 720 +
 include/odp_api.h  |   1 +
 platform/Makefile.inc  |   1 +
 platform/linux-generic/Makefile.am |   2 +
 platform/linux-generic/include/odp/api/ipsec.h |  36 ++
 .../include/odp/api/plat/event_types.h |   1 +
 .../include/odp/api/plat/ipsec_types.h |  39 ++
 8 files changed, 801 insertions(+), 1 deletion(-)  create mode 100644 
include/odp/api/spec/ipsec.h  create mode 100644 
platform/linux-generic/include/odp/api/ipsec.h
 create mode 100644 platform/linux-generic/include/odp/api/plat/ipsec_types.h

diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h index 
fdfa52d..75c0bbc 100644
--- a/include/odp/api/spec/event.h
+++ b/include/odp/api/spec/event.h
@@ -39,7 +39,7 @@ extern "C" {
  * @typedef odp_event_type_t
  * ODP event types:
  * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
- * ODP_EVENT_CRYPTO_COMPL
+ * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT
  */
 
 /**
diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h new 
file mode 100644 index 000..b45bcd4
--- /dev/null
+++ b/include/odp/api/spec/ipsec.h
@@ -0,0 +1,720 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP IPSEC API
+ */
+
+#ifndef ODP_API_IPSEC_H_
+#define ODP_API_IPSEC_H_
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @defgroup odp_ipsec ODP IPSEC
+ *  Operations of IPSEC API.
+ *  @{
+ */
+
+/**
+ * @typedef odp_ipsec_sa_t
+ * IPSEC Security Association (SA)
+ */
+
+ /**
+ * @def ODP_IPSEC_SA_INVALID
+ * Invalid IPSEC SA
+ */
+
+/**
+ * IPSEC SA direction
+ */
+typedef enum odp_ipsec_dir_t {
+   /** Inbound IPSEC SA */
+   ODP_IPSEC_DIR_INBOUND = 0,
+
+   /** Outbound IPSEC SA */
+   ODP_IPSEC_DIR_OUTBOUND
+
+} odp_ipsec_dir_t;
+
+/**
+ * IPSEC operation mode
+ */
+typedef enum odp_ipsec_op_mode_t {
+   /** Synchronous IPSEC operation
+ *
+ * Application uses synchronous IPSEC operations,
+ * which output all results on function return.
+ */
+   ODP_IPSEC_OP_MODE_SYNC = 0,
+
+   /** Asynchronous IPSEC operation
+ *
+ * Application uses asynchronous IPSEC operations,
+ * which return results via events.
+ */
+   ODP_IPSEC_OP_MODE_ASYNC
+
+} odp_ipsec_op_mode_t;
+
+/**
+ * IPSEC protocol mode
+ */
+typedef enum odp_ipsec_mode_t {
+   /** IPSEC tunnel mode */
+   ODP_IPSEC_MODE_TUNNEL = 0,
+
+   /** IPSEC transport mode */
+   ODP_IPSEC_MODE_TRANSPORT
+
+} odp_ipsec_mode_t;
+
+/**
+ * IPSEC protocol
+ */
+typedef enum odp_ipsec_proto_t {
+   /** ESP protocol */
+   ODP_IPSEC_ESP = 0,
+
+   /** AH protocol */
+   ODP_IPSEC_AH
+
+} odp_ipsec_proto_t;
+
+/**
+ * IPSEC tunnel type
+ */
+typedef enum odp_ipsec_tunnel_type_t {
+   /** Outer header is IPv4 */
+   ODP_IPSEC_TUNNEL_IPV4 = 0,
+
+   /** Outer header is IPv6 */
+   ODP_IPSEC_TUNNEL_IPV6
+
+} odp_ipsec_tunnel_type_t;
+
+/**
+ * IPSEC crypto parameters
+ */
+typedef struct odp_ipsec_crypto_param_t {
+   /** Cipher algorithm */
+   odp_cipher_alg_t cipher_alg;
+
+   /** Cipher key */
+   odp_crypto_key_t cipher_key;
+
+   /** Authentication algorithm */
+   odp_auth_alg_t auth_alg;
+
+   /** Authentication key */
+   odp_crypto_key_t auth_key;
+
+} odp_ipsec_crypto_param_t;
+
+/**
+ * IPSEC tunnel parameters
+ *
+ * These parameters are used to build outbound tunnel headers. All 
+values are
+ * passed in CPU native byte / bit order if not specified otherwise.
+ * IP addresses must be in NETWORK byte order as those are passed in 
+with
+ * pointers and copied byte-by-byte from memory to the packet.
+ */
+typedef struct odp_ipsec_tunnel_param_t {
+   /** Tunnel type: IPv4 or IPv6 */
+   odp_ipsec_tunnel_type_t type;
+
+   union {
+   /** IPv4 header parameters */
+   struct {
+   /** IPv4 source address (NETWORK ENDIAN) */
+   void *src_addr;
+
+   /** IPv4 destination address (NETWORK ENDIAN) */
+   void *dst_addr;
+
+   /** IPv4 Differentiated Services Code Point */
+  

Re: [lng-odp] [RFCv2] api:crypto: Adding IPSEC protocol APIs.

[Nikhil Agarwal]

On 3 November 2016 at 18:55, Francois Ozog  wrote:

> Hi,
>
> Some hardware can accept clear IP packets, some require segmentation to be
> done and IPSec headers prepended before sending the packets (unencrypted)
> to HW.
>
> I would have expected capabilities reflect that so that ODP knows what to
> do: we don't want upper layers to be exposed to this HW specifics things.
> The flow would be:
>
> 1) OFP/SISU send clear packet (say 1500 bytes) to ODP IPSec API
> 2) depending on capabilities
>a. ODP sends the packet to HW for encryption and send (including
> fragmentation)
> or
>b. ODP splits packet according to MTU, prepends IPSec headers, deal
> with sequence numbers (optional), sends packets to HW for encryption and
> send
>
[Nikhil] ODP API will behave in similar way. Policy parameter
ODP_IPSEC_POLICY_REDSIDE_FRAGMENTATION_ENABLE will control whether to
fragment plain packet and then encrypt 2 packets or encrypt first and then
fragment the ciphered packet. This capability of RED(random early
detection) side fragmentation will be a capability that implementation may
support and will inform the application through capability APIs.

>
> How to deal with anti-replay attacks and seq number handling?
>
Session param uint16_t ar_ws controls anti replay enable/disable and anti
replay window configuration.
esn bit in session flags indicates whether to use extended seq number or
not. User can also configure initial seq number for session using session
params.
ODP_IPSEC_SA_SEQ_NUM_OVERFLOW type of notification from ODP will let the
application know that seq num for a session has overflown and needs proper
action from user.


>
> How to control ICMP messages related to MTU so that upper TCP layers are
> aware of the required actions when IPSec is handled in HW? ICMP proxying by
> HW?
>
These features are yet not include in the RFC.

>
>
> FF
>
> On 26 October 2016 at 04:55, Bill Fischofer 
> wrote:
>
>> On Mon, Oct 24, 2016 at 12:04 PM, Nikhil Agarwal <
>> nikhil.agar...@linaro.org>
>> wrote:
>>
>> > This RFC introduces IPSEC crypto offload APIs. These APIs can be used in
>> > accelerator
>> > pipeline model or for look aside IPSEC model.
>> >
>> > TODO items:
>> > - statistics amd capability APIs
>> > - Encrypt and send APIs
>> >
>> > Signed-off-by: Nikhil Agarwal 
>> > ---
>> >  include/odp/api/spec/crypto.h  |  29 ++
>> >  include/odp/api/spec/crypto_ipsec.h| 449
>> > +
>> >  .../include/odp/api/plat/event_types.h |   1 +
>> >  3 files changed, 479 insertions(+)
>> >  create mode 100644 include/odp/api/spec/crypto_ipsec.h
>> >
>> > diff --git a/include/odp/api/spec/crypto.h
>> b/include/odp/api/spec/crypto.h
>> > index dea1fe9..3a67d92 100644
>> > --- a/include/odp/api/spec/crypto.h
>> > +++ b/include/odp/api/spec/crypto.h
>> > @@ -144,6 +144,27 @@ typedef union odp_crypto_auth_algos_t {
>> > uint32_t all_bits;
>> >  } odp_crypto_auth_algos_t;
>> >
>> > +
>> > +/**
>> > + * Network security protocols in bit field structure
>> > + */
>> > +typedef union odp_crypto_protocol_t {
>> > +   /** Network security protocols */
>> > +   struct {
>> > +   /** ESP Protocol */
>> > +   uint32_t ipsec_esp: 1;
>> > +
>> > +   /** AH protocol */
>> > +   uint32_t ipsec_ah : 1;
>> > +
>> > +   } bit;
>> > +
>> > +   /** All bits of the bit field structure
>> > + *
>> > + * This field can be used to set/clear all flags, or bitwise
>> > + * operations over the entire structure. */
>> > +   uint32_t all_bits;
>> > +} odp_crypto_protocol_t;
>> >  /**
>> >   * Crypto API key structure
>> >   */
>> > @@ -264,6 +285,8 @@ typedef enum {
>> > ODP_CRYPTO_SES_CREATE_ERR_INV_CIPHER,
>> > /** Creation failed, bad auth params */
>> > ODP_CRYPTO_SES_CREATE_ERR_INV_AUTH,
>> > +   /** Creation failed, bad protocol params */
>> > +   ODP_CRYPTO_SES_CREATE_ERR_INV_PROTO,
>> >  } odp_crypto_ses_create_err_t;
>> >
>> >  /**
>> > @@ -332,6 +355,12 @@ typedef struct odp_crypto_capability_t {
>> > /** Authentication algorithms implemented with HW offload */
>> > odp_crypto_auth_algos_t   hw_auths;
>> >
>> > +   /** Supp

[lng-odp] [RFCv2] api:crypto: Adding IPSEC protocol APIs.

[Nikhil Agarwal]

This RFC introduces IPSEC crypto offload APIs. These APIs can be used in 
accelerator
pipeline model or for look aside IPSEC model.

TODO items:
- statistics amd capability APIs
- Encrypt and send APIs

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h  |  29 ++
 include/odp/api/spec/crypto_ipsec.h| 449 +
 .../include/odp/api/plat/event_types.h |   1 +
 3 files changed, 479 insertions(+)
 create mode 100644 include/odp/api/spec/crypto_ipsec.h

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index dea1fe9..3a67d92 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -144,6 +144,27 @@ typedef union odp_crypto_auth_algos_t {
uint32_t all_bits;
 } odp_crypto_auth_algos_t;
 
+
+/**
+ * Network security protocols in bit field structure
+ */
+typedef union odp_crypto_protocol_t {
+   /** Network security protocols */
+   struct {
+   /** ESP Protocol */
+   uint32_t ipsec_esp: 1;
+
+   /** AH protocol */
+   uint32_t ipsec_ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+ *
+ * This field can be used to set/clear all flags, or bitwise
+ * operations over the entire structure. */
+   uint32_t all_bits;
+} odp_crypto_protocol_t;
 /**
  * Crypto API key structure
  */
@@ -264,6 +285,8 @@ typedef enum {
ODP_CRYPTO_SES_CREATE_ERR_INV_CIPHER,
/** Creation failed, bad auth params */
ODP_CRYPTO_SES_CREATE_ERR_INV_AUTH,
+   /** Creation failed, bad protocol params */
+   ODP_CRYPTO_SES_CREATE_ERR_INV_PROTO,
 } odp_crypto_ses_create_err_t;
 
 /**
@@ -332,6 +355,12 @@ typedef struct odp_crypto_capability_t {
/** Authentication algorithms implemented with HW offload */
odp_crypto_auth_algos_t   hw_auths;
 
+   /** Supported authentication algorithms */
+   odp_crypto_protocol_t   protocols;
+
+   /** Authentication algorithms implemented with HW offload */
+   odp_crypto_protocol_t   hw_protocols;
+
 } odp_crypto_capability_t;
 
 /**
diff --git a/include/odp/api/spec/crypto_ipsec.h 
b/include/odp/api/spec/crypto_ipsec.h
new file mode 100644
index 000..5916ea0
--- /dev/null
+++ b/include/odp/api/spec/crypto_ipsec.h
@@ -0,0 +1,449 @@
+/* Copyright (c) 2014, Linaro Limited
+ * Copyright (c) 2015 - 2016 Freescale Semiconductor, Inc.
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP crypto IPSec extension
+ */
+
+#ifndef ODP_API_CRYPTO_IPSEC_H_
+#define ODP_API_CRYPTO_IPSEC_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+typedef enum odp_ipsec_mode {
+   ODP_IPSEC_MODE_TUNNEL,  /** IPSec tunnel mode */
+   ODP_IPSEC_MODE_TRANSPORT,   /** IPSec transport mode */
+} odp_ipsec_mode_t;
+
+typedef enum odp_ipsec_proto {
+   ODP_IPSEC_ESP, /** ESP protocol */
+   ODP_IPSEC_AH,  /** AH protocol */
+} odp_ipsec_proto_t;
+
+typedef enum odp_ipsec_outhdr_type {
+   ODP_IPSEC_OUTHDR_IPV4,/** Outer header is IPv4 */
+   ODP_IPSEC_OUTHDR_IPV6,/** Outer header is IPv6 */
+} odp_ipsec_outhdr_type_t;
+
+/**
+  * ODP IPSEC flags bit feilds structure
+  */
+
+typedef struct odp_ipsec_session_flags {
+   uint32_t esn : 1;
+   /** When enabled, extended sequence numbers is used */
+   uint32_t nat_t : 1;
+   /** When enabled, this indicates that UDP encapsulation/decapsulation
+ * for IPSEC packet has to be done so that IPSEC packet can traverse
+ * through NAT boxes. UDP encapsulation/decapsulation is to be applied
+ * for packets that get processed off this SA.
+ */
+   uint32_t copy_dscp : 1;
+   /** When enabled, Copy the IPv4 TOS or IPv6 Traffic Class byte from
+ * inner/outer IP header to the outer/inner IP header. If disabled
+ * values from configured Header will be used */
+   uint32_t copy_df : 1;
+   /** When enabled, copy the DF bit from the inner IP header to the outer
+ * IP header. If disabled, values from configured Header will be used 
*/
+
+   uint32_t ip_dttl : 1;
+   /** When enabled,IPv4 ttl/IPv6 Hop Limit feild will be decremented
+ * in case of tunnel mode encap & decap */
+
+   uint32_t remove_outer_hdr : 1;
+   /** remove outer header - tunnel mode decap */
+
+   uint32_t verify_sa_selectors : 1;
+   /** This flag is only application to inbound sessions. When enabled,
+ * this indicates that post decryption, selectors needs to be verified
+ * for this session. */
+
+} odp_ipsec_session_flags_t;
+
+typedef enum odp_ipsec_sa_lifetime_type {
+   ODP_IPSEC_SA_LIFETIME_IN_SEC, /** SA life time is in seconds */
+   ODP_IPSEC_SA_LIFETIME_IN_KB,  /** SA life time is in kilo bytes */
+   ODP_IPSEC_SA_LIFETIME_IN_PKT_CNT, /*

Re: [lng-odp] [PATCH] api:crypto: Adding IPSEC protocol APIs.

[Nikhil Agarwal Agarwal]

Inline responses.

Regards
Nikhil
-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Peltonen, 
Janne (Nokia - FI/Espoo)
Sent: Tuesday, September 27, 2016 9:24 PM
To: nikhil.agar...@linaro.org; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCH] api:crypto: Adding IPSEC protocol APIs.

Hi,

Is this work toward a look-a-side IPsec offload or toward inline IPsec offload?


How would the application offer packets to IPsec processing and how would it 
get the processed packets back and how would it know which policy and session 
was applied to the packet? What happens when an outbound packet matches a 
policy for which there is no session?

[NA] This effort  is towards both having look-a-side as well as the inline 
IPSEC offload. For look-a-side application can offer packets to engine using 
same APi odp_crypto_operation. Also for look-aside only SA info needs to be 
offloaded to engine as policy matching will be done in GPP.

Should there be support for "discard" policies/sessions that just drop the 
packets?

[NA] Yes there needs to be. Currently that can be supported through 
Classification APIs.

It would be nice to have support for multiple instances of SPD and SAD so that 
one would e.g. be able to do IPsec with virtual routing and forwarding (or 
network namespaces) even when addresses etc overlap.
[NA] Yes. That area needs to be looked into yet.

Does the API promise to do inbound policy check for decapsulated packets, i.e. 
check that the clear text packets match a policy associated with the SA that 
was used in the decapsulation, or is it something that the application has to 
do itself?
IOW, I want to check that packets came through a tunnel they were supposed to 
come and not through some unrelated tunnel.

[NA] Yes. I would like to add option for user to configure that wether to do 
inbound SPD verification. By default it would do that.

> +typedef enum odp_ipsec_ar_ws {
> + ODP_IPSEC_AR_WS_NONE,  /**< Anti-replay is not enabled */
> + ODP_IPSEC_AR_WS_32,/**< Anti-replay window size 32 */
> + ODP_IPSEC_AR_WS_64,/**< Anti-replay window size 64 */
> + ODP_IPSEC_AR_WS_128,   /**< Anti-replay window size 128 */
> +} odp_ipsec_ar_ws_t;

I do not see why this would be better than specifying the anti-replay window as 
an integer. The implementation would then be free to select any window size 
greater or equal to what was requested. The proposed API would impose somewhat 
artificial a restriction and would need to be updated if/when bigger window 
sizes would be supported.

[NA] Agree. Will change that in next version.

> +typedef struct odp_ipsec_params {

There is no information about the used crypto-algorithms and their keys here.

[NA] This info already exist in odp_crypto_session_params_t. For creating ipsec 
session user needs to provide both session params. This is to avoid duplication 
of same params again.

> + odp_bool_t auto_iv; /** Auto IV generation for each operation. */

What if this is false? Is the IV provided with the packet?
How?

Yes. In odp_crypto_session API there is an option of providing IV per packet IV 
or you may also choose per session IV.

> + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
> +decap */

What happens if this is false? ESP/AH gets removed and the packet appears as 
IPIP-tunneled packet? Something else?
[NA] Nope. It will not remove ESP AH header as well. In this case it will just 
decrypt the packet contents, and verify the ICV.

> +int odp_crypto_ipsec_session_create(odp_crypto_session_params_t *ses_params,
> + odp_ipsec_proto_t ipsec_proto,
> + odp_ipsec_params_t *ipsec_params,
> + odp_crypto_session_t *session_out,
> + odp_crypto_ses_create_err_t *status);

The first parameter looks redundant and the type has not been defined. I wonder 
why ipsec_proto is a separate parameter and not included in ipsec_params like 
all the other stuff?
[NA] This is done in a view that ESP and AH may have seprate set of params. It 
can be included as well.

> +struct odp_ipsec_spd_params{

How do I put the policies in priority order in case I have overlapping 
policies? Not supporting overlapping policies at all would of course be simpler 
but a bit restrictive.

[NA] Yes this may be included in next version. We may specify the location 
where this policy needs to be inserted.

> + enum odp_ipsec_policy_redside_fragmentation redside;
> + /**< Fragmentation before Encapsulation option: TRUE/FALSE */

Where does the MTU value come from? I suppose it could be part of session or 
policy so that the application could update it e.g. based on the current idea 
of PMTU.

[NA] for Autonomous IPSEC , i.e. full offload it will be fetched from the 
interface on which the packet is outgoing.

I suppose the application needs to co

[lng-odp] [PATCH] api:crypto: Adding IPSEC protocol APIs.

[Nikhil Agarwal]

TODO items:
- Event Notification(Eg. Seq Number overflow, SA not found, SA hard/soft expiry)
- statistics APIs
- Encrpt and send APIs

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h   |  29 +++
 include/odp/api/spec/crypto_ipsec.h | 345 
 2 files changed, 374 insertions(+)
 create mode 100644 include/odp/api/spec/crypto_ipsec.h

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index dea1fe9..b629b82 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -144,6 +144,27 @@ typedef union odp_crypto_auth_algos_t {
uint32_t all_bits;
 } odp_crypto_auth_algos_t;
 
+
+/**
+ * Network security protocols in bit field structure
+ */
+typedef union odp_crypto_protocol_t {
+   /** Network security protocols */
+   struct {
+   /** ODP_AUTH_ALG_NULL */
+   uint32_t ipsec_esp: 1;
+
+   /** ODP_AUTH_ALG_MD5_96 */
+   uint32_t ipsec_ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+ *
+ * This field can be used to set/clear all flags, or bitwise
+ * operations over the entire structure. */
+   uint32_t all_bits;
+} odp_crypto_protocol_t;
 /**
  * Crypto API key structure
  */
@@ -264,6 +285,8 @@ typedef enum {
ODP_CRYPTO_SES_CREATE_ERR_INV_CIPHER,
/** Creation failed, bad auth params */
ODP_CRYPTO_SES_CREATE_ERR_INV_AUTH,
+   /** Creation failed, bad protocol params */
+   ODP_CRYPTO_SES_CREATE_ERR_INV_PROTO,
 } odp_crypto_ses_create_err_t;
 
 /**
@@ -332,6 +355,12 @@ typedef struct odp_crypto_capability_t {
/** Authentication algorithms implemented with HW offload */
odp_crypto_auth_algos_t   hw_auths;
 
+   /** Supported authentication algorithms */
+   odp_crypto_protocol_t   protocols;
+
+   /** Authentication algorithms implemented with HW offload */
+   odp_crypto_protocol_t   hw_protocols;
+
 } odp_crypto_capability_t;
 
 /**
diff --git a/include/odp/api/spec/crypto_ipsec.h 
b/include/odp/api/spec/crypto_ipsec.h
new file mode 100644
index 000..6a0cee0
--- /dev/null
+++ b/include/odp/api/spec/crypto_ipsec.h
@@ -0,0 +1,345 @@
+/* Copyright (c) 2014, Linaro Limited
+ * Copyright (c) 2015 - 2016 Freescale Semiconductor, Inc.
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP crypto IPSec extension
+ */
+
+#ifndef ODP_API_CRYPTO_IPSEC_H_
+#define ODP_API_CRYPTO_IPSEC_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+typedef enum odp_ipsec_mode {
+   ODP_IPSEC_MODE_TUNNEL,  /**< IPSec tunnel mode */
+   ODP_IPSEC_MODE_TRANSPORT,   /**< IPSec transport mode */
+} odp_ipsec_mode_t;
+
+typedef enum odp_ipsec_proto {
+   ODP_IPSEC_ESP, /**< ESP protocol */
+} odp_ipsec_proto_t;
+
+typedef enum odp_ipsec_outhdr_type {
+   ODP_IPSEC_OUTHDR_IPV4,/**< Outer header is IPv4 */
+   ODP_IPSEC_OUTHDR_IPV6,/**< Outer header is IPv6 */
+} odp_ipsec_outhdr_type_t;
+
+typedef enum odp_ipsec_ar_ws {
+   ODP_IPSEC_AR_WS_NONE,  /**< Anti-replay is not enabled */
+   ODP_IPSEC_AR_WS_32,/**< Anti-replay window size 32 */
+   ODP_IPSEC_AR_WS_64,/**< Anti-replay window size 64 */
+   ODP_IPSEC_AR_WS_128,   /**< Anti-replay window size 128 */
+} odp_ipsec_ar_ws_t;
+
+typedef struct odp_ipsec_params {
+   odp_ipsec_mode_t ipsec_mode; /** Transport or Tunnel */
+   uint32_t spi;/** SPI value */
+   uint32_t seq;/** Initial SEQ number */
+   odp_ipsec_ar_ws_t ar_ws; /** Anti-replay window size -
+   inbound session with authentication */
+   odp_bool_t esn; /** Use extended sequence numbers */
+   odp_bool_t auto_iv; /** Auto IV generation for each operation. */
+   uint16_t out_hdr_size;   /** outer header size - tunnel mode */
+   uint8_t *out_hdr;/** outer header - tunnel mode */
+   odp_ipsec_outhdr_type_t out_hdr_type; /* outer header type -
+   tunnel mode */
+   odp_bool_t ip_csum; /** update/verify ip header checksum */
+   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap & decap */
+   odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
decap */
+   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
+   IPv6 Traffic Class byte from the inner/outer
+   IP header to the outer/inner IP header -
+   tunnel mode encap & decap */
+   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
+   the inner IP header to the
+   outer IP header - tunnel mode encap

Re: [lng-odp] [PATCH] example: ipsec: Poll mode fix.

[Nikhil Agarwal Agarwal]

Does it matter. We are just saving this to local structure. Also we will start 
polling on these queues after launching worker threads post init.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim 
Uvarov
Sent: Thursday, September 08, 2016 9:37 PM
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCH] example: ipsec: Poll mode fix.

Hello Nikhil,

I think it's better to add inq to poll before pktio start.

Maxim.

On 08/16/16 17:22, Nikhil Agarwal wrote:
> Adding pktio queues in poll mode to polled queues.
>
> Signed-off-by: gagandeep singh 
> Signed-off-by: Nikhil Agarwal 
> ---
>   example/ipsec/odp_ipsec.c | 6 ++
>   1 file changed, 6 insertions(+)
>
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c 
> index 6a9a9fe..89ba1e9 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -561,6 +561,12 @@ void initialize_intf(char *intf)
>  odp_queue_to_u64(inq),
>  mac_addr_str(src_mac_str, src_mac));
>   
> + if (pktio_param.in_mode == ODP_PKTIN_MODE_QUEUE) {
> + poll_queues[num_polled_queues++] = inq;
> + printf("%s: adding %"PRIu64"\n", __func__,
> +odp_queue_to_u64(inq));
> + }
> +
>   /* Resolve any routes using this interface for output */
>   resolve_fwd_db(intf, pktout, src_mac);
>   }

Re: [lng-odp] issue with odp_crypto validation suite

[Nikhil Agarwal Agarwal]

Krishna,

Following is the API documentation for "auth_cipher_text"

* @var odp_crypto_session_params_t::auth_cipher_text
 *
 *   Controls ordering of authentication and cipher operations,
 *   and is relative to the operation (encode vs decode).
 *   When encoding, @c TRUE indicates the authentication operation
 *   should be performed @b after the cipher operation else before.
 *   When decoding, @c TRUE indicates the reverse order of operation.

Logically speaking this seems correct as well. If in encode direction you did 
cipher first and then auth, then in decode direction you have to follow the 
reverse order. I hope this clarifies your doubt.

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Krishna 
Garapati
Sent: Tuesday, September 06, 2016 6:34 PM
To: LNG ODP Mailman List 
Subject: [lng-odp] issue with odp_crypto validation suite

From odp crypto validation suite I see that the application is setting 
"auth_cipher_text" flag from odp_crypto_session_params to "false" all ways 
(Irrespective of ENCODE or DECODE). What this means from my understanding is 
application wants to do "cipher first and then authentication".  And in the 
odp_crypto implementation during session_create if the crypto operation is 
ENCODE, this flag is set as is against the 
"odp_crypto_generic_session_t->do_cipher_first" which actually instead leads to 
do authentication then ciphering during crypto operation. This feels wrong in 
some way. Any idea about this implementation ?.

/Krishna

[lng-odp] [RFC] api:crypto: Adding IPSEC protocol APIs.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h   |  29 +
 include/odp/api/spec/crypto_ipsec.h | 114 
 2 files changed, 143 insertions(+)
 create mode 100644 include/odp/api/spec/crypto_ipsec.h

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index dea1fe9..b629b82 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -144,6 +144,27 @@ typedef union odp_crypto_auth_algos_t {
uint32_t all_bits;
 } odp_crypto_auth_algos_t;
 
+
+/**
+ * Network security protocols in bit field structure
+ */
+typedef union odp_crypto_protocol_t {
+   /** Network security protocols */
+   struct {
+   /** ODP_AUTH_ALG_NULL */
+   uint32_t ipsec_esp: 1;
+
+   /** ODP_AUTH_ALG_MD5_96 */
+   uint32_t ipsec_ah : 1;
+
+   } bit;
+
+   /** All bits of the bit field structure
+ *
+ * This field can be used to set/clear all flags, or bitwise
+ * operations over the entire structure. */
+   uint32_t all_bits;
+} odp_crypto_protocol_t;
 /**
  * Crypto API key structure
  */
@@ -264,6 +285,8 @@ typedef enum {
ODP_CRYPTO_SES_CREATE_ERR_INV_CIPHER,
/** Creation failed, bad auth params */
ODP_CRYPTO_SES_CREATE_ERR_INV_AUTH,
+   /** Creation failed, bad protocol params */
+   ODP_CRYPTO_SES_CREATE_ERR_INV_PROTO,
 } odp_crypto_ses_create_err_t;
 
 /**
@@ -332,6 +355,12 @@ typedef struct odp_crypto_capability_t {
/** Authentication algorithms implemented with HW offload */
odp_crypto_auth_algos_t   hw_auths;
 
+   /** Supported authentication algorithms */
+   odp_crypto_protocol_t   protocols;
+
+   /** Authentication algorithms implemented with HW offload */
+   odp_crypto_protocol_t   hw_protocols;
+
 } odp_crypto_capability_t;
 
 /**
diff --git a/include/odp/api/spec/crypto_ipsec.h 
b/include/odp/api/spec/crypto_ipsec.h
new file mode 100644
index 000..e80e2d9
--- /dev/null
+++ b/include/odp/api/spec/crypto_ipsec.h
@@ -0,0 +1,114 @@
+/* Copyright (c) 2014, Linaro Limited
+ * Copyright (c) 2015 - 2016 Freescale Semiconductor, Inc.
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP crypto IPSec extension
+ */
+
+#ifndef ODP_API_CRYPTO_IPSEC_H_
+#define ODP_API_CRYPTO_IPSEC_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+typedef enum odp_ipsec_mode {
+   ODP_IPSEC_MODE_TUNNEL,  /**< IPSec tunnel mode */
+   ODP_IPSEC_MODE_TRANSPORT,   /**< IPSec transport mode */
+} odp_ipsec_mode_t;
+
+typedef enum odp_ipsec_proto {
+   ODP_IPSEC_ESP, /**< ESP protocol */
+} odp_ipsec_proto_t;
+
+typedef enum odp_ipsec_outhdr_type {
+   ODP_IPSEC_OUTHDR_IPV4,/**< Outer header is IPv4 */
+   ODP_IPSEC_OUTHDR_IPV6,/**< Outer header is IPv6 */
+} odp_ipsec_outhdr_type_t;
+
+typedef enum odp_ipsec_ar_ws {
+   ODP_IPSEC_AR_WS_NONE,  /**< Anti-replay is not enabled */
+   ODP_IPSEC_AR_WS_32,/**< Anti-replay window size 32 */
+   ODP_IPSEC_AR_WS_64,/**< Anti-replay window size 64 */
+   ODP_IPSEC_AR_WS_128,   /**< Anti-replay window size 128 */
+} odp_ipsec_ar_ws_t;
+
+typedef struct odp_ipsec_params {
+   odp_ipsec_mode_t ipsec_mode; /** Transport or Tunnel */
+   uint32_t spi;/** SPI value */
+   uint32_t seq;/** Initial SEQ number */
+   odp_ipsec_ar_ws_t ar_ws; /** Anti-replay window size -
+   inbound session with authentication */
+   odp_bool_t esn; /** Use extended sequence numbers */
+   odp_bool_t auto_iv; /** Auto IV generation for each operation. */
+   uint16_t out_hdr_size;   /** outer header size - tunnel mode */
+   uint8_t *out_hdr;/** outer header - tunnel mode */
+   odp_ipsec_outhdr_type_t out_hdr_type; /* outer header type -
+   tunnel mode */
+   odp_bool_t ip_csum; /** update/verify ip header checksum */
+   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap & decap */
+   odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
decap */
+   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
+   IPv6 Traffic Class byte from the inner/outer
+   IP header to the outer/inner IP header -
+   tunnel mode encap & decap */
+   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
+   the inner IP header to the
+   outer IP header - tunnel mode encap */
+   odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel mode */
+   odp_bool_t udp_csum;

Re: [lng-odp] [PATCH] example: ipsec: Poll mode fix.

[Nikhil Agarwal]

Ping. Please review.

Regards
Nikhil

On 16 August 2016 at 19:52, Nikhil Agarwal 
wrote:

> Adding pktio queues in poll mode to polled queues.
>
> Signed-off-by: gagandeep singh 
> Signed-off-by: Nikhil Agarwal 
> ---
>  example/ipsec/odp_ipsec.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index 6a9a9fe..89ba1e9 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -561,6 +561,12 @@ void initialize_intf(char *intf)
>odp_queue_to_u64(inq),
>mac_addr_str(src_mac_str, src_mac));
>
> +   if (pktio_param.in_mode == ODP_PKTIN_MODE_QUEUE) {
> +   poll_queues[num_polled_queues++] = inq;
> +   printf("%s: adding %"PRIu64"\n", __func__,
> +  odp_queue_to_u64(inq));
> +   }
> +
> /* Resolve any routes using this interface for output */
> resolve_fwd_db(intf, pktout, src_mac);
>  }
> --
> 2.8.2
>
>

[lng-odp] [PATCH] example: ipsec: Poll mode fix.

[Nikhil Agarwal]

Adding pktio queues in poll mode to polled queues.

Signed-off-by: gagandeep singh 
Signed-off-by: Nikhil Agarwal 
---
 example/ipsec/odp_ipsec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index 6a9a9fe..89ba1e9 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -561,6 +561,12 @@ void initialize_intf(char *intf)
   odp_queue_to_u64(inq),
   mac_addr_str(src_mac_str, src_mac));
 
+   if (pktio_param.in_mode == ODP_PKTIN_MODE_QUEUE) {
+   poll_queues[num_polled_queues++] = inq;
+   printf("%s: adding %"PRIu64"\n", __func__,
+  odp_queue_to_u64(inq));
+   }
+
/* Resolve any routes using this interface for output */
resolve_fwd_db(intf, pktout, src_mac);
 }
-- 
2.8.2

[lng-odp] [PATCH 2/2] api:crypto: resolve todo items

[Nikhil Agarwal]

odp_session_proc_info_t is no longer required.
Clarified hash_result_offset and its relation with ICV value.

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index d8123e9..dea1fe9 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -170,8 +170,6 @@ typedef struct odp_crypto_data_range {
 
 /**
  * Crypto API session creation parameters
- *
- * @todo Add "odp_session_proc_info_t"
  */
 typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
@@ -210,8 +208,6 @@ typedef struct odp_crypto_session_params {
 
 /**
  * Crypto API per packet operation parameters
- *
- * @todo Clarify who zero's ICV and how this relates to "hash_result_offset"
  */
 typedef struct odp_crypto_op_params {
odp_crypto_session_t session;   /**< Session handle from creation */
@@ -245,6 +241,14 @@ typedef struct odp_crypto_op_params {
  *   indicates the caller wishes the destination packet buffer be allocated
  *   from the output pool specified during session creation.
  *
+ * @var odp_crypto_op_params_t::hash_result_offset
+ *
+ *   Specifies the offset where the hash result is to be stored. In case of
+ *   decode sessions, input hash values will be read from this offset, and
+ *   overwritten with hash results. If this offset lies within specified
+ *   auth_range, implementation will mute this field before calculating the 
hash
+ *   result.
+ *
  *   @sa odp_crypto_session_params_t::output_pool.
  */
 
-- 
2.8.2

[lng-odp] [PATCH 1/2] example:ipsec: removed invalid todos.

[Nikhil Agarwal]

This todo item is no longer valid.
Fixed as a part of following work card.
https://cards.linaro.org/browse/LNG-857

Signed-off-by: Nikhil Agarwal 
---
 example/ipsec/odp_ipsec_stream.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/example/ipsec/odp_ipsec_stream.h b/example/ipsec/odp_ipsec_stream.h
index ea480c3..6f6f7df 100644
--- a/example/ipsec/odp_ipsec_stream.h
+++ b/example/ipsec/odp_ipsec_stream.h
@@ -93,10 +93,6 @@ odp_packet_t create_ipv4_packet(stream_db_entry_t *stream,
 /**
  * Verify an IPv4 packet received on a loop output queue
  *
- * @todo Better error checking, add counters, add tracing,
- *   remove magic numbers, add order verification
- *   (see https://bugs.linaro.org/show_bug.cgi?id=620)
- *
  * @param stream  Stream to verify the packet against
  * @param pkt Packet to verify
  *
-- 
2.8.2

[lng-odp] [RFC OPNESSL-ODP 2/2] Adding Async ODP engine for AES cipher

[Nikhil Agarwal]

---
 README   |  21 +++
 engine/eng_odp.c | 437 +++
 2 files changed, 458 insertions(+)
 create mode 100644 README
 create mode 100644 engine/eng_odp.c

diff --git a/README b/README
new file mode 100644
index 000..b13393a
--- /dev/null
+++ b/README
@@ -0,0 +1,21 @@
+Copyright (c) 2013-2014, Linaro Limited
+All rights reserved.
+
+SPDX-License-Identifier:BSD-3-Clause
+
+OpenDataPlane (ODP) project source code.
+http://www.opendataplane.org/
+
+How to build:
+Following are the steep to build this object:
+./bootstrap
+./configure --with-openssl-path= 
--with-odp-path=
+make
+
+How to run.
+Copy the shared object engine/.libs/libsslodp.so to "opnessl 
path"/lib/engines/.
+Execute any openssl application with arguments  "-engine libsslodp".
+
+Currently, we have tested openssl speed application with NXP platform.
+
+
diff --git a/engine/eng_odp.c b/engine/eng_odp.c
new file mode 100644
index 000..91151ae
--- /dev/null
+++ b/engine/eng_odp.c
@@ -0,0 +1,437 @@
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+odp_pool_t pool;
+int num_queue = 8;
+odp_queue_t out_queue[8];
+
+typedef struct ossl_odp_status {
+   bool is_complete;
+   bool is_successful;
+} ossl_odp_status_t;
+
+/* Engine Id and Name */
+static const char *engine_odp_id = "libsslodp";
+static const char *engine_odp_name = "ODP based engine";
+
+/* Engine Lifetime functions */
+static int ossl_odp_destroy(ENGINE *e);
+static int ossl_odp_init(ENGINE *e);
+static int ossl_odp_finish(ENGINE *e);
+
+/* Set up digests. Just SHA1 for now */
+static int ossl_odp_digests(ENGINE *e, const EVP_MD **digest,
+   const int **nids, int nid);
+
+/*
+ * Holds the EVP_MD object for sha1 in this engine. Set up once only during
+ * engine bind and can then be reused many times.
+ */
+static EVP_MD *_hidden_sha1_md = NULL;
+static const EVP_MD *ossl_odp_sha1(void)
+{
+   return _hidden_sha1_md;
+}
+static void destroy_digests(void)
+{
+   EVP_MD_meth_free(_hidden_sha1_md);
+   _hidden_sha1_md = NULL;
+}
+
+
+static int ossl_odp_digest_nids(const int **nids)
+{
+   static int digest_nids[2] = { 0, 0 };
+   static int pos = 0;
+   static int init = 0;
+
+   if (!init) {
+   const EVP_MD *md;
+   if ((md = ossl_odp_sha1()) != NULL)
+   digest_nids[pos++] = EVP_MD_type(md);
+   digest_nids[pos] = 0;
+   init = 1;
+   }
+   *nids = digest_nids;
+   return pos;
+}
+
+/* AES */
+
+static int ossl_odp_aes128_init_key(EVP_CIPHER_CTX *ctx,
+   const unsigned char *key, const unsigned char *iv, int enc);
+static int ossl_odp_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
+   const unsigned char *in, size_t inl);
+static int ossl_odp_aes128_cbc_cleanup(EVP_CIPHER_CTX *ctx);
+
+struct ossl_odp_ctx {
+   odp_crypto_session_t session;
+};
+
+/*
+ * Holds the EVP_CIPHER object for aes_128_cbc in this engine. Set up once only
+ * during engine bind and can then be reused many times.
+ */
+static EVP_CIPHER *_hidden_aes_128_cbc;
+static const EVP_CIPHER *ossl_odp_aes_128_cbc(void)
+{
+   return _hidden_aes_128_cbc;
+}
+
+static void destroy_ciphers(void)
+{
+   EVP_CIPHER_meth_free(_hidden_aes_128_cbc);
+   _hidden_aes_128_cbc = NULL;
+}
+
+static int ossl_odp_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
+   const int **nids, int nid);
+
+static int ossl_odp_cipher_nids[] = {
+   NID_aes_128_cbc,
+   0
+};
+
+
+static int bind_odp(ENGINE *e)
+{
+   odp_queue_param_t qparam;
+   odp_pool_param_t params;
+   int i;
+   if (0 != odp_init_global(NULL, NULL)) {
+   printf("error: odp_init_global() failed.\n");
+   return -1;
+   }
+
+   if (0 != odp_init_local(ODP_THREAD_WORKER)) {
+   printf("error: odp_init_local() failed.\n");
+   return -1;
+   }
+
+   memset(¶ms, 0, sizeof(params));
+   params.pkt.seg_len = 20480;
+   params.pkt.len = 20480;
+   params.pkt.num = 4096;
+   params.type = ODP_POOL_PACKET;
+
+   pool = odp_pool_create("ossl_odp_pool", ¶ms);
+
+   if (ODP_POOL_INVALID == pool) {
+   printf("Packet pool creation failed.\n");
+   odp_term_local();
+   odp_term_global();
+   return -1;
+   }
+   odp_queue_param_init(&qparam);
+   qparam.sched.prio = ODP_SCHED_PRIO_HIGHEST;
+   qparam.sched.sync = ODP_SCHED_SYNC_ATOMIC;
+   qparam.sched.group = ODP_SCHED_GROUP_ALL;
+   for (i = 0; i < num_queue; i++) {
+   char queue_name[256] = {0};
+   sprintf(queue_name, "%s%d", "ossl_out_queue_", i);
+   out_queue[i] = odp_queue_create(queue_name,
+

[lng-odp] [RFC OPNESSL-ODP 1/2] Initial Commit for Makeflies and configure scripts.

[Nikhil Agarwal]

From: Nikhil Agarwal 

Added Directory structure. Makeflies and configure scripts.

Signed-off-by: Nikhil Agarwal 
---
 .gitignore |  25 ++
 Makefile.am|   2 +
 bootstrap  |   7 +++
 configure.ac   | 136 +
 engine/Makefile.am |   5 ++
 5 files changed, 175 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 Makefile.am
 create mode 100755 bootstrap
 create mode 100644 configure.ac
 create mode 100644 engine/Makefile.am

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..1f844a8
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,25 @@
+Makefile
+Makefile.in
+aclocal.m4
+ar-lib
+autom4te.cache/
+compile
+config.guess
+config.log
+config.status
+config.sub
+configure
+depcomp
+engine/.deps/
+engine/.libs/
+engine/Makefile
+engine/Makefile.in
+engine/eng_odp.lo
+engine/eng_odp.o
+engine/libsslodp.la
+install-sh
+libtool
+ltmain.sh
+m4/
+missing
+
diff --git a/Makefile.am b/Makefile.am
new file mode 100644
index 000..0536da9
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,2 @@
+ACLOCAL_AMFLAGS=-I m4
+SUBDIRS = engine
diff --git a/bootstrap b/bootstrap
new file mode 100755
index 000..ce37658
--- /dev/null
+++ b/bootstrap
@@ -0,0 +1,7 @@
+#! /bin/sh
+set -x
+#mkdir m4
+aclocal
+libtoolize --copy
+automake --add-missing --copy --warnings=all
+autoconf
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..19249c9
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,136 @@
+AC_PREREQ([2.5])
+AC_INIT([ossl-odp], [0.1], [lng-odp@lists.linaro.org])
+AM_INIT_AUTOMAKE([foreign])
+AC_CONFIG_SRCDIR([engine/eng_odp.c])
+
+AC_USE_SYSTEM_EXTENSIONS
+AC_SYS_LARGEFILE
+AC_CONFIG_MACRO_DIR([m4])
+AM_SILENT_RULES([yes])
+
+# Checks for programs.
+AC_PROG_CC
+AM_PROG_CC_C_O
+
+AC_PROG_CXX
+AC_PROG_INSTALL
+AC_PROG_MAKE_SET
+
+AM_PROG_AR
+#Use libtool
+LT_INIT([])
+AC_SUBST([LIBTOOL_DEPS])
+AM_PROG_LIBTOOL
+
+# Checks for library functions.
+AC_FUNC_MALLOC
+
+# Checks for typedefs, structures, and compiler characteristics.
+AC_HEADER_STDBOOL
+AC_C_INLINE
+AC_TYPE_SIZE_T
+AC_TYPE_SSIZE_T
+AC_TYPE_UINT8_T
+AC_TYPE_UINT16_T
+AC_TYPE_INT32_T
+AC_TYPE_UINT32_T
+AC_TYPE_UINT64_T
+
+##
+# Which architecture optimizations will we use
+##
+AS_CASE([$host],
+  [x86*], [ARCH=x86],
+  [mips64*], [ARCH=mips64],
+  [aarch64*], [ARCH=aarch64],
+  [powerpc*], [ARCH=powerpc],
+  [ARCH=linux]
+)
+AC_SUBST([ARCH])
+
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_CPPFLAGS=$CPPFLAGS
+LDFLAGS="$AM_LDFLAGS $LDFLAGS"
+CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+
+
+##
+# Default include setup
+##
+AM_CFLAGS="$AM_CFLAGS $ODP_CFLAGS"
+AM_CXXFLAGS="-std=c++11"
+
+
+
+##
+# Set optional OpenSSL path
+##
+AC_ARG_WITH([openssl-path],
+   AC_HELP_STRING([--with-openssl-path=DIR path to openssl libs and 
headers],
+   [(or in the default path if not specified).]),
+   [OPENSSL_PATH=$withval
+   AM_CPPFLAGS="$AM_CPPFLAGS -I$OPENSSL_PATH/include"
+   AM_LDFLAGS="$AM_LDFLAGS -L$OPENSSL_PATH/lib"
+   ],[])
+
+##
+# Set optional ODP path
+##
+AC_ARG_WITH([odp-path],
+   AC_HELP_STRING([--with-odp-path=DIR path to odp libs and headers],
+   [(or in the default path if not specified).]),
+   [ODP_PATH=$withval
+   AM_CPPFLAGS="$AM_CPPFLAGS -I$ODP_PATH/include"
+   AM_LDFLAGS="$AM_LDFLAGS -L$ODP_PATH/lib"
+   ],[])
+
+
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_CPPFLAGS=$CPPFLAGS
+LDFLAGS="$AM_LDFLAGS $LDFLAGS"
+CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+
+AC_CHECK_LIB([odp], [odp_init_global],[ODP_LIB=-lodp],
+   [AC_MSG_FAILURE([ODP library required])])
+
+
+AC_CONFIG_FILES([Makefile
+   engine/Makefile
+   ])
+
+AC_SUBST([ODP_PATH])
+AC_SUBST([ODP_LIB])
+AC_SUBST([OPENSSL_PATH])
+AC_SUBST([LIBS])
+AC_SUBST([AM_CPPFLAGS])
+AC_SUBST([CPPFLAGS])
+AC_SUBST([AM_CFLAGS])
+AC_SUBST([C

[lng-odp] [RFC API-NEXT] Adding crypto statistics.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 7b4424d..05e9221 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -330,6 +330,37 @@ typedef struct odp_crypto_capability_t {
 } odp_crypto_capability_t;
 
 /**
+ * Crypto Statistics
+ */
+typedef struct odp_crypto_stats {
+   /** Number of outbound encode operations requested */
+   uint64_t enc_requests;
+   /** Number of inbound decode operations requested */
+   uint64_t dec_requests;
+   /** Number of operation completed */
+   uint64_t operation_complete;
+   /** Number of outbound bytes encrypted */
+   uint64_t bytes_encrypted;
+   /** Number of outbound bytes protected */
+   uint64_t bytes_protected;
+   /** Number of inbound bytes decrypted */
+   uint64_t bytes_decrypted;
+   /** Number of inbound Bytes validated */
+   uint64_t bytes_validated;
+} odp_crypto_stats_t;
+
+/**
+ * Get crypto statistics.
+ *
+ * Fetches crypto statistics on success.
+ *
+ * @param[out] stats   Pointer to crypto statistics for Output
+ * @retval 0   on success
+ * @retval <0  on failure
+ */
+int odp_crypto_global_stats(odp_crypto_global_stats_t *stats);
+
+/**
  * Query crypto capabilities
  *
  * Outputs crypto capabilities on success.
-- 
2.8.2

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

Re: [lng-odp] [RFCv2 API-NEXT] Adding API for Multi crypto operation support.

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Friday, June 10, 2016 4:30 PM
To: Nikhil Agarwal 
Cc: LNG ODP Mailman List 
Subject: Re: [lng-odp] [RFCv2 API-NEXT] Adding API for Multi crypto operation 
support.

On 10 June 2016 at 15:00, Nikhil Agarwal  wrote:
>
>
> On 9 June 2016 at 16:50, Bala Manoharan  wrote:
>>
>> Regards,
>> Bala
>>
>>
>> On 8 June 2016 at 22:38, Nikhil Agarwal  wrote:
>> > Signed-off-by: Nikhil Agarwal 
>> > ---
>> >  include/odp/api/spec/crypto.h | 29 +++--
>> >  1 file changed, 27 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/odp/api/spec/crypto.h 
>> > b/include/odp/api/spec/crypto.h index d8123e9..7b4424d 100644
>> > --- a/include/odp/api/spec/crypto.h
>> > +++ b/include/odp/api/spec/crypto.h
>> > @@ -214,7 +214,6 @@ typedef struct odp_crypto_session_params {
>> >   * @todo Clarify who zero's ICV and how this relates to 
>> > "hash_result_offset"
>> >   */
>> >  typedef struct odp_crypto_op_params {
>> > -   odp_crypto_session_t session;   /**< Session handle from
>> > creation */
>> > void *ctx;  /**< User context */
>> > odp_packet_t pkt;   /**< Input packet buffer */
>> > odp_packet_t out_pkt;   /**< Output packet buffer */
>> > @@ -406,6 +405,7 @@ void odp_crypto_compl_free(odp_crypto_compl_t
>> > completion_event);
>> >   * If "posted" returns TRUE the result will be delivered via the 
>> > completion
>> >   * queue specified when the session was created.
>> >   *
>> > + * @param session   Session handle
>> >   * @param paramsOperation parameters
>> >   * @param postedPointer to return posted, TRUE for async
>> > operation
>> >   * @param resultResults of operation (when posted returns
>> > FALSE)
>> > @@ -413,10 +413,35 @@ void odp_crypto_compl_free(odp_crypto_compl_t
>> > completion_event);
>> >   * @retval 0 on success
>> >   * @retval <0 on failure
>> >   */
>> > -int odp_crypto_operation(odp_crypto_op_params_t *params,
>> > +int odp_crypto_operation(odp_crypto_session_t session,
>> > +odp_crypto_op_params_t *params,
>> >  odp_bool_t *posted,
>> >  odp_crypto_op_result_t *result);
>> >
>> > +
>> > +/**
>> > + * Crypto packet burst operation
>> > + *
>> > + * Performs the cryptographic operations specified during session
>> > creation
>> > + * on the list of packets. Burst operation can only be performed
>> > asynchronously,
>> > + * and the result will be delivered via the completion queue 
>> > + specified
>> > when the
>> > + * session was created.
>> > + *
>> > + * @param session   Session handle
>> > + * @param paramsArray of Operation parameters
>> > + * @param postedPointer to return posted, TRUE for async
>> > operation
>> > + * @param resultResults of operation (when posted returns
>> > FALSE)
>> > + * @param num   Number of operations reuested
>> > + *
>> > + * @return Number of operations actually enqueued/completed (0 ... 
>> > +num)
>> > + * @retval <0 on failure
>> > + */
>> > +int odp_crypto_operation_multi(odp_crypto_session_t session,
>> > +  odp_crypto_op_params_t *params[],
>> > +  odp_bool_t *posted,
>> > +  odp_crypto_op_result_t *result[],
>> > +  int num);
>>
>> This function will have a performance issue with synchronous crypto 
>> operations since in sync crypto odp_crypto_operation_multi() is a 
>> blocking call and the call will have to be blocked for all the 
>> packets to complete before posting the result. Also the crypto 
>> operations were kept agnostic of the internal behaviour of the 
>> implementation so help in portability of the applications.
>
>
> This API will work with both synchronous and asynchronous modes. There 
> may be different recommendations from different implementations for 
> performance.
> All APIs may not perform equally on all implementations. Moreover 
> there will not be mu

Re: [lng-odp] [RFCv2 API-NEXT] Adding API for Multi crypto operation support.

[Nikhil Agarwal]

On 9 June 2016 at 16:50, Bala Manoharan  wrote:

> Regards,
> Bala
>
>
> On 8 June 2016 at 22:38, Nikhil Agarwal  wrote:
> > Signed-off-by: Nikhil Agarwal 
> > ---
> >  include/odp/api/spec/crypto.h | 29 +++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/odp/api/spec/crypto.h
> b/include/odp/api/spec/crypto.h
> > index d8123e9..7b4424d 100644
> > --- a/include/odp/api/spec/crypto.h
> > +++ b/include/odp/api/spec/crypto.h
> > @@ -214,7 +214,6 @@ typedef struct odp_crypto_session_params {
> >   * @todo Clarify who zero's ICV and how this relates to
> "hash_result_offset"
> >   */
> >  typedef struct odp_crypto_op_params {
> > -   odp_crypto_session_t session;   /**< Session handle from
> creation */
> > void *ctx;  /**< User context */
> > odp_packet_t pkt;   /**< Input packet buffer */
> > odp_packet_t out_pkt;   /**< Output packet buffer */
> > @@ -406,6 +405,7 @@ void odp_crypto_compl_free(odp_crypto_compl_t
> completion_event);
> >   * If "posted" returns TRUE the result will be delivered via the
> completion
> >   * queue specified when the session was created.
> >   *
> > + * @param session   Session handle
> >   * @param paramsOperation parameters
> >   * @param postedPointer to return posted, TRUE for async
> operation
> >   * @param resultResults of operation (when posted returns
> FALSE)
> > @@ -413,10 +413,35 @@ void odp_crypto_compl_free(odp_crypto_compl_t
> completion_event);
> >   * @retval 0 on success
> >   * @retval <0 on failure
> >   */
> > -int odp_crypto_operation(odp_crypto_op_params_t *params,
> > +int odp_crypto_operation(odp_crypto_session_t session,
> > +odp_crypto_op_params_t *params,
> >  odp_bool_t *posted,
> >  odp_crypto_op_result_t *result);
> >
> > +
> > +/**
> > + * Crypto packet burst operation
> > + *
> > + * Performs the cryptographic operations specified during session
> creation
> > + * on the list of packets. Burst operation can only be performed
> asynchronously,
> > + * and the result will be delivered via the completion queue specified
> when the
> > + * session was created.
> > + *
> > + * @param session   Session handle
> > + * @param paramsArray of Operation parameters
> > + * @param postedPointer to return posted, TRUE for async
> operation
> > + * @param resultResults of operation (when posted returns
> FALSE)
> > + * @param num   Number of operations reuested
> > + *
> > + * @return Number of operations actually enqueued/completed (0 ... num)
> > + * @retval <0 on failure
> > + */
> > +int odp_crypto_operation_multi(odp_crypto_session_t session,
> > +  odp_crypto_op_params_t *params[],
> > +  odp_bool_t *posted,
> > +  odp_crypto_op_result_t *result[],
> > +  int num);
>
> This function will have a performance issue with synchronous crypto
> operations since in sync crypto odp_crypto_operation_multi() is a
> blocking call and the call will have to be blocked for all the packets
> to complete before posting the result. Also the crypto operations were
> kept agnostic of the internal behaviour of the implementation so help
> in portability of the applications.
>

This API will work with both synchronous and asynchronous modes. There may
be different recommendations from different implementations for
performance. All APIs may not perform equally on all implementations.
Moreover there will not be much difference in performance of this API
compared to calling odp_crypto_operation multiple times in a implementation
like linux generic.

>
> Regards,
> Bala
> > +
> >  /**
> >   * Crypto per packet operation query result from completion event
> >   *
> > --
> > 2.8.2
> >
> > ___
> > 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] [RFCv2 API-NEXT] Adding API for Multi crypto operation support.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index d8123e9..7b4424d 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -214,7 +214,6 @@ typedef struct odp_crypto_session_params {
  * @todo Clarify who zero's ICV and how this relates to "hash_result_offset"
  */
 typedef struct odp_crypto_op_params {
-   odp_crypto_session_t session;   /**< Session handle from creation */
void *ctx;  /**< User context */
odp_packet_t pkt;   /**< Input packet buffer */
odp_packet_t out_pkt;   /**< Output packet buffer */
@@ -406,6 +405,7 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
completion_event);
  * If "posted" returns TRUE the result will be delivered via the completion
  * queue specified when the session was created.
  *
+ * @param session   Session handle
  * @param paramsOperation parameters
  * @param postedPointer to return posted, TRUE for async operation
  * @param resultResults of operation (when posted returns FALSE)
@@ -413,10 +413,35 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
completion_event);
  * @retval 0 on success
  * @retval <0 on failure
  */
-int odp_crypto_operation(odp_crypto_op_params_t *params,
+int odp_crypto_operation(odp_crypto_session_t session,
+odp_crypto_op_params_t *params,
 odp_bool_t *posted,
 odp_crypto_op_result_t *result);
 
+
+/**
+ * Crypto packet burst operation
+ *
+ * Performs the cryptographic operations specified during session creation
+ * on the list of packets. Burst operation can only be performed 
asynchronously,
+ * and the result will be delivered via the completion queue specified when the
+ * session was created.
+ *
+ * @param session   Session handle
+ * @param paramsArray of Operation parameters
+ * @param postedPointer to return posted, TRUE for async operation
+ * @param resultResults of operation (when posted returns FALSE)
+ * @param num   Number of operations reuested
+ *
+ * @return Number of operations actually enqueued/completed (0 ... num)
+ * @retval <0 on failure
+ */
+int odp_crypto_operation_multi(odp_crypto_session_t session,
+  odp_crypto_op_params_t *params[],
+  odp_bool_t *posted,
+  odp_crypto_op_result_t *result[],
+  int num);
+
 /**
  * Crypto per packet operation query result from completion event
  *
-- 
2.8.2

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

[lng-odp] [RFC OPENSSL-ODP] Adding README file.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 README | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 README

diff --git a/README b/README
new file mode 100644
index 000..b13393a
--- /dev/null
+++ b/README
@@ -0,0 +1,21 @@
+Copyright (c) 2013-2014, Linaro Limited
+All rights reserved.
+
+SPDX-License-Identifier:BSD-3-Clause
+
+OpenDataPlane (ODP) project source code.
+http://www.opendataplane.org/
+
+How to build:
+Following are the steep to build this object:
+./bootstrap
+./configure --with-openssl-path= 
--with-odp-path=
+make
+
+How to run.
+Copy the shared object engine/.libs/libsslodp.so to "opnessl 
path"/lib/engines/.
+Execute any openssl application with arguments  "-engine libsslodp".
+
+Currently, we have tested openssl speed application with NXP platform.
+
+
-- 
2.8.2

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

[lng-odp] [RFC OPNESSL-ODP 2/2] Adding Async ODP engine for AES cipher

[Nikhil Agarwal]

---
 engine/eng_odp.c | 375 +++
 1 file changed, 375 insertions(+)
 create mode 100644 engine/eng_odp.c

diff --git a/engine/eng_odp.c b/engine/eng_odp.c
new file mode 100644
index 000..3340649
--- /dev/null
+++ b/engine/eng_odp.c
@@ -0,0 +1,375 @@
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DUMMY_CHAR 'X'
+odp_pool_t pool;
+int num_queue = 8;
+odp_queue_t out_queue[8];
+OSSL_ASYNC_FD pipefds[2] = {0, 0};
+
+/* Engine Id and Name */
+static const char *engine_odp_id = "libsslodp";
+static const char *engine_odp_name = "ODP based engine";
+
+/* Engine Lifetime functions */
+static int ossl_odp_destroy(ENGINE *e);
+static int ossl_odp_init(ENGINE *e);
+static int ossl_odp_finish(ENGINE *e);
+
+/* Set up digests. Just SHA1 for now */
+static int ossl_odp_digests(ENGINE *e, const EVP_MD **digest,
+   const int **nids, int nid);
+
+/*
+ * Holds the EVP_MD object for sha1 in this engine. Set up once only during
+ * engine bind and can then be reused many times.
+ */
+static void destroy_digests(void)
+{
+   /*Nothing for now*/
+}
+
+static int ossl_odp_digest_nids(const int **nids)
+{
+   int digest_nids[2] = { 0, 0 };
+
+   *nids = digest_nids;
+   return 1;
+}
+
+/* AES */
+
+static int ossl_odp_aes128_init_key(EVP_CIPHER_CTX *ctx,
+   const unsigned char *key, const unsigned char *iv, int enc);
+static int ossl_odp_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
+   const unsigned char *in, size_t inl);
+static int ossl_odp_aes128_cbc_cleanup(EVP_CIPHER_CTX *ctx);
+
+struct ossl_odp_ctx {
+   odp_crypto_session_t session;
+};
+
+/*
+ * Holds the EVP_CIPHER object for aes_128_cbc in this engine. Set up once only
+ * during engine bind and can then be reused many times.
+ */
+static EVP_CIPHER *_hidden_aes_128_cbc;
+static const EVP_CIPHER *ossl_odp_aes_128_cbc(void)
+{
+   return _hidden_aes_128_cbc;
+}
+
+static void destroy_ciphers(void)
+{
+   EVP_CIPHER_meth_free(_hidden_aes_128_cbc);
+   _hidden_aes_128_cbc = NULL;
+}
+
+static int ossl_odp_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
+   const int **nids, int nid);
+
+static int ossl_odp_cipher_nids[] = {
+   NID_aes_128_cbc,
+   0
+};
+
+static int bind_odp(ENGINE *e)
+{
+   if (!ENGINE_set_id(e, engine_odp_id)
+   || !ENGINE_set_name(e, engine_odp_name)
+   || !ENGINE_set_ciphers(e, ossl_odp_ciphers)
+   || !ENGINE_set_destroy_function(e, ossl_odp_destroy)
+   || !ENGINE_set_init_function(e, ossl_odp_init)
+   || !ENGINE_set_finish_function(e, ossl_odp_finish)) {
+   return 0;
+   }
+
+   _hidden_aes_128_cbc = EVP_CIPHER_meth_new(NID_aes_128_cbc,
+   16 /* block size */,
+   16 /* key len */);
+   if (_hidden_aes_128_cbc == NULL
+   || !EVP_CIPHER_meth_set_iv_length(_hidden_aes_128_cbc, 16)
+   || !EVP_CIPHER_meth_set_flags(_hidden_aes_128_cbc,
+   EVP_CIPH_FLAG_DEFAULT_ASN1
+   | EVP_CIPH_CBC_MODE)
+   || !EVP_CIPHER_meth_set_init(_hidden_aes_128_cbc,
+   ossl_odp_aes128_init_key)
+   || !EVP_CIPHER_meth_set_do_cipher(_hidden_aes_128_cbc,
+   ossl_odp_aes128_cbc_cipher)
+   || !EVP_CIPHER_meth_set_cleanup(_hidden_aes_128_cbc,
+   ossl_odp_aes128_cbc_cleanup)
+   || !EVP_CIPHER_meth_set_impl_ctx_size(_hidden_aes_128_cbc,
+   sizeof(struct ossl_odp_ctx))) {
+   EVP_CIPHER_meth_free(_hidden_aes_128_cbc);
+   _hidden_aes_128_cbc = NULL;
+   }
+   return 1;
+}
+
+static int bind_helper(ENGINE *e, const char *id)
+{
+   if (id && (strcmp(id, engine_odp_id) != 0))
+   return 0;
+   if (!bind_odp(e))
+   return 0;
+   return 1;
+}
+
+IMPLEMENT_DYNAMIC_CHECK_FN()
+IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)
+
+static int ossl_odp_init(ENGINE *e)
+{
+   odp_queue_param_t qparam;
+   odp_pool_param_t params;
+   int i;
+   char buf = DUMMY_CHAR;
+
+   if (0 != odp_init_global(NULL, NULL)) {
+   printf("error: odp_init_global() failed.\n");
+   return -1;
+   }
+   if (0 != odp_init_local(ODP_THREAD_WORKER)) {
+   printf("error: odp_init_local() failed.\n");
+   return -1;
+   }
+
+   memset(¶ms, 0, sizeof(params));
+   params.pkt.seg_len = 20480;
+   params.pkt.len = 20480;
+   params.pkt.num = 4096;
+   params.type = ODP_POOL_PACKET;
+
+   pool = odp_pool_create("packet_pool", ¶ms);
+
+   if (ODP_POOL_INVALID == pool) {
+   printf("Packet pool creation fai

[lng-odp] [RFC OPNESSL-ODP 1/2] Initial Commit for Makeflies and configure scripts.

[Nikhil Agarwal]

From: Nikhil Agarwal 

Added Directory structure. Makeflies and configure scripts.

Signed-off-by: Nikhil Agarwal 
---
 .gitignore |  25 ++
 Makefile.am|   2 +
 bootstrap  |   7 +++
 configure.ac   | 136 +
 engine/Makefile.am |   5 ++
 5 files changed, 175 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 Makefile.am
 create mode 100755 bootstrap
 create mode 100644 configure.ac
 create mode 100644 engine/Makefile.am

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..1f844a8
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,25 @@
+Makefile
+Makefile.in
+aclocal.m4
+ar-lib
+autom4te.cache/
+compile
+config.guess
+config.log
+config.status
+config.sub
+configure
+depcomp
+engine/.deps/
+engine/.libs/
+engine/Makefile
+engine/Makefile.in
+engine/eng_odp.lo
+engine/eng_odp.o
+engine/libsslodp.la
+install-sh
+libtool
+ltmain.sh
+m4/
+missing
+
diff --git a/Makefile.am b/Makefile.am
new file mode 100644
index 000..0536da9
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,2 @@
+ACLOCAL_AMFLAGS=-I m4
+SUBDIRS = engine
diff --git a/bootstrap b/bootstrap
new file mode 100755
index 000..ce37658
--- /dev/null
+++ b/bootstrap
@@ -0,0 +1,7 @@
+#! /bin/sh
+set -x
+#mkdir m4
+aclocal
+libtoolize --copy
+automake --add-missing --copy --warnings=all
+autoconf
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..19249c9
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,136 @@
+AC_PREREQ([2.5])
+AC_INIT([ossl-odp], [0.1], [lng-odp@lists.linaro.org])
+AM_INIT_AUTOMAKE([foreign])
+AC_CONFIG_SRCDIR([engine/eng_odp.c])
+
+AC_USE_SYSTEM_EXTENSIONS
+AC_SYS_LARGEFILE
+AC_CONFIG_MACRO_DIR([m4])
+AM_SILENT_RULES([yes])
+
+# Checks for programs.
+AC_PROG_CC
+AM_PROG_CC_C_O
+
+AC_PROG_CXX
+AC_PROG_INSTALL
+AC_PROG_MAKE_SET
+
+AM_PROG_AR
+#Use libtool
+LT_INIT([])
+AC_SUBST([LIBTOOL_DEPS])
+AM_PROG_LIBTOOL
+
+# Checks for library functions.
+AC_FUNC_MALLOC
+
+# Checks for typedefs, structures, and compiler characteristics.
+AC_HEADER_STDBOOL
+AC_C_INLINE
+AC_TYPE_SIZE_T
+AC_TYPE_SSIZE_T
+AC_TYPE_UINT8_T
+AC_TYPE_UINT16_T
+AC_TYPE_INT32_T
+AC_TYPE_UINT32_T
+AC_TYPE_UINT64_T
+
+##
+# Which architecture optimizations will we use
+##
+AS_CASE([$host],
+  [x86*], [ARCH=x86],
+  [mips64*], [ARCH=mips64],
+  [aarch64*], [ARCH=aarch64],
+  [powerpc*], [ARCH=powerpc],
+  [ARCH=linux]
+)
+AC_SUBST([ARCH])
+
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_CPPFLAGS=$CPPFLAGS
+LDFLAGS="$AM_LDFLAGS $LDFLAGS"
+CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+
+
+##
+# Default include setup
+##
+AM_CFLAGS="$AM_CFLAGS $ODP_CFLAGS"
+AM_CXXFLAGS="-std=c++11"
+
+
+
+##
+# Set optional OpenSSL path
+##
+AC_ARG_WITH([openssl-path],
+   AC_HELP_STRING([--with-openssl-path=DIR path to openssl libs and 
headers],
+   [(or in the default path if not specified).]),
+   [OPENSSL_PATH=$withval
+   AM_CPPFLAGS="$AM_CPPFLAGS -I$OPENSSL_PATH/include"
+   AM_LDFLAGS="$AM_LDFLAGS -L$OPENSSL_PATH/lib"
+   ],[])
+
+##
+# Set optional ODP path
+##
+AC_ARG_WITH([odp-path],
+   AC_HELP_STRING([--with-odp-path=DIR path to odp libs and headers],
+   [(or in the default path if not specified).]),
+   [ODP_PATH=$withval
+   AM_CPPFLAGS="$AM_CPPFLAGS -I$ODP_PATH/include"
+   AM_LDFLAGS="$AM_LDFLAGS -L$ODP_PATH/lib"
+   ],[])
+
+
+##
+# Save and set temporary compilation flags
+##
+OLD_LDFLAGS=$LDFLAGS
+OLD_CPPFLAGS=$CPPFLAGS
+LDFLAGS="$AM_LDFLAGS $LDFLAGS"
+CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+
+AC_CHECK_LIB([odp], [odp_init_global],[ODP_LIB=-lodp],
+   [AC_MSG_FAILURE([ODP library required])])
+
+
+AC_CONFIG_FILES([Makefile
+   engine/Makefile
+   ])
+
+AC_SUBST([ODP_PATH])
+AC_SUBST([ODP_LIB])
+AC_SUBST([OPENSSL_PATH])
+AC_SUBST([LIBS])
+AC_SUBST([AM_CPPFLAGS])
+AC_SUBST([CPPFLAGS])
+AC_SUBST([AM_CFLAGS])
+AC_SUBST([C

Re: [lng-odp] [RFC] Adding Multi variant for Async crypto operation.

[Nikhil Agarwal]

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Friday, June 03, 2016 2:32 PM
To: Nikhil Agarwal 
Cc: LNG ODP Mailman List 
Subject: Re: [lng-odp] [RFC] Adding Multi variant for Async crypto operation.

On 2 June 2016 at 20:37, Nikhil Agarwal  wrote:
> Signed-off-by: Nikhil Agarwal 
> ---
>  include/odp/api/spec/crypto.h | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/include/odp/api/spec/crypto.h 
> b/include/odp/api/spec/crypto.h index d8123e9..1c2b384 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -214,7 +214,6 @@ typedef struct odp_crypto_session_params {
>   * @todo Clarify who zero's ICV and how this relates to "hash_result_offset"
>   */
>  typedef struct odp_crypto_op_params {
> -   odp_crypto_session_t session;   /**< Session handle from creation */
> void *ctx;  /**< User context */
> odp_packet_t pkt;   /**< Input packet buffer */
> odp_packet_t out_pkt;   /**< Output packet buffer */
> @@ -406,6 +405,7 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
> completion_event);
>   * If "posted" returns TRUE the result will be delivered via the completion
>   * queue specified when the session was created.
>   *
> + * @param session   Session handle
>   * @param paramsOperation parameters
>   * @param postedPointer to return posted, TRUE for async 
> operation
>   * @param resultResults of operation (when posted returns FALSE)
> @@ -413,10 +413,31 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
> completion_event);
>   * @retval 0 on success
>   * @retval <0 on failure
>   */
> -int odp_crypto_operation(odp_crypto_op_params_t *params,
> +int odp_crypto_operation(odp_crypto_session_t session,
> +odp_crypto_op_params_t *params,
>  odp_bool_t *posted,
>  odp_crypto_op_result_t *result);

Since odp_crypto_session_t is already available inside crypto_op_params_t,  
What is the advantage of sending the session separately in this API?
[Nikhil]RFC proposes to remove session from crypto_op_params_t to have 
synchronization between single and multi variant of the API. Since multi should 
have all the packet belonging to same crypto sessions and rest all params may 
differ for all packets.

Regards,
Bala
>
> +
> +/**
> + * Crypto packet burst operation
> + *
> + * Performs the cryptographic operations specified during session 
> +creation
> + * on the list of packets. Burst operation can only be performed 
> +asynchronously,
> + * and the result will be delivered via the completion queue 
> +specified when the
> + * session was created.
> + *
> + * @param session   Session handle
> + * @param paramsOperation parameters
> + * @param num   Number of operations requested
> + *
> + * @return Number of operations actually enqueued (0 ... num)
> + * @retval <0 on failure
> + */
> +int odp_crypto_operation_multi(odp_crypto_session_t session,
> +  odp_crypto_op_params_t *params[],
> +  int num);
> +
>  /**
>   * Crypto per packet operation query result from completion event
>   *
> --
> 2.8.2
>
> ___
> 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

[lng-odp] [RFC] Adding Multi variant for Async crypto operation.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 include/odp/api/spec/crypto.h | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index d8123e9..1c2b384 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -214,7 +214,6 @@ typedef struct odp_crypto_session_params {
  * @todo Clarify who zero's ICV and how this relates to "hash_result_offset"
  */
 typedef struct odp_crypto_op_params {
-   odp_crypto_session_t session;   /**< Session handle from creation */
void *ctx;  /**< User context */
odp_packet_t pkt;   /**< Input packet buffer */
odp_packet_t out_pkt;   /**< Output packet buffer */
@@ -406,6 +405,7 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
completion_event);
  * If "posted" returns TRUE the result will be delivered via the completion
  * queue specified when the session was created.
  *
+ * @param session   Session handle
  * @param paramsOperation parameters
  * @param postedPointer to return posted, TRUE for async operation
  * @param resultResults of operation (when posted returns FALSE)
@@ -413,10 +413,31 @@ void odp_crypto_compl_free(odp_crypto_compl_t 
completion_event);
  * @retval 0 on success
  * @retval <0 on failure
  */
-int odp_crypto_operation(odp_crypto_op_params_t *params,
+int odp_crypto_operation(odp_crypto_session_t session,
+odp_crypto_op_params_t *params,
 odp_bool_t *posted,
 odp_crypto_op_result_t *result);
 
+
+/**
+ * Crypto packet burst operation
+ *
+ * Performs the cryptographic operations specified during session creation
+ * on the list of packets. Burst operation can only be performed 
asynchronously,
+ * and the result will be delivered via the completion queue specified when the
+ * session was created.
+ *
+ * @param session   Session handle
+ * @param paramsOperation parameters
+ * @param num   Number of operations requested
+ *
+ * @return Number of operations actually enqueued (0 ... num)
+ * @retval <0 on failure
+ */
+int odp_crypto_operation_multi(odp_crypto_session_t session,
+  odp_crypto_op_params_t *params[],
+  int num);
+
 /**
  * Crypto per packet operation query result from completion event
  *
-- 
2.8.2

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

[lng-odp] [PATCH v4] doc: user-guide: Improve crypto section.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 doc/users-guide/users-guide.adoc | 87 +++-
 1 file changed, 69 insertions(+), 18 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 0221634..b094802 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -909,24 +909,75 @@ include::users-guide-pktio.adoc[]
 
 == Cryptographic services
 
-ODP provides support for cryptographic operations required by various security
-protocols (e.g. IPSec). To apply a cryptographic operation to a packet a 
session
-must be created first. Packets processed by a session share the same 
cryptographic
-parameters like algorithms, keys, initialization vectors. A session is created 
with
-*odp_crypto_session_create()* call. After session creation a cryptographic 
operation
-can be applied to a packet using *odp_crypto_operation()* call.
-Depending on the session type - synchronous or asynchronous the operation 
returns
-when the operation completed or after the request has been submitted. In the
-asynchronous case an operation completion event will be enqueued on the session
-completion queue. The completion event conveys the status of the operation and
-the result. The application has the responsibility to free the completion 
event.
-The operation arguments specify for each packet the areas which are to be 
encrypted
-or decrypted and authenticated. Also, in asynchronous case a context can be
-associated with a given operation and when the operation completion event is
-retrieved the associated context can be retrieved. An operation can be executed
-in-place, when the output packet is the same as the input packet or the output
-packet can be a new packet provided by the application or allocated by the
-implementation from the session output pool.
+ODP provides APIs to perform cryptographic operations required by various
+communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing (HMAC)
+* Random number generation
+* Crypto capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and asynchronous crypto sessions. For asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+the completion queue in its session parameters.
+
+ODP crypto APIs support chained operation sessions in which hashing and 
ciphering
+both can be achieved using a single session and operation call. The order of
+cipher and hashing can be controlled by the `auth_cipher_text` session 
parameter.
+
+Other Session parameters include algorithms, keys, initialization vector
+(optional), encode or decode, output queue for async mode and output packet 
pool
+for allocation of an output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using the `odp_crypto_operation()` API. Applications may indicate a preference
+for synchronous or asynchronous processing in the session's `pref_mode` 
parameter.
+However crypto operations may complete synchronously even if an asynchronous
+preference is indicated, and applications must examine the `posted` output
+parameter from `odp_crypto_operation()` to determine whether the operation has
+completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the 
case
+of an async operation, the `posted` output parameter will be set to true.
+
+
+The operation arguments specify for each packet the areas that are to be
+encrypted or decrypted and authenticated. Also, there is an option of 
overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or new buffer mode.
+In in-place mode output packet is same as the input packet.
+In case of out-of-place mode output packet is different from input packet as
+specified by the application, while in new buffer mode implementation allocates
+a new output buffer from the session’s output pool.
+
+The application can also specify a context associated with a given operation 
that
+will be retained during async operation and can be retrieved via the completion
+event.
+
+Results of an asynchronous session will be posted as completion events to the
+session’s completion queue, which can be accessed directly or via the ODP
+scheduler. The completion event contains the status of the operation and the
+result. The application has the responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API `odp_random_data()` to generate random data bytes. It has
+an argument to specify whether to use system entropy source for random number
+generation or not.
+
+=== Capab

Re: [lng-odp] [PATCH] doc: user-guide: Improve Crypto section.

[Nikhil Agarwal]

I have those changes. Please check if i have missed anything.

On 12 May 2016 at 23:32, Bala Manoharan  wrote:

> Hi Nikhil,
>
> I had some comments on V1 regarding session type.
> If you agree can you please incorporate on next version.
>
> Regards,
> Bala
>
> On 12 May 2016 at 22:22, Nikhil Agarwal  wrote:
>
>> Yes I do agree with mentioning only the API names here. I did that in v2
>> of this patch.
>>
>> On 12 May 2016 at 22:14, Bill Fischofer 
>> wrote:
>>
>>>
>>> On Thu, May 12, 2016 at 11:25 AM, Mike Holmes 
>>> wrote:
>>>
>>>>
>>>>
>>>> On 11 May 2016 at 19:15, Bill Fischofer 
>>>> wrote:
>>>>
>>>>> A number of grammatical corrections and suggestions for improvement.
>>>>>
>>>>> On Wed, May 11, 2016 at 9:45 AM, Nikhil Agarwal <
>>>>> nikhil.agar...@linaro.org> wrote:
>>>>>
>>>>>> From: Nikhil Agarwal 
>>>>>>
>>>>>> Signed-off-by: Nikhil Agarwal 
>>>>>> ---
>>>>>>  doc/users-guide/users-guide.adoc | 81
>>>>>> +++-
>>>>>>  1 file changed, 63 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/doc/users-guide/users-guide.adoc
>>>>>> b/doc/users-guide/users-guide.adoc
>>>>>> index 0221634..b80ed8c 100644
>>>>>> --- a/doc/users-guide/users-guide.adoc
>>>>>> +++ b/doc/users-guide/users-guide.adoc
>>>>>> @@ -909,24 +909,69 @@ include::users-guide-pktio.adoc[]
>>>>>>
>>>>>>  == Cryptographic services
>>>>>>
>>>>>> -ODP provides support for cryptographic operations required by
>>>>>> various security
>>>>>> -protocols (e.g. IPSec). To apply a cryptographic operation to a
>>>>>> packet a session
>>>>>> -must be created first. Packets processed by a session share the same
>>>>>> cryptographic
>>>>>> -parameters like algorithms, keys, initialization vectors. A session
>>>>>> is created with
>>>>>> -*odp_crypto_session_create()* call. After session creation a
>>>>>> cryptographic operation
>>>>>> -can be applied to a packet using *odp_crypto_operation()* call.
>>>>>> -Depending on the session type - synchronous or asynchronous the
>>>>>> operation returns
>>>>>> -when the operation completed or after the request has been
>>>>>> submitted. In the
>>>>>> -asynchronous case an operation completion event will be enqueued on
>>>>>> the session
>>>>>> -completion queue. The completion event conveys the status of the
>>>>>> operation and
>>>>>> -the result. The application has the responsibility to free the
>>>>>> completion event.
>>>>>> -The operation arguments specify for each packet the areas which are
>>>>>> to be encrypted
>>>>>> -or decrypted and authenticated. Also, in asynchronous case a context
>>>>>> can be
>>>>>> -associated with a given operation and when the operation completion
>>>>>> event is
>>>>>> -retrieved the associated context can be retrieved. An operation can
>>>>>> be executed
>>>>>> -in-place, when the output packet is the same as the input packet or
>>>>>> the output
>>>>>> -packet can be a new packet provided by the application or allocated
>>>>>> by the
>>>>>> -implementation from the session output pool.
>>>>>> +ODP provides APIs to perform cryptographic operations required by
>>>>>> various
>>>>>> +communication Protocols (e.g. IPSec). ODP cryptographic APIs are
>>>>>> session based.
>>>>>> +
>>>>>> +ODP provides APIs for following cryptographic services:
>>>>>> +
>>>>>> +* Ciphering
>>>>>> +* Authentication/data integrity via Keyed-Hashing(HMAC)
>>>>>>
>>>>>
>>>>> Add space before (HMAC)
>>>>>
>>>>>
>>>>>> +* Random number generation
>>>>>> +* Crypto Capability inquiries
>>>>>> +
>>>>>> +=== Crypto

[lng-odp] [PATCH v3] doc: user-guide: Improve crypto section.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 doc/users-guide/users-guide.adoc | 84 +++-
 1 file changed, 66 insertions(+), 18 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 0221634..b3b919d 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -909,24 +909,72 @@ include::users-guide-pktio.adoc[]
 
 == Cryptographic services
 
-ODP provides support for cryptographic operations required by various security
-protocols (e.g. IPSec). To apply a cryptographic operation to a packet a 
session
-must be created first. Packets processed by a session share the same 
cryptographic
-parameters like algorithms, keys, initialization vectors. A session is created 
with
-*odp_crypto_session_create()* call. After session creation a cryptographic 
operation
-can be applied to a packet using *odp_crypto_operation()* call.
-Depending on the session type - synchronous or asynchronous the operation 
returns
-when the operation completed or after the request has been submitted. In the
-asynchronous case an operation completion event will be enqueued on the session
-completion queue. The completion event conveys the status of the operation and
-the result. The application has the responsibility to free the completion 
event.
-The operation arguments specify for each packet the areas which are to be 
encrypted
-or decrypted and authenticated. Also, in asynchronous case a context can be
-associated with a given operation and when the operation completion event is
-retrieved the associated context can be retrieved. An operation can be executed
-in-place, when the output packet is the same as the input packet or the output
-packet can be a new packet provided by the application or allocated by the
-implementation from the session output pool.
+ODP provides APIs to perform cryptographic operations required by various
+communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing (HMAC)
+* Random number generation
+* Crypto capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and asynchronous crypto sessions. For asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+completion queue in session parameters.
+
+ODP crypto APIs support chained operation sessions in which hashing and 
ciphering
+both can be achieved using single session and operation call. The order of 
cipher
+and hashing can be controlled by `auth_cipher_text` session parameter.
+
+Other Session parameters include algorithms, keys, initialization vector
+(optional), encode or decode, output queue for async mode and output packet 
pool
+for allocation of an output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using the `odp_crypto_operation()` API. Depending on the implementation
+(please note that implementation may perform the crypto operation in 
synchronous
+or asynchronous mode irrespective of preffered mode specified by application in
+`pref_mode` session param) the API returns when the operation is completed or
+after the request has been submitted. In the case of an async operation, the
+`*posted` (output variable of odp_crypto_operation API) will be set to true.
+
+The operation arguments specify for each packet the areas that are to be
+encrypted or decrypted and authenticated. Also, there is an option of 
overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or new buffer mode.
+In in-place mode output packet is same as the input packet.
+In case of out-of-place mode output packet is different from input packet as
+specified by the application, while in new buffer mode implementation allocates
+a new output buffer from the session’s output pool.
+
+User can also specify a context associated with a given operation that will be
+retained during async operation and can be retrieved via the completion event.
+
+Results of an asynchronous session will be posted as completion events to the
+session’s completion queue, which can be accessed directly or via ODP 
scheduler.
+The completion event contains the status of the operation and the result. The
+application has the responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API `odp_random_data()` to generate random data bytes. It has
+an argument to specify whether to use system entropy source for random number
+generation or not.
+
+=== Capability inquiries
+
+ODP provides an API interface `odp_crypto_capability()` to inquire 
implementation’s
+crypto capabilities

Re: [lng-odp] [PATCH] doc: user-guide: Improve Crypto section.

[Nikhil Agarwal]

Yes I do agree with mentioning only the API names here. I did that in v2 of
this patch.

On 12 May 2016 at 22:14, Bill Fischofer  wrote:

>
> On Thu, May 12, 2016 at 11:25 AM, Mike Holmes 
> wrote:
>
>>
>>
>> On 11 May 2016 at 19:15, Bill Fischofer 
>> wrote:
>>
>>> A number of grammatical corrections and suggestions for improvement.
>>>
>>> On Wed, May 11, 2016 at 9:45 AM, Nikhil Agarwal <
>>> nikhil.agar...@linaro.org> wrote:
>>>
>>>> From: Nikhil Agarwal 
>>>>
>>>> Signed-off-by: Nikhil Agarwal 
>>>> ---
>>>>  doc/users-guide/users-guide.adoc | 81
>>>> +++-
>>>>  1 file changed, 63 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/doc/users-guide/users-guide.adoc
>>>> b/doc/users-guide/users-guide.adoc
>>>> index 0221634..b80ed8c 100644
>>>> --- a/doc/users-guide/users-guide.adoc
>>>> +++ b/doc/users-guide/users-guide.adoc
>>>> @@ -909,24 +909,69 @@ include::users-guide-pktio.adoc[]
>>>>
>>>>  == Cryptographic services
>>>>
>>>> -ODP provides support for cryptographic operations required by various
>>>> security
>>>> -protocols (e.g. IPSec). To apply a cryptographic operation to a packet
>>>> a session
>>>> -must be created first. Packets processed by a session share the same
>>>> cryptographic
>>>> -parameters like algorithms, keys, initialization vectors. A session is
>>>> created with
>>>> -*odp_crypto_session_create()* call. After session creation a
>>>> cryptographic operation
>>>> -can be applied to a packet using *odp_crypto_operation()* call.
>>>> -Depending on the session type - synchronous or asynchronous the
>>>> operation returns
>>>> -when the operation completed or after the request has been submitted.
>>>> In the
>>>> -asynchronous case an operation completion event will be enqueued on
>>>> the session
>>>> -completion queue. The completion event conveys the status of the
>>>> operation and
>>>> -the result. The application has the responsibility to free the
>>>> completion event.
>>>> -The operation arguments specify for each packet the areas which are to
>>>> be encrypted
>>>> -or decrypted and authenticated. Also, in asynchronous case a context
>>>> can be
>>>> -associated with a given operation and when the operation completion
>>>> event is
>>>> -retrieved the associated context can be retrieved. An operation can be
>>>> executed
>>>> -in-place, when the output packet is the same as the input packet or
>>>> the output
>>>> -packet can be a new packet provided by the application or allocated by
>>>> the
>>>> -implementation from the session output pool.
>>>> +ODP provides APIs to perform cryptographic operations required by
>>>> various
>>>> +communication Protocols (e.g. IPSec). ODP cryptographic APIs are
>>>> session based.
>>>> +
>>>> +ODP provides APIs for following cryptographic services:
>>>> +
>>>> +* Ciphering
>>>> +* Authentication/data integrity via Keyed-Hashing(HMAC)
>>>>
>>>
>>> Add space before (HMAC)
>>>
>>>
>>>> +* Random number generation
>>>> +* Crypto Capability inquiries
>>>> +
>>>> +=== Crypto Sessions
>>>> +
>>>> +To apply a cryptographic operation to a packet a session must be
>>>> created. All
>>>> +packets processed by a session share the parameters that define the
>>>> session.
>>>> +
>>>> +ODP supports synchronous and Asynchronous crypto sessions. For
>>>> Asynchronous
>>>>
>>>
>>> No need to capitalize asynchronous here
>>>
>>>
>>>> +sessions, the output of crypto operation is posted in a queue defined
>>>> as
>>>> +completion queue in session parameters.
>>>> +
>>>> +ODP crypto APIs support chained operation sessions in which Hashing
>>>> and ciphering
>>>>
>>>
>>> hashing (no caps)
>>>
>>>
>>>> +both can be achieved using single session and single operation call.
>>>> Order of
>>>>
>>>
>>> using a single sess

[lng-odp] [PATCH v2] doc: user-guide: Improve crypto section.

[Nikhil Agarwal]

Signed-off-by: Nikhil Agarwal 
---
 doc/users-guide/users-guide.adoc | 83 +++-
 1 file changed, 65 insertions(+), 18 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 0221634..e8d690e 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -909,24 +909,71 @@ include::users-guide-pktio.adoc[]
 
 == Cryptographic services
 
-ODP provides support for cryptographic operations required by various security
-protocols (e.g. IPSec). To apply a cryptographic operation to a packet a 
session
-must be created first. Packets processed by a session share the same 
cryptographic
-parameters like algorithms, keys, initialization vectors. A session is created 
with
-*odp_crypto_session_create()* call. After session creation a cryptographic 
operation
-can be applied to a packet using *odp_crypto_operation()* call.
-Depending on the session type - synchronous or asynchronous the operation 
returns
-when the operation completed or after the request has been submitted. In the
-asynchronous case an operation completion event will be enqueued on the session
-completion queue. The completion event conveys the status of the operation and
-the result. The application has the responsibility to free the completion 
event.
-The operation arguments specify for each packet the areas which are to be 
encrypted
-or decrypted and authenticated. Also, in asynchronous case a context can be
-associated with a given operation and when the operation completion event is
-retrieved the associated context can be retrieved. An operation can be executed
-in-place, when the output packet is the same as the input packet or the output
-packet can be a new packet provided by the application or allocated by the
-implementation from the session output pool.
+ODP provides APIs to perform cryptographic operations required by various
+communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing (HMAC)
+* Random number generation
+* Crypto capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and asynchronous crypto sessions. For asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+completion queue in session parameters.
+
+ODP crypto APIs support chained operation sessions in which hashing and 
ciphering
+both can be achieved using single session and operation call. The order of 
cipher
+and hashing can be controlled by `auth_cipher_text` session parameter.
+
+Other Session parameters include algorithms, keys, initialization vector
+(optional), encode or decode, output queue for async mode and output packet 
pool
+for allocation of an output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using the `odp_crypto_operation()` API. Depending on the implementation
+(synchronous or asynchronous) the API returns when the operation is completed
+or after the request has been submitted.
+
+The operation arguments specify for each packet the areas that are to be
+encrypted or decrypted and authenticated. Also, there is an option of 
overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or new buffer mode.
+In in-place mode output packet is same as the input packet.
+In case of out-of-place mode output packet is different from input packet as
+specified by the application, while in new buffer mode implementation allocates
+a new output buffer from the session’s output pool.
+
+User can also specify a context associated with a given operation that will be
+retained during async operation and can be retrieved via the completion event.
+
+In the case of an async session, the `*posted` (output variable of
+odp_crypto_operation API) will be set to true. Results of an asynchronous
+session will be posted as completion events to the session’s completion queue,
+which can be accessed directly or via ODP scheduler. The completion event
+contains the status of the operation and the result. The application has the
+responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API `odp_random_data` to generate random data bytes. It has
+an argument to specify whether to use system entropy source for random number
+generation or not.
+
+=== Capability inquiries
+
+ODP provides an API interface `odp_crypto_capability` to inquire 
implementation’s
+crypto capabilities. This interface returns a bitmask for supported algorithms
+and hardware backed algorithms.
 
 include::users-guide-tm.adoc[]
 
-- 
2.8.2

[lng-odp] [PATCH] doc: user-guide: Improve Crypto section.

[Nikhil Agarwal]

From: Nikhil Agarwal 

Signed-off-by: Nikhil Agarwal 
---
 doc/users-guide/users-guide.adoc | 81 +++-
 1 file changed, 63 insertions(+), 18 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 0221634..b80ed8c 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -909,24 +909,69 @@ include::users-guide-pktio.adoc[]
 
 == Cryptographic services
 
-ODP provides support for cryptographic operations required by various security
-protocols (e.g. IPSec). To apply a cryptographic operation to a packet a 
session
-must be created first. Packets processed by a session share the same 
cryptographic
-parameters like algorithms, keys, initialization vectors. A session is created 
with
-*odp_crypto_session_create()* call. After session creation a cryptographic 
operation
-can be applied to a packet using *odp_crypto_operation()* call.
-Depending on the session type - synchronous or asynchronous the operation 
returns
-when the operation completed or after the request has been submitted. In the
-asynchronous case an operation completion event will be enqueued on the session
-completion queue. The completion event conveys the status of the operation and
-the result. The application has the responsibility to free the completion 
event.
-The operation arguments specify for each packet the areas which are to be 
encrypted
-or decrypted and authenticated. Also, in asynchronous case a context can be
-associated with a given operation and when the operation completion event is
-retrieved the associated context can be retrieved. An operation can be executed
-in-place, when the output packet is the same as the input packet or the output
-packet can be a new packet provided by the application or allocated by the
-implementation from the session output pool.
+ODP provides APIs to perform cryptographic operations required by various
+communication Protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing(HMAC)
+* Random number generation
+* Crypto Capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and Asynchronous crypto sessions. For Asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+completion queue in session parameters.
+
+ODP crypto APIs support chained operation sessions in which Hashing and 
ciphering
+both can be achieved using single session and single operation call. Order of
+cipher and Hashing can be controlled by `auth_cipher_text` session parameter.
+
+Other Session parameters include algorithms, keys, Initialization vector
+(optional), encode or decode, output queue for async mode and output packet 
pool
+for allocation of output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using *odp_crypto_operation()* call. Depending on the session type - 
synchronous
+or asynchronous the API returns when the operation is completed or after the
+request has been submitted.
+
+The operation arguments specify for each packet the areas which are to be
+encrypted or decrypted and authenticated. Also, there is an option of 
overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or New buffer mode.
+In in-place mode output packet is same as input packet. In case of out-of-place
+mode output packet is different from input packet as specified by the 
application
+while in new buffer mode, implementation allocates a new output buffer from
+session’s output pool.
+
+User can also specify a context associated with a given operation which will be
+retained during async operation and can be retrieved via completion event.
+
+In case of async session `*posted` (output variable of odp_crypto_operation 
API)
+will be set to true. Results of asynchronous session will be posted as 
completion
+events to session’s completion queues which can be accessed directly or via 
ODP
+scheduler. The completion event contains the status of the operation and the
+result. The application has the responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API to generate random data bytes. It has argument to specify
+whether to use system entropy source for random number generation or not.
+
+=== Capability inquiries
+
+ODP provides an interface to inquire implementation’s crypto capabilities.
+This interface returns a bitmask for supported algorithms and hardware backed
+algorithms.
 
 include::users-guide-tm.adoc[]
 
-- 
2.7.0

___
lng-odp mailing list
lng-odp

Re: [lng-odp] Crypto_operation_multi API?

[Nikhil Agarwal]

One use case that will benefit from it will be fat ipsec tunnel use case,
where majority of packets coming from one pktio interface belongs to same
sessions. In general, it can be used in case where we are doing batch
processing using burst rx/tx apis(odp_pktio_recv/tx with more than one
packet)  and multiple packet needs crypto operations.

I dont have API changes as of now, but that can be proposed if people agree.

Regards
Nikhil

On 10 May 2016 at 21:03, Bala Manoharan  wrote:

> Do you have any specific changes or additions to crypto API? or any
> specific use-case which might benefit from the additional API?
>
> Regards,
> Bala
>
> On 10 May 2016 at 20:50, Nikhil Agarwal  wrote:
>
>> Hi All,
>>
>> Since we have multi flavor for packet Rx/Tx APIs on queues and scheduler,
>> shall we have have a similar API  for crypto operation? It might save
>> significant CPU cycles for implementation having hardware engines. Any
>> thoughts?
>>
>> Regards
>> Nikhil
>>
>> ___
>> 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] Crypto_operation_multi API?

[Nikhil Agarwal]

Hi All,

Since we have multi flavor for packet Rx/Tx APIs on queues and scheduler,
shall we have have a similar API  for crypto operation? It might save
significant CPU cycles for implementation having hardware engines. Any
thoughts?

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

Re: [lng-odp] [PATCH] example/ipsec: crash with invalid route parameters

[Nikhil Agarwal]

Reviewed-by: nikhil.agar...@linaro.org



> -- Forwarded message --
> From: 
> Date: Thu, Apr 21, 2016 at 12:33 PM
> Subject: [lng-odp] [PATCH] example/ipsec: crash with invalid route
> parameters
> To: lng-odp@lists.linaro.org
>
>
> From: Akhil Goyal 
>
> If invalid interface is passed in route config parameters,
> then the application crashes.
> So Matching the entered interface with the parameters configured
> in -i parameters.
>
> Signed-off-by: Akhil Goyal 
> ---
>  example/ipsec/odp_ipsec.c|  3 ++-
>  example/ipsec/odp_ipsec_fwd_db.c | 15 +--
>  example/ipsec/odp_ipsec_fwd_db.h |  6 +-
>  3 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index 79c6022..74c99b0 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -1450,7 +1450,8 @@ static void parse_args(int argc, char *argv[],
> appl_args_t *appl_args)
> break;
>
> case 'r':
> -   rc = create_fwd_db_entry(optarg);
> +   rc = create_fwd_db_entry(optarg,
> appl_args->if_names,
> +appl_args->if_count);
> break;
>
> case 'p':
> diff --git a/example/ipsec/odp_ipsec_fwd_db.c
> b/example/ipsec/odp_ipsec_fwd_db.c
> index 7b0bc08..e1f6384 100644
> --- a/example/ipsec/odp_ipsec_fwd_db.c
> +++ b/example/ipsec/odp_ipsec_fwd_db.c
> @@ -39,9 +39,9 @@ void init_fwd_db(void)
> memset(fwd_db, 0, sizeof(*fwd_db));
>  }
>
> -int create_fwd_db_entry(char *input)
> +int create_fwd_db_entry(char *input, char **if_names, int if_count)
>  {
> -   int pos = 0;
> +   int pos = 0, i, match = 0;
> char *local;
> char *str;
> char *save;
> @@ -76,6 +76,17 @@ int create_fwd_db_entry(char *input)
> case 1:
> strncpy(entry->oif, token, OIF_LEN - 1);
> entry->oif[OIF_LEN - 1] = 0;
> +   for (i = 0; i < if_count; i++) {
> +   if (!strcmp(if_names[i], entry->oif)) {
> +   match = 1;
> +   break;
> +   }
> +   }
> +   if (!match) {
> +   printf("ERROR: interface name not correct
> for route\n");
> +   free(local);
> +   return -1;
> +   }
> break;
> case 2:
> parse_mac_string(token, entry->dst_mac);
> diff --git a/example/ipsec/odp_ipsec_fwd_db.h
> b/example/ipsec/odp_ipsec_fwd_db.h
> index 094253e..748ae04 100644
> --- a/example/ipsec/odp_ipsec_fwd_db.h
> +++ b/example/ipsec/odp_ipsec_fwd_db.h
> @@ -51,9 +51,13 @@ void init_fwd_db(void);
>   *
>   * @param input  Pointer to string describing route
>   *
> + * @param if_names  Array of Name of the interfaces available
> + *
> + * @param if_count  number of interfaces in if_names array
> + *
>   * @return 0 if successful else -1
>   */
> -int create_fwd_db_entry(char *input);
> +int create_fwd_db_entry(char *input, char **if_names, int if_count);
>
>  /**
>   * Scan FWD DB entries and resolve output queue and source MAC address
> --
> 2.7.0
>
> ___
> 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] example/ipsec: crash with invalid route parameters

[Nikhil Agarwal]

A good fix to avoid crash in wrong/error configuration. Patch seems OK.

Regards

Nikhil Agarwal



> -- Forwarded message --
> From: 
> Date: Thu, Apr 21, 2016 at 12:33 PM
> Subject: [lng-odp] [PATCH] example/ipsec: crash with invalid route
> parameters
> To: lng-odp@lists.linaro.org
>
>
> From: Akhil Goyal 
>
> If invalid interface is passed in route config parameters,
> then the application crashes.
> So Matching the entered interface with the parameters configured
> in -i parameters.
>
> Signed-off-by: Akhil Goyal 
> ---
>  example/ipsec/odp_ipsec.c|  3 ++-
>  example/ipsec/odp_ipsec_fwd_db.c | 15 +--
>  example/ipsec/odp_ipsec_fwd_db.h |  6 +-
>  3 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index 79c6022..74c99b0 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -1450,7 +1450,8 @@ static void parse_args(int argc, char *argv[],
> appl_args_t *appl_args)
> break;
>
> case 'r':
> -   rc = create_fwd_db_entry(optarg);
> +   rc = create_fwd_db_entry(optarg,
> appl_args->if_names,
> +appl_args->if_count);
> break;
>
> case 'p':
> diff --git a/example/ipsec/odp_ipsec_fwd_db.c
> b/example/ipsec/odp_ipsec_fwd_db.c
> index 7b0bc08..e1f6384 100644
> --- a/example/ipsec/odp_ipsec_fwd_db.c
> +++ b/example/ipsec/odp_ipsec_fwd_db.c
> @@ -39,9 +39,9 @@ void init_fwd_db(void)
> memset(fwd_db, 0, sizeof(*fwd_db));
>  }
>
> -int create_fwd_db_entry(char *input)
> +int create_fwd_db_entry(char *input, char **if_names, int if_count)
>  {
> -   int pos = 0;
> +   int pos = 0, i, match = 0;
> char *local;
> char *str;
> char *save;
> @@ -76,6 +76,17 @@ int create_fwd_db_entry(char *input)
> case 1:
> strncpy(entry->oif, token, OIF_LEN - 1);
> entry->oif[OIF_LEN - 1] = 0;
> +   for (i = 0; i < if_count; i++) {
> +   if (!strcmp(if_names[i], entry->oif)) {
> +   match = 1;
> +   break;
> +   }
> +   }
> +   if (!match) {
> +   printf("ERROR: interface name not correct
> for route\n");
> +   free(local);
> +   return -1;
> +   }
> break;
> case 2:
> parse_mac_string(token, entry->dst_mac);
> diff --git a/example/ipsec/odp_ipsec_fwd_db.h
> b/example/ipsec/odp_ipsec_fwd_db.h
> index 094253e..748ae04 100644
> --- a/example/ipsec/odp_ipsec_fwd_db.h
> +++ b/example/ipsec/odp_ipsec_fwd_db.h
> @@ -51,9 +51,13 @@ void init_fwd_db(void);
>   *
>   * @param input  Pointer to string describing route
>   *
> + * @param if_names  Array of Name of the interfaces available
> + *
> + * @param if_count  number of interfaces in if_names array
> + *
>   * @return 0 if successful else -1
>   */
> -int create_fwd_db_entry(char *input);
> +int create_fwd_db_entry(char *input, char **if_names, int if_count);
>
>  /**
>   * Scan FWD DB entries and resolve output queue and source MAC address
> --
> 2.7.0
>
> ___
> 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] Query regarding odp_schedule

[Nikhil Agarwal]

Hi all,

I had a query regarding API ODP_schedule. This API has a parameter wait, to 
specify time to wait for an event. Why this API is designed in such a way that 
we need to convert the time using API odp_schedule_wait_time, and then pass it 
to this API. Shouldn't it be  passing the input time here itself and do all 
required conversion internally?

Please comment.

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

Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add odp_crypto_capability() api

[Nikhil Agarwal]

Shall supported algos be add in crypto capabilities?

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Thursday, February 18, 2016 10:40 AM
To: Bill Fischofer 
Cc: LNG ODP Mailman List 
Subject: Re: [lng-odp] [API-NEXT PATCH 1/4] api: crypto: add 
odp_crypto_capability() api

For the series:
Reviewed-by: Balasubramanian Manoharan 
mailto:bala.manoha...@linaro.org>>

Regards,
Bala

On 18 February 2016 at 01:07, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
Signed-off-by: Bill Fischofer 
mailto:bill.fischo...@linaro.org>>
---
 include/odp/api/spec/crypto.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index 41beedb..eaacff1 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -254,6 +254,24 @@ typedef struct odp_crypto_op_result {
 } odp_crypto_op_result_t;

 /**
+ * Crypto capabilities
+ */
+typedef struct odp_crypto_capability_t {
+   /** Maximum number of sessions */
+   unsigned max_sessions;
+} odp_crypto_capability_t;
+
+/**
+ * Get crypto capabilities
+ *
+ * @param[out] capability Pointer to capability structrue for output
+ *
+ * @retval 0 on success
+ * @retval <0 on failure
+ */
+int odp_crypto_capability(odp_crypto_capability_t *capability);
+
+/**
  * Crypto session creation (synchronous)
  *
  * @param paramsSession parameters
--
2.5.0

___
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] crypto contexts

[Nikhil Agarwal]

Othe option is instead of taking key and session as input, it is better to add 
an API odp_crypto_op_xxx which takes all input needed (Algos/Keys/buffer as 
input) and perform the single crypto operation without any session.

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Thursday, February 18, 2016 3:25 PM
To: Gábor Sándor Enyedi 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] crypto contexts


On 18 February 2016 at 13:58, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
OK, so back to the original question: I have up to ~100K users (but always 
higher than 32 by orders of magnitude) all with its own crypto key. In worst 
case, all of them are sending packets at the same time, so I need to decrypt a 
lot of packets from other users, before I face a packet from the same user 
again, so I cannot have 'n' different sessions. Since I cannot change the 
crypto key, the only way to do this is creating and destroying a session per 
packet. I looked into the x86 code, and it seemed that the code was 
intentionally written in a way that session create/destroy is relatively quick, 
since there is no malloc and free and crypto contexts are not destroyed at all.

I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that creating/destroying crypto 
session is fast, i.e. I can expect that this is a cheap operation on each 
platform.
2. This is just a bug in API, and should be fixed by adding some way to change 
the crypto key.
3. There is already some solution, which I don't know... E.g. the 
cipher_key.data field in the session is just a pointer, one possibility is 
changing the memory content at the address where it points to. :)

Please confirm that #1 is the correct answer.

Gabor


Unfortunately the method in which crypto session is created/destroyed is 
implementation specific it might be faster but I personally wouldn't bet on 
this. Since as discussed earlier the idea of crypto session is only to reuse 
the parameters during odp_cryto_operation() function for better performance so 
crypto session create/destroy might not be upto the mark required in a fast 
path execution.

IMO there is two possible ways to address your use-case,
1. add override_cipher_key and override_auth_key parameters to 
odp_crypto_op_params_t  struct which is an input to odp_cryto_operations() 
function so that if these value is a not-null then the implementation will 
override the values in crypto session but the drawback of this approach is that 
then for general use-case where the cipher/auth key is same per session the 
implementation will always have to check the 
override_cipher_key/override_auth_key parameter which actually is just a simple 
check but since this code runs in fast path and it is per packet might impact 
the performance.

2. A more preferable approach in my point of view is to add a new API 
odp_crypto_operation_key() where cipher key and auth key are given as input 
parameter along with session so that the applications which need to pass 
individual cipher/auth key per user can use this new API so that the 
performance of  odp_crypto_operation() is not changed.

your suggestions/ comments are most welcome and I will send an RFC based on 
option 2 for further discussion and you can provide your comments on the same.

Regards,
Bala



On 02/17/2016 05:56 PM, Bala Manoharan wrote:
Hi,

Crypto key in crypto session cannot be changed and in this case you need 'n' 
different crypto sessions only and it cannot be reused.

Regards,
Bala
On 17 February 2016 at 21:11, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
How can you change the crypto key? Each user has its own.

Gabor

On 02/17/2016 12:13 PM, Bala Manoharan wrote:
Hi,

There is no need to create a crypto session for each packet. The application 
needs to create a crypto session for a unique cipher/auth key (ie all the 
parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can create a crypto session and 
reuse it for packets which need similar processing.  The parameters of crypto 
session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text;   /**< Authenticate/cipher ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
odp_crypto_key_t cipher_key;   /**< Cipher key */
odp_crypto_iv_t  iv;   /**< Cipher Initialization Vector 
(IV) */
odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue;   /**< Async mode completion event 
queue */
odp_pool_t output_pool;/**< Output buffer po

Re: [lng-odp] crypto contexts

[Nikhil Agarwal]

Hi,

It seems none of your statement is true.  Comments inline.
It is platform implementation specific that how many crypto sessions it 
supports. If it does not support required number of sessions, then only way out 
as of today is to create n destroy session.

Bala,

If this is a generic use-case, shall a  light weight modify session API be 
considered to be added, as 100K session might be costly to maintain, provided 
they are used only once in a long run?

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Gábor 
Sándor Enyedi
Sent: Thursday, February 18, 2016 1:58 PM
To: Bala Manoharan 
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] crypto contexts

OK, so back to the original question: I have up to ~100K users (but always 
higher than 32 by orders of magnitude) all with its own crypto key. In worst 
case, all of them are sending packets at the same time, so I need to decrypt a 
lot of packets from other users, before I face a packet from the same user 
again, so I cannot have 'n' different sessions. Since I cannot change the 
crypto key, the only way to do this is creating and destroying a session per 
packet. I looked into the x86 code, and it seemed that the code was 
intentionally written in a way that session create/destroy is relatively quick, 
since there is no malloc and free and crypto contexts are not destroyed at all.

I think, there are three possibilities at this point:
1. ODP was intentionally designed in the way that creating/destroying crypto 
session is fast, i.e. I can expect that this is a cheap operation on each 
platform.
[Nikhil] This is implementation specific, and cannot be guaranteed to be fast 
on each platform.(As this is supposed to be one time API per session)
2. This is just a bug in API, and should be fixed by adding some way to change 
the crypto key.
[Nikhil] You cannot change crypto key for a session.
3. There is already some solution, which I don't know... E.g. the 
cipher_key.data field in the session is just a pointer, one possibility is 
changing the memory content at the address where it points to. :)
[Nikhil] There is no way as of today that you can modify crypto keys of a 
session.


Please confirm that #1 is the correct answer.

Gabor

On 02/17/2016 05:56 PM, Bala Manoharan wrote:
Hi,

Crypto key in crypto session cannot be changed and in this case you need 'n' 
different crypto sessions only and it cannot be reused.

Regards,
Bala
On 17 February 2016 at 21:11, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
How can you change the crypto key? Each user has its own.

Gabor

On 02/17/2016 12:13 PM, Bala Manoharan wrote:
Hi,

There is no need to create a crypto session for each packet. The application 
needs to create a crypto session for a unique cipher/auth key (ie all the 
parameters in odp_crypto_session_params_t ).
A crypto session is created so that application can create a crypto session and 
reuse it for packets which need similar processing.  The parameters of crypto 
session are as follows

typedef struct odp_crypto_session_params {
odp_crypto_op_t op;/**< Encode versus decode */
odp_bool_t auth_cipher_text;   /**< Authenticate/cipher ordering */
odp_crypto_op_mode_t pref_mode;/**< Preferred sync vs async */
odp_cipher_alg_t cipher_alg;   /**< Cipher algorithm */
odp_crypto_key_t cipher_key;   /**< Cipher key */
odp_crypto_iv_t  iv;   /**< Cipher Initialization Vector 
(IV) */
odp_auth_alg_t auth_alg;   /**< Authentication algorithm */
odp_crypto_key_t auth_key; /**< Authentication key */
odp_queue_t compl_queue;   /**< Async mode completion event 
queue */
odp_pool_t output_pool;/**< Output buffer pool */
} odp_crypto_session_params_t

If you see the odp_crypto_operation() function it reuses an existing crypto 
session and only provides parameters which are unique per packet (ie 
cipher/auth range, input packet, etc )

The limit of 32 crypto sessions is a limitation on the linux-generic 
implementation and this value might depend on individual platforms.

Regards,
Bala

On 16 February 2016 at 18:40, Gábor Sándor Enyedi 
mailto:gabor.sandor.eny...@ericsson.com>> 
wrote:
Hi,

I want to keep up IPSec connections with up to ~100K users simultaneously. 
After looking into the code, it seems that both linux-generic and odp-dpdk can 
allocate at most 32 crypto sessions (with odp_crypto_session_create). Please 
confirm, that this is not a bug, but crypto sessions are considered to be a 
very limited resource and an ODP application should create and destroy a crypto 
session for each packet, when all the users are sending traffic at the same 
time.
Thanks,

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




__

[lng-odp] ODP IPSEC example application optimizations

[Nikhil Agarwal]

Hi All,

Currently ODP IPSEC example application deploys ESP header for encryption and 
AH header for Authentication. This is not most widely use case scenario for 
IPSEC.  AH is known to have issue in NAT environment.

Majority of deployment in IPSEC is being done with Encryption and 
Authentication under ESP Header only. I was trying to change the ODP example 
application to cater to this use case. If this is  acceptable to the community 
I can share the patch for the same. Please comment.

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

Re: [lng-odp] [PATCH] example:ipsec: Using environment varibale for pktio mode.

[Agarwal Nikhil Agarwal]

Ping.

-Original Message-
From: nikhil.agar...@freescale.com [mailto:nikhil.agar...@freescale.com] 
Sent: Wednesday, October 07, 2015 3:54 PM
To: lng-odp@lists.linaro.org
Cc: Agarwal Nikhil-B38457 
Subject: [PATCH] example:ipsec: Using environment varibale for pktio mode.

From: Nikhil Agarwal 

Pktio input mode of operation should be derived from environment variable input 
instead of compile time flag.

Signed-off-by: Nikhil Agarwal 
---
 example/ipsec/odp_ipsec.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c index 
96effe2..bc1d00e 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -515,11 +515,10 @@ void initialize_intf(char *intf)
 
memset(&pktio_param, 0, sizeof(pktio_param));
 
-#ifdef IPSEC_POLL_QUEUES
-   pktio_param.in_mode = ODP_PKTIN_MODE_POLL;
-#else
-   pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
-#endif
+   if (getenv("ODP_IPSEC_USE_POLL_QUEUES"))
+   pktio_param.in_mode = ODP_PKTIN_MODE_POLL;
+   else
+   pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
 
/*
 * Open a packet IO instance for thread and get default output queue
--
2.5.0

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

[lng-odp] FW: [PATCH] example:packet: Add pktio start in burst Mode.

[Agarwal Nikhil Agarwal]

Ping.

> -Original Message-
> From: nikhil.agar...@freescale.com [mailto:nikhil.agar...@freescale.com]
> Sent: Wednesday, September 30, 2015 12:23 PM
> To: lng-odp@lists.linaro.org
> Cc: Agarwal Nikhil-B38457
> Subject: [PATCH] example:packet: Add pktio start in burst Mode.
> 
> From: Nikhil Agarwal 
> 
> default state of pktio interface after odp_pktio_open is disabled. Need
> to enable the interface befaore using it.
> Seems like it has been missed for burst mode.
> 
> Signed-off-by: Nikhil Agarwal 
> ---
>  example/packet/odp_pktio.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
> index df53ea2..16d4533 100644
> --- a/example/packet/odp_pktio.c
> +++ b/example/packet/odp_pktio.c
> @@ -146,6 +146,9 @@ static odp_pktio_t create_pktio(const char *dev,
> odp_pool_t pool, int mode)
>   switch (mode) {
>   case  APPL_MODE_PKT_BURST:
>   /* no further setup needed for burst mode */
> + ret = odp_pktio_start(pktio);
> + if (ret != 0)
> + EXAMPLE_ABORT("Error: unable to start %s\n", dev);
>   return pktio;
>   case APPL_MODE_PKT_QUEUE:
>   inq_def = odp_queue_create(inq_name,
> --
> 2.5.0

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

Re: [lng-odp] [PATCH] example:ipsec: Fix for Polled queues

[Agarwal Nikhil Agarwal]

That sounds better, but it can be taken as an enhancement work for the 
application.
This patch I have submitted was for the broken functionality in the current 
release.

Regards
Nikhil

> -Original Message-
> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Monday, July 20, 2015 8:20 PM
> To: Agarwal Nikhil-B38457; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH] example:ipsec: Fix for Polled queues
> 
> On 07/20/15 16:07, Agarwal Nikhil Agarwal wrote:
> > Hi Maxim,
> >
> > Thanks for your comment.
> >
> > In case of ODP IPSEC application, queue_create is an function pointer
> assigned with odp_queue_create in schedule mode and
> polled_odp_queue_create in poll mode of operation. So we cannot remove
> last argument from polled_odp_queue_create otherwise its prototype will
> differ from odp_queue_create api and we will not be able to use common
> function pointer for both modes.
> >
> > Regards
> > Nikhil
> 
> Ah, ok. How about drop that function pointer? I.e. add option to
> parse_args() if it's polled or not. Then put 2 different queue creation
> to internal queue_create(). I think that getenv() can be not supported on
> bare metal.
> 
> Maxim.
> >
> >> -Original Message-
> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> >> Maxim Uvarov
> >> Sent: Monday, July 20, 2015 5:25 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [PATCH] example:ipsec: Fix for Polled queues
> >>
> >> Fix looks reasonable but I think it's better to have more clean fix.
> >>
> >> It might be reasonable to put all
> >>
> >>   qparam.sched.prio  = ODP_SCHED_PRIO_HIGHEST;
> >>   qparam.sched.sync  = ODP_SCHED_SYNC_ATOMIC;
> >>   qparam.sched.group = ODP_SCHED_GROUP_DEFAULT;
> >>
> >> inside queue_create. In that case queue_create will not have last
> >> argument and you don't need to set EXAMPLE_UNUSED for common code.
> >>
> >> Thanks,
> >> Maxim.
> >>
> >> On 07/20/15 11:57, nikhil.agar...@freescale.com wrote:
> >>> From: Nikhil Agarwal 
> >>>
> >>> This patch updates IPSEC application to create proper Pktin queues
> >>> in poll mode of operation.
> >>> PKTIN queue is created as polled queues if no scheduling parameters
> >>> is passed to queue create API.
> >>>
> >>> Signed-off-by: Nikhil Agarwal 
> >>> ---
> >>>example/ipsec/odp_ipsec.c |4 ++--
> >>>1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> >>> index 8b4f1a8..03bd737 100644
> >>> --- a/example/ipsec/odp_ipsec.c
> >>> +++ b/example/ipsec/odp_ipsec.c
> >>> @@ -238,7 +238,7 @@ static int num_polled_queues;
> >>>static
> >>>odp_queue_t polled_odp_queue_create(const char *name,
> >>>   odp_queue_type_t type,
> >>> - odp_queue_param_t *param)
> >>> + odp_queue_param_t *param EXAMPLE_UNUSED)
> >>>{
> >>>   odp_queue_t my_queue;
> >>>   odp_queue_type_t my_type = type; @@ -248,7 +248,7 @@
> odp_queue_t
> >>> polled_odp_queue_create(const char
> >> *name,
> >>>   my_type = ODP_QUEUE_TYPE_POLL;
> >>>   }
> >>>
> >>> - my_queue = odp_queue_create(name, my_type, param);
> >>> + my_queue = odp_queue_create(name, my_type, NULL);
> >>>
> >>>   if ((ODP_QUEUE_TYPE_SCHED == type) || (ODP_QUEUE_TYPE_PKTIN
> ==
> >> type)) {
> >>>   poll_queues[num_polled_queues++] = my_queue;
> >> ___
> >> 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] example:ipsec: Fix for Polled queues

[Agarwal Nikhil Agarwal]

Hi Maxim,

Thanks for your comment.

In case of ODP IPSEC application, queue_create is an function pointer assigned 
with odp_queue_create in schedule mode and polled_odp_queue_create in poll mode 
of operation. So we cannot remove last argument from polled_odp_queue_create 
otherwise its prototype will differ from odp_queue_create api and we will not 
be able to use common function pointer for both modes.

Regards
Nikhil

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Maxim Uvarov
> Sent: Monday, July 20, 2015 5:25 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH] example:ipsec: Fix for Polled queues
> 
> Fix looks reasonable but I think it's better to have more clean fix.
> 
> It might be reasonable to put all
> 
>  qparam.sched.prio  = ODP_SCHED_PRIO_HIGHEST;
>  qparam.sched.sync  = ODP_SCHED_SYNC_ATOMIC;
>  qparam.sched.group = ODP_SCHED_GROUP_DEFAULT;
> 
> inside queue_create. In that case queue_create will not have last
> argument and you don't need to set EXAMPLE_UNUSED for common code.
> 
> Thanks,
> Maxim.
> 
> On 07/20/15 11:57, nikhil.agar...@freescale.com wrote:
> > From: Nikhil Agarwal 
> >
> > This patch updates IPSEC application to create proper Pktin queues in
> > poll mode of operation.
> > PKTIN queue is created as polled queues if no scheduling parameters is
> > passed to queue create API.
> >
> > Signed-off-by: Nikhil Agarwal 
> > ---
> >   example/ipsec/odp_ipsec.c |4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> > index 8b4f1a8..03bd737 100644
> > --- a/example/ipsec/odp_ipsec.c
> > +++ b/example/ipsec/odp_ipsec.c
> > @@ -238,7 +238,7 @@ static int num_polled_queues;
> >   static
> >   odp_queue_t polled_odp_queue_create(const char *name,
> > odp_queue_type_t type,
> > -   odp_queue_param_t *param)
> > +   odp_queue_param_t *param EXAMPLE_UNUSED)
> >   {
> > odp_queue_t my_queue;
> > odp_queue_type_t my_type = type;
> > @@ -248,7 +248,7 @@ odp_queue_t polled_odp_queue_create(const char
> *name,
> > my_type = ODP_QUEUE_TYPE_POLL;
> > }
> >
> > -   my_queue = odp_queue_create(name, my_type, param);
> > +   my_queue = odp_queue_create(name, my_type, NULL);
> >
> > if ((ODP_QUEUE_TYPE_SCHED == type) || (ODP_QUEUE_TYPE_PKTIN ==
> type)) {
> > poll_queues[num_polled_queues++] = my_queue;
> 
> ___
> 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] example:ipsec: query regarding ESP policy configuration

[Agarwal Nikhil Agarwal]

Hi All,

Is there any way to configure IPSEC application so that both encryption and 
authentication is catered in esp policy only?

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

Re: [lng-odp] Query regarding sequence number update in IPSEC application

[Agarwal Nikhil Agarwal]

My current concerns is w.r.t the ipsec example use case only. Usages of atomic 
queues may be demonstrated by other specific example.
Also even if we use atomic queues for sequence number it cannot guarantee the 
ingress order preservation if incoming packets are picked up by different cores 
and submitted to seq number queue in different order.

Regards
Nikhil

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
Manoharan
Sent: Tuesday, May 12, 2015 5:58 PM
To: Ola Liljedahl
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Query regarding sequence number update in IPSEC 
application

IMO, using atomic variable instead of atomic queues will work for this Ipsec 
example use-case as in this case the critical section is required only for 
updating the sequence number but in a generic use-case the atomicity should be 
protected over "a region of code" which the application wants to be executed in 
the ingress-order.

If HWs are capable we should add additional APIs for scheduler based locking 
which can be used by application incase the critical section is small enough 
that going through scheduler will cause a performance impact.

Regards,
Bala

On 12 May 2015 at 17:31, Ola Liljedahl 
mailto:ola.liljed...@linaro.org>> wrote:
Yes the seqno counter is a shared resource and the atomic_fetch_and_add will 
eventually become a bottleneck for per-SA throughput. But one could hope that 
it should scale better than using atomic queues although this depends on the 
actual microarchitecture.

Freescale PPC has "decorated storage", can't it be used for 
atomic_fetch_and_add()?
ARMv8.1 has support for "far atomics" which are supposed to scale better (again 
depends on the actual implementation).

On 12 May 2015 at 13:47, Alexandru Badicioiu 
mailto:alexandru.badici...@linaro.org>> wrote:
Atomic increment performance gets worse by increasing the number of cores -
see 
https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2015.01.31a.pdf
 - chapter 5) for some measurements on a conventional Intel machine.
It may be possible for this overhead to become bigger than the one associated 
with the atomic queue.

Alex

On 12 May 2015 at 14:20, Ola Liljedahl 
mailto:ola.liljed...@linaro.org>> wrote:
I think it should be OK to use ordered queues instead of atomic queues, e.g. 
for sequence number allocation (which will need an atomic variable to hold the 
seqno counter). Packet ingress order will be maintained but might not always 
correspond to sequence number order. This is not a problem a the sliding window 
in the replay protection will take care of that, the sliding window could be 
hundreds of entries (sequence numbers) large (each will only take one bit). 
Packet ingress order is the important characteristic that must be maintained. 
The IPsec sequence number is not used for packet ordering and order 
restoration, it is only used for replay protection.

Someone with a platform which supports both ordered and atomic scheduling could 
benchmark both designs and see how performance scales when using ordered queues 
(and that atomic fetch_and_add) for some relevant traffic patterns.

On 8 May 2015 at 13:53, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
Jerrin,

Can you propose such a set of APIs for further discussion?  This would be good 
to discuss at the Tuesday call.

Thanks.

Bill

On Fri, May 8, 2015 at 12:07 AM, Jacob, Jerin 
mailto:jerin.ja...@caviumnetworks.com>> wrote:

I agree with Ola here on preserving the ingress order.
However, I have experienced same performance issue as Nikhil pointed out
(atomic queues have too much overhead for short critical section)

I am not sure about any other HW but Cavium has support for
introducing the critical section while maintain the ingress order as a HW 
scheduler feature.

IMO, if such support is available in other HW then 
odp_schedule_ordered_lock()/unlock()
kind of API will solve the performance issue for the need for short critical 
section in ordered flow.

/Jerin.


From: lng-odp 
mailto:lng-odp-boun...@lists.linaro.org>> on 
behalf of Ola Liljedahl 
mailto:ola.liljed...@linaro.org>>
Sent: Thursday, May 7, 2015 9:06 PM
To: nikhil.agar...@freescale.com
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Query regarding sequence number update in IPSEC 
application


Using atomic queues will preserve the ingress order when allocating and 
assigning the sequence number. Also you don't need to use an expensive atomic 
operation for updating the sequence number as the atomic queue and scheduling 
will provide mutual  exclusion.


If the packets that require a sequence number came from parallel or ordered 
queues, there would be no guarantee that the sequence numbers would be 
allocated in packet (ingress) order. Just using an atomic operation (e.g. 
fetch_and_add or similar) only  guarantees proper update of the sequence number 
variable, not any specifi