On 12/21/2018 8:19 PM, Ananyev, Konstantin wrote: > >> -----Original Message----- >> From: Akhil Goyal [mailto:akhil.go...@nxp.com] >> Sent: Friday, December 21, 2018 2:13 PM >> To: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org >> Cc: Nicolau, Radu <radu.nico...@intel.com> >> Subject: Re: [dpdk-dev] [PATCH v4 3/9] examples/ipsec-secgw: fix crypto-op >> might never get dequeued >> >> >> >> On 12/14/2018 10:10 PM, Konstantin Ananyev wrote: >>> In some cases crypto-ops could never be dequeued from the crypto-device. >>> The easiest way to reproduce: >>> start ipsec-secgw with crypto-dev and send to it less then 32 packets. >>> none packets will be forwarded. >>> Reason for that is that the application does dequeue() from crypto-queues >>> only when new packets arrive. >>> This patch makes sure it calls dequeue() on a regular basis. >>> >>> Fixes: c64278c0c18b ("examples/ipsec-secgw: rework processing loop") >> Thanks for looking into this age long issue of ipsec-secgw. But wouldn't >> this cause packet reordering, >> and the packets which are somehow left in the queue will get delayed and >> would be dropped subsequently due to anti-replay late? > Could you explain a bit more - how do you think reordering might happen?
I thought any core can pick the remainder of the packets and can give to any of the cryptodevs. If that is assured, then probably we wont face such issues. > Now we always processing packets belonging to particular SA on the same > crypto-dev. > Konstantin
