[dpdk-dev] [PATCH v6 2/4] examples/ipsec-secgw: add fallback session feature

[Ananyev, Konstantin]

> > > > 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.
> 
> Which usecases allow reordering.

AFAIK, VoIP, video-streaming, netflow/ipfix, some P2P protocols -  all of them tolerate packet reordering.
Actually modern TCP implementations are also quite robust to packet reorderings
(till some extent of course).

> I think most stacks have replay window of less than 256/128 frames.

>From our measurements, on IA boxes, ~256 seems good enough for many cases. 

> >
> >  > 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.
> 
> So what is currently supported with this patchset.
> - cpu crypto is not there yet.
> - SW PMD you are not supporting that model.

ixbge(inline-crypto)+qat(lksd-crypto)

> 
> >
> > >
> > > 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?
> I believe there are some discussion going on between you and Anoob.

Seems too vague...
Anything concrete?
Konstantin