Using atomic queues will preserve the ingress order when allocating and assigning the sequence number. Also you don't need to use an expensive atomic operation for updating the sequence number as the atomic queue and scheduling will provide mutual exclusion.
If the packets that require a sequence number came from parallel or ordered queues, there would be no guarantee that the sequence numbers would be allocated in packet (ingress) order. Just using an atomic operation (e.g. fetch_and_add or similar) only guarantees proper update of the sequence number variable, not any specific ordering. If you are ready to trade absolute "correctness" for performance, you could use ordered or may even parallel (questionable for other reasons) queues and then allocate the sequence number using an atomic fetch_and_add. Sometimes packets egress order will then not match the sequence number order (for a flow/SA). For IPSec, this might affect the replay window check & update at the receiving end but as the replay protection uses a sliding window of sequence numbers (to handle misordered packets), there might not be any adverse effects in practice. The most important aspect is probably to preserve original packet order. -- Ola On 6 May 2015 at 11:29, nikhil.agar...@freescale.com < nikhil.agar...@freescale.com> wrote: > Hi, > > > > In IPSEC example application, queues are used to update the sequence > number. I was wondering why we have used queues to update sequence number > which will add to scheduling delays and adversely hit the performance > throughput. Is there any specific advantage of using queues over atomic > variables. > > > > Thanks in advance > > Nikhil > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
