> > > > 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
