Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.
On 07.04.2017 13:00, Nikhil Agarwal wrote:
> +typedef union odp_ipsec_protocols_t {
> + /** Cipher algorithms */
> + struct {
> + /** ODP_IPSEC_ESP */
> + uint32_t esp: 1;
> +
> + /** ODP_IPSEC_AH */
> + uint32_t ah : 1;
Small suggestion: it might be reasonable to split esp and ah to fully
identify ESP_IPv4/ESP_IPv6 and AH_IPv4/AH_IPv6.
--
With best wishes
Dmitry
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.
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
*
* User defined context pointer associated with the SA.
--
2.9.3
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;
> 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.
>
> Thanks
> Shally
>
> - /** Classifier destination CoS for IPSEC result events
> -*
> -* Result events for successfully decapsulated packet
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 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
*
*
Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.
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.
Hi, > > 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. My understanding was that the completion queuing order is neither the submission order nor operation completion order, but the packet input order with respect to the ordered context of the thread(s) submitting the packet to IPsec (i.e. the order packets arrived in the system if there is a chain of ordered contexts before IPsec enqueue). But now that I look at the latest IPsec API I am not sure it reads that way. Maybe I am mistaken or maybe the API doc is just not clear enough. Anyway, I think original packet order is the most useful alternative since then I can construct the application data path like this: pktin->ordered queue->app processing->ipsec enque ... ipsec event->ordered queue->app processing->ordered output queue->pktout Original packet order would be maintained through the whole chain without the application having to take any atomic context. If IPsec offload only respected the submission order, then maintaining the original packet order would require switching to an atomic context (going through an atomic queue) or taking an ordered lock before IPsec operation submission. Janne
