Re: [lng-odp] [API-NEXT PATCH v2 1/3] api: ipsec: extend lookaside API

2017-03-23 Thread Bala Manoharan
Regards,
Bala

On 21 March 2017 at 19:47, Petri Savolainen 
wrote:

> Added configuration option for inbound SPI range and default
> queue. Added SA disable function and status event for the
> response from it. The same event may be used for e.g. IPSEC
> statistics, etc queries. Improved outbound fragmentation
> documentation.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/event.h |   2 +-
>  include/odp/api/spec/ipsec.h | 181 ++
> +++--
>  2 files changed, 143 insertions(+), 40 deletions(-)
>
> diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h
> index 75c0bbc..f22efce 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_IPSEC_RESULT
> + * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT, ODP_EVENT_IPSEC_STATUS
>   */
>
>  /**
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index 66222d8..e951e49 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -56,6 +56,30 @@ typedef enum odp_ipsec_op_mode_t {
>  } odp_ipsec_op_mode_t;
>
>  /**
> + * Configuration options for IPSEC inbound processing
> + */
> +typedef struct odp_ipsec_inbound_config_t {
> +   /** Default destination queue for IPSEC events
> +*
> +*  When inbound SA lookup fails in asynchronous or inline modes,
> +*  resulting IPSEC events are enqueued into this queue.
> +*/
> +   odp_queue_t default_queue;
> +
> +   /** Inbound SPI range. Minimal range size may improve performance.
> */
> +   struct {
> +   /** Minimum inbound SPI value that application will use.
> +*  Default value is 0. */
> +   uint32_t min;
> +
> +   /** Maximum inbound SPI value that application will use.
> +*  Default value is UINT32_MAX. */
> +   uint32_t max;
> +   } spi;
> +
> +} odp_ipsec_inbound_config_t;
> +
> +/**
>   * IPSEC capability
>   */
>  typedef struct odp_ipsec_capability_t {
> @@ -111,6 +135,13 @@ typedef struct odp_ipsec_config_t {
>  */
> odp_ipsec_op_mode_t op_mode;
>
> +   /** Maximum number of IPSEC SAs that application will use
> +* simultaneously */
> +   uint32_t max_num_sa;
> +
> +   /** IPSEC inbound processing configuration */
> +   odp_ipsec_inbound_config_t inbound;
> +
>  } odp_ipsec_config_t;
>
>  /**
> @@ -529,6 +560,29 @@ void odp_ipsec_sa_param_init(odp_ipsec_sa_param_t
> *param);
>  odp_ipsec_sa_t odp_ipsec_sa_create(odp_ipsec_sa_param_t *param);
>
>  /**
> + * Disable IPSEC SA
> + *
> + * Application must use this call to disable a SA before destroying it.
> The call
> + * marks the SA disabled, so that IPSEC implementation stops using it. For
> + * example, inbound SPI lookups will not match any more. Application must
> + * stop providing the SA as parameter to new IPSEC input/output operations
> + * before calling disable. Packets in progress during the call may still
> match
> + * the SA and be processed successfully.
> + *
> + * When in synchronous operation mode, the call will return when it's
> possible
> + * to destroy the SA. In asynchronous mode, the same is indicated by an
> + * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA.
>


During synchronous operation mode, it is possible that this call is
executing on one core
and the SA is being used in ipsec operation by some other core and so this
call might take considerable cpu
cycles waiting for other cores to finish.
It might be easy if we dictate that the result will be returned using the
status even for synchronous mode or we can add a new API odp_ipsec_sa_use()
which specifies if the SA has been disabled or not.


> + *
> + * @param sa  IPSEC SA to be disabled
> + *
> + * @retval 0  On success
> + * @retval <0 On failure
> + *
> + * @see odp_ipsec_sa_destroy()
> + */
> +int odp_ipsec_sa_disable(odp_ipsec_sa_t sa);
> +
> +/**
>   * Destroy IPSEC SA
>   *
>   * Destroy an unused IPSEC SA. Result is undefined if the SA is being used
> @@ -567,55 +621,59 @@ typedef struct odp_ipsec_op_opt_t {
>  #define ODP_IPSEC_OK 0
>
>  /** IPSEC operation status */
> -typedef union odp_ipsec_status_t {
> -   /** Error flags */
> -   struct {
> -   /** Protocol error. Not a valid ESP or AH packet. */
> -   uint32_t proto: 1;
> +typedef struct odp_ipsec_op_status_t {
> +   union {
> +   /** Error flags */
> +   struct {
> +   /** Protocol error. Not a valid ESP or AH packet.
> */
> +   uint32_t proto: 1;
>
> -   /** SA lookup failed */
> -   uint32_t sa_lookup: 1;
> +   /** SA

Re: [lng-odp] [API-NEXT PATCH v2 1/3] api: ipsec: extend lookaside API

2017-03-23 Thread Savolainen, Petri (Nokia - FI/Espoo)
No HTML mails please.


 /**
+ * Disable IPSEC SA
+ *
+ * Application must use this call to disable a SA before destroying it. The 
call
+ * marks the SA disabled, so that IPSEC implementation stops using it. For
+ * example, inbound SPI lookups will not match any more. Application must
+ * stop providing the SA as parameter to new IPSEC input/output operations
+ * before calling disable. Packets in progress during the call may still match
+ * the SA and be processed successfully.
+ *
+ * When in synchronous operation mode, the call will return when it's possible
+ * to destroy the SA. In asynchronous mode, the same is indicated by an
+ * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA.

During synchronous operation mode, it is possible that this call is executing 
on one core
and the SA is being used in ipsec operation by some other core and so this call 
might take considerable cpu
cycles waiting for other cores to finish.
It might be easy if we dictate that the result will be returned using the 
status even for synchronous mode or we can add a new API odp_ipsec_sa_use() 
which specifies if the SA has been disabled or not.


This is included into the spec already: " Application must stop providing the 
SA as parameter to new IPSEC input/output operations before calling disable."

So, first application needs to synchronize between all threads, so that any of 
those are not any more using the SA for current/new calls. Only after that one 
application thread goes and calls disable. In synchronous mode there are no 
packets even in flight, if application has done the above sync.

-Petri

 


Re: [lng-odp] [API-NEXT PATCH v2 1/3] api: ipsec: extend lookaside API

2017-03-23 Thread Peltonen, Janne (Nokia - FI/Espoo)

> >  /**
> > + * Disable IPSEC SA
> > + *
> > + * Application must use this call to disable a SA before destroying it. 
> > The call
> > + * marks the SA disabled, so that IPSEC implementation stops using it. For
> > + * example, inbound SPI lookups will not match any more. Application must
> > + * stop providing the SA as parameter to new IPSEC input/output operations
> > + * before calling disable. Packets in progress during the call may still 
> > match
> > + * the SA and be processed successfully.
> > + *
> > + * When in synchronous operation mode, the call will return when it's 
> > possible
> > + * to destroy the SA. In asynchronous mode, the same is indicated by an
> > + * ODP_EVENT_IPSEC_STATUS event sent to the queue specified for the SA.
> > 
> > During synchronous operation mode, it is possible that this call is 
> > executing on one core
> > and the SA is being used in ipsec operation by some other core and so this 
> > call might take
> > considerable cpu
> > cycles waiting for other cores to finish.
> > It might be easy if we dictate that the result will be returned using the 
> > status even for
> > synchronous mode or we can add a new API odp_ipsec_sa_use() which specifies 
> > if the SA has
> > been disabled or not.
> 
> 
> This is included into the spec already: " Application must stop providing the 
> SA as
> parameter to new IPSEC input/output operations before calling disable."
> 
> So, first application needs to synchronize between all threads, so that any 
> of those are
> not any more using the SA for current/new calls. Only after that one 
> application thread
> goes and calls disable. In synchronous mode there are no packets even in 
> flight, if
> application has done the above sync.
> 

Yes, but the SA may be in use through calls that do not specify the SA
explicitly as a parameter but let ODP do the lookup. In this case sa_disable()
may have to block for some time to let the sync operations on other threads
for the same SA to complete.

Janne