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