[dpdk-dev] [PATCH v6 2/4] examples/ipsec-secgw: add fallback session feature
Ananyev, Konstantin
konstantin.ananyev at intel.com
Fri Oct 11 17:06:30 CEST 2019
Hi Akhil,
> >
> > Inline processing is limited to a specified subset of traffic. It is
> > often unable to handle more complicated situations, such as fragmented
> > traffic. When using inline processing such traffic is dropped.
> >
> > Introduce fallback session for inline processing allowing processing
> > packets that normally would be dropped. A fallback session is
> > configured by adding 'fallback' keyword with 'lookaside-none' or
> > 'lookaside-protocol' parameter to an SA configuration.
> >
> > Using IPsec anti-replay window or ESN feature with fallback session is
> > not yet supported when primary session is of type
> > 'inline-protocol-offload' or fallback session is 'lookaside-protocol'
> > because SA sequence number is not synchronized between software and
> > hardware sessions. Fallback sessions are also limited to ingress IPsec
> > traffic.
> >
> > Fallback session feature is not available in the legacy mode.
> >
> I started looking this patch, but some initial thoughts looking at the patch description.
>
> When you say a fallback session will be a lookaside none or lookaside protocol,
> the packet will be processed asynchronously and might as well reorder.
Yes, we documented it as one of limitations.
Though as I already mentioned for some use-cases some reordering it is acceptable.
> The best possible solution for this would be the synchronous API which are in talks
Agree, that would be a way to avoid reordering, but it is not there yet.
> in another patchset or use a SW PMD(eg. Openssl etc.) session and wait till you get the packet dequeued.
> So effectively async APIs will be used to behave synchronously.
> You can not use hardware PMD session as it will perform very badly for fallback packets
> Because you have to wait till the packet is not getting dequeued back.
We don't plan to support that model because of great performance penalty you mentioned.
>
> Having said that, you won't find a device or a scenario where you can use
> Inline crypto as primary and lookaside proto as fallback.
> It can only be like inline crypto as primary and lookaside none as fallback.
Yes, correct.
I thought that we already removed lookaside-proto from supported types.
If we didn't - will certainly do that.
>
> BTW, I am ok with Patch 1/4 and 3/4. If no objections from the community, I can pick those.
Great to hear.
What obstacles do you see with others two?
Konstantin
>
> -Akhil
>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> > Tested-by: Bernard Iremonger <bernard.iremonger at intel.com>
> > Signed-off-by: Marcin Smoczynski <marcinx.smoczynski at intel.com>
> > ---
More information about the dev
mailing list