Hi,
On Thu, Apr 6, 2017 at 1:46 PM, Bill Fischofer <bill.fischo...@linaro.org>
wrote:
> On Thu, Apr 6, 2017 at 1:32 PM, Ola Liljedahl <ola.liljed...@linaro.org>
> wrote:
> > On 6 April 2017 at 13:48, Jerin Jacob <jerin.ja...@caviumnetworks.com>
> > wrote:
> >> We see ORDERED->ATOMIC as main use case for basic packet forward.Stage
> >> 1(ORDERED) to process on N cores and Stage2(ATOMIC) to maintain the ingress
> >> order.
> > Doesn't ORDERED scheduling maintain the ingress packet order all the
> > way to the egress interface? A least that's my understanding of ODP
> > ordered queues.
> > From an ODP perspective, I fail to see how the ATOMIC stage is needed.
For basic IP forwarding I also do not see why an atomic stage would be
needed, but for stateful things like IPsec or some application specific
higher layer processing the situation can be different.
At the risk of stating the obvious: Ordered scheduling maintains ingress
order when packets are placed in the next queue (toward the next pipeline
stage or to pktout), but it allows parallel processing of packets of the
same flow between the points where order is maintained. To guarantee packet
processing in the ingress order in some section of code, the code needs
to be executed in an atomic context or protected using an ordered lock.
> As pointed out earlier, ordered locks are another option to avoid a
> separate processing stage simply to do in-sequence operations within
> an ordered flow. I'd be curious to understand the use-case in a bit
> more detail here. Ordered queues preserve the originating queue's
> order, however to achieve end-to-end ordering involving multiple
> processing stages requires that flows traverse only ordered or atomic
> queues. If a parallel queue is used ordering is indeterminate from
> that point on in the pipeline.
Exactly.
In an IPsec GW (as a use case example) one might want to do all
stateless processing (like ingress and egress IP processing and the
crypto operations) in ordered contexts to get parallelism, but the
stateful part (replay-check and sequence number generation) in
an atomic context (or holding an ordered lock) so that not only
the packets are output in ingress order but also their sequence
numbers are in the same order.
That said, some might argue that IPsec replay window can take care
not only of packet reordering in the network but also of reordering
inside an IPsec GW and therefore the atomic context (or ordered lock)
is not necessarily needed in all implementations.
Janne
