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
