> > /**
> > + * 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;
> > +
> > + /** Constraints for SPI values of inbound SAs for which lookup
> is
> > + * enabled. Minimal range size and unique SPI values may
> improve
> > + * performance. */
> > + struct {
> > + /** Minimum inbound SPI value. Default value is 0. */
> > + uint32_t min;
> > +
> > + /** Maximum inbound SPI value. Default value is
> UINT32_MAX. */
> > + uint32_t max;
> > +
> > + /** Inbound SPI values may overlap. Default value is 0.
> */
> > + odp_bool_t overlap;
>
> It's not clear what you mean by SPI values overlapping since an SPI is
> a unit32_t value. Some explanation / illustration seems warranted
> here.
Application tells if it uses unique SPI values for all (inbound) SAs it creates
(== no two SAs have the same SPI), which results simpler lookup for
implementation. This should be the default setting, since application can
decide inbound SPI values. Since default values are usually zero, I used term
"overlap" instead of e.g. "non_unique".
> >
> > /**
> > + * 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.
>
> Does this mean that it is an application responsibility to ensure that
> there are no "in flight" IPsec operations at the time this call is
> made? That seems unnecessarily burdensome, as one of the purposes of
> an API like this is to flush the request pipeline before issuing a
> destroy call. I'd prefer the following sort of wording:
>
> "Operations initiated or in progress at the time this call is made
> will complete normally, however no further operations on this SA will
> be accepted. For example, inbound SPI lookups will not match any more,
> and outbound operations referencing this SA will fail."
Application must not pass the same SA as parameter simultaneously to disable()
and e.g. ipsec_in() or ipsec_enq(). This way implementation does not (may not)
need to synchronize, between slow path (disable) and fast path (ipsec_in)
calls. Appplication should be able to synchronize itself so that one thread
does not disable/destroy a SA that other thread still actively uses.
Look ups for in-flight packet are still possible during disable, since that SA
usage is in control of implementation. So, application can still continue
passing packets without SA (for lookup), but it must not explicitly refer use
SA itself on other (fast path calls).
-Petri
