> > /**
> > + * 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
