| Message ID | 20170407100014.5122-1-nikhil.agarwal@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
-----Original Message----- From: lng-odp [mailto:lng-odp-bounces@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 <nikhil.agarwal@linaro.org> --- include/odp/api/spec/ipsec.h | 62 +++++++++++++++++++------------------------- 1 file changed, 26 insertions(+), 36 deletions(-) */ 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.3diff --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 {
-----Original Message----- From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of Verma, Shally Sent: Friday, April 07, 2017 4:45 PM To: Nikhil Agarwal <nikhil.agarwal@linaro.org>; 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-bounces@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 <nikhil.agarwal@linaro.org> --- include/odp/api/spec/ipsec.h | 62 +++++++++++++++++++------------------------- 1 file changed, 26 insertions(+), 36 deletions(-) */ 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 * * User defined context pointer associated with the SA. -- 2.9.3diff --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 {
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
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.
Signed-off-by: Nikhil Agarwal <nikhil.agarwal@linaro.org> --- include/odp/api/spec/ipsec.h | 62 +++++++++++++++++++------------------------- 1 file changed, 26 insertions(+), 36 deletions(-) -- 2.9.3