[dpdk-dev] [PATCH v4 3/9] examples/ipsec-secgw: fix crypto-op might never get dequeued

Ananyev, Konstantin konstantin.ananyev at intel.com
Fri Dec 21 16:01:37 CET 2018



> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal at nxp.com]
> Sent: Friday, December 21, 2018 2:57 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; dev at dpdk.org
> Cc: Nicolau, Radu <radu.nicolau at intel.com>
> 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:akhil.goyal at nxp.com]
> >> Sent: Friday, December 21, 2018 2:13 PM
> >> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; dev at dpdk.org
> >> Cc: Nicolau, Radu <radu.nicolau at 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.

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



More information about the dev mailing list