Hi,

Why is this change needed or preferred over the current API?

I would guess that many applications that use inline or asynchronous
mode need an end marker in the SA queue so that they know when they
can free their own per-SA state and destroy the ODP SA (i.e. when
all events for the SA being disabled have been dequeued and processed).

If odp_ipsec_sa_disable() may return synchronously, then such an
application would need to submit an end marker event to the SA queue
itself. The application cannot create an IPsec status event itself so
it has to define another type of event. But the application still has
to be able to process both the IPsec status event and its own event
in the event handler.

So, based on the above, it does not look like this change would make
the life of an application any easier, but maybe even the opposite.
Does it make ODP implementation significantly easier?

If this change is anyway made, the API should make it clear that after
return with retval 0 the implementation will not enqueue any further
events for that SA to the SA queue.

        Janne


> -----Original Message-----
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Github 
> ODP bot
> Sent: Thursday, August 10, 2017 9:00 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v5 1/1] API:IPSEC: IPSEC events may be 
> reported
> synchronously.
> 
> From: Nikhil Agarwal <nikhil.agar...@linaro.org>
> 
> IPSEC events may be delivered synchronous or ansynchrous
> depending on implementation. Application will know based on
> return value of odp_ipsec_sa_disable API.
> 
> Signed-off-by: Nikhil Agarwal <nikhil.agar...@linaro.org>
> ---
> /** Email created from pull request 109 (NikhilA-Linaro:disable_event)
>  ** https://github.com/Linaro/odp/pull/109
>  ** Patch: https://github.com/Linaro/odp/pull/109.patch
>  ** Base sha: e420668cd3886f003c8bd6022e210bf08a0ee3b5
>  ** Merge commit sha: f65d49b122f2f60a7fc9af3e0a09067dcfd369d9
>  **/
>  include/odp/api/spec/ipsec.h | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index 7085bc0d..3f02635a 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -831,16 +831,19 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
> odp_ipsec_sa_param_t
> *param);
>   * 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. The
> - * status event is guaranteed to be the last event for the SA, i.e. all
> - * in-progress operations have completed and resulting events (including 
> status
> - * events) have been enqueued before it.
> + * A return value 0 indicates that the disable request has completed
> + * synchronously and the SA is now disabled. A return value 1 indicates that 
> the
> + * disable request has been accepted and completion will be indicated by an
> + * ODP_EVENT_IPSEC_STATUS sent to the queue specified for the SA. This event 
> is
> + * guaranteed to be the last event for the SA, i.e., all in-progress 
> operations
> + * have completed and resulting events (including status events) have been
> + * enqueued before it. In synchronous mode of operation, disable requests are
> + * gauranteed to complete synchronously as there is no queue assciated with 
> SA.
>   *
>   * @param sa      IPSEC SA to be disabled
>   *
> - * @retval 0      On success
> + * @retval 0      When SA is disabled successfully.
> + * @retval 1      Disable event will be posted on SA queue.
>   * @retval <0     On failure
>   *
>   * @see odp_ipsec_sa_destroy()

Reply via email to