Hi Konstantin, Please see inline.
Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > Sent: Thursday, September 19, 2019 3:49 AM > To: Anoob Joseph <ano...@marvell.com>; Smoczynski, MarcinX > <marcinx.smoczyn...@intel.com>; akhil.go...@nxp.com > Cc: dev@dpdk.org; Narayana Prasad Raju Athreya <pathr...@marvell.com>; > Jerin Jacob Kollanukkaran <jer...@marvell.com>; Archana Muniganti > <march...@marvell.com> > Subject: RE: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback > session > > > > Hi Anoob, > > > > > Sorry for the late response. But how do you plan to handle "inline > protocol" > > > processed packets? > > > > > > Right now that feature is supported for "inline crypto" only. > > > > [Anoob] The description says "inline processed" packets. Hence the > > confusion. > > > > > For the case when SA doesn't enable replay window and/or ESN current > > > patch should also work for "inline proto" too, but this is just my > > > understanding (not tested, etc.). > > > > [Anoob] In case of inline ipsec processing, the ipsec state (which > > would track sequence number etc) will be internal to the PMDs. So > > anti- replay/ESN would have to be done either in the h/w or PMD. This would > mean application will not have state information regarding ipsec processing. > Hence fallback handling with the above scheme will not work in that case. > > Agree, that's why I wrote above that current wok might work for inline-proto > *only* if replay window and ESN is disabled. [Anoob] Any feature that makes use of protocol "state" would fail with this scheme. In case of inline ipsec, that is anti-replay & ESN. I see that you are not planning for fallback session for outbound. If at all that is planned, this scheme will fail to co-ordinate sequence number between original and fallback sessions. > > > > > To address this properly for inline protocol, we will have to come up > > with some logic to share session private data b/w "eligible" PMDs. This > > would > involve library changes to rte_security, etc. > > Again, totally agree. > As I remember we already discussed it about a year ago, but didn't come up > with > any concrete proposal. > > > Once that is proposed, there will be one kind of handling for inline > > protocol processing and another kind for inline crypto processing. Would you > be fine with that? > > For sure something needs to be changed for inline-proto to sync replay- > window/ESN related data between HW/PMD and SW. > What it should be - new function, or something else - hard to tell right now. [Anoob] No disagreement. My only concern is the incompleteness of this solution. We will have to propose a totally new scheme for inline protocol. You do agree that this approach will not help inline protocol offloading, right? If you are okay with having different solutions for inline crypto & inline protocol, I don't have any issue with this series. Also, how do you plan to pass "state" info to lookaside protocol session? That will be required to handle ESN/anti-replay in lookaside protocol capable PMD as well. > Konstantin > > > > > > Konstantin > > > > > > > > > > > Thanks, > > > > Anoob > > > > > > > > > -----Original Message----- > > > > > From: dev <dev-boun...@dpdk.org> On Behalf Of Marcin Smoczynski > > > > > Sent: Wednesday, September 4, 2019 7:47 PM > > > > > To: konstantin.anan...@intel.com; akhil.go...@nxp.com > > > > > Cc: dev@dpdk.org; Marcin Smoczynski > > > > > <marcinx.smoczyn...@intel.com> > > > > > Subject: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add > > > > > fallback session > > > > > > > > > > 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 multiple sessions per SA allowing to configure a > > > > > fallback lookaside session for packets that normally would be dropped. > > > > > A fallback session type in the SA configuration by adding 'fallback' > > > > > with 'lookaside-none' or 'lookaside-protocol' parameter to > > > > > determine type of session. > > > > > > > > > > Fallback session feature is available only when using librte_ipsec. > > > > > > > > > > v1 to v2 changes: > > > > > - disable fallback offload for outbound SAs > > > > > - add test scripts > > > > > > > > > > Marcin Smoczynski (3): > > > > > examples/ipsec-secgw: ipsec_sa structure cleanup > > > > > examples/ipsec-secgw: add fallback session feature > > > > > examples/ipsec-secgw: add offload fallback tests > > > > > > > > > > doc/guides/sample_app_ug/ipsec_secgw.rst | 17 +- > > > > > examples/ipsec-secgw/esp.c | 35 ++-- > > > > > examples/ipsec-secgw/ipsec-secgw.c | 16 +- > > > > > examples/ipsec-secgw/ipsec.c | 99 ++++++----- > > > > > examples/ipsec-secgw/ipsec.h | 61 +++++-- > > > > > examples/ipsec-secgw/ipsec_process.c | 113 +++++++----- > > > > > examples/ipsec-secgw/sa.c | 164 > > > > > +++++++++++++----- > > > > > .../test/trs_aesgcm_common_defs.sh | 4 +- > > > > > .../trs_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > .../test/tun_aesgcm_common_defs.sh | 6 +- > > > > > .../tun_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > 11 files changed, 358 insertions(+), 167 deletions(-) create > > > > > mode > > > > > 100644 > > > > > examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs > > > > > .sh create mode 100644 examples/ipsec- > > > > > secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh > > > > > > > > > > -- > > > > > 2.21.0.windows.1
