> -----Original Message----- > From: Akhil Goyal [mailto:[email protected]] > Sent: Friday, December 21, 2018 2:57 PM > To: Ananyev, Konstantin <[email protected]>; [email protected] > Cc: Nicolau, Radu <[email protected]> > Subject: Re: [dpdk-dev] [PATCH v4 3/9] examples/ipsec-secgw: fix crypto-op > might never get dequeued > > > > On 12/21/2018 8:19 PM, Ananyev, Konstantin wrote: > > > >> -----Original Message----- > >> From: Akhil Goyal [mailto:[email protected]] > >> Sent: Friday, December 21, 2018 2:13 PM > >> To: Ananyev, Konstantin <[email protected]>; [email protected] > >> Cc: Nicolau, Radu <[email protected]> > >> 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.
No it is not possible with current app design. eqnueue/dequeue from particular crypto-queue is always done by the same core. > 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
