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.
Right now we don't do outbound fallback sessions.
Again, similar scheme would work for TX with lookaside-none and inline-crypto,
but not for inline/lookaside-proto.
Of course few extra changes would be needed - move fragmentation before ipsec
processing part.
>
> >
> > >
> > > 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.
Sure, looking forward for it.
In fact, I asked these questions a year ago but as I said before there was no
progress on that.
> You do agree that this approach will not help inline protocol offloading,
> right?
Yes, see above.
> 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.
Obviously there is no such API for any *-proto devices, see above.
Not sure why do you keep repeating it, I already agreed with you, see above :)
Just to summarize:
1. Yes I think for lookaiside/iniline-proto devices there is a need for some
extra API
to sync session state between HW and SW.
Right now, I don't have a clear idea how exactly it should look like.
2. Intel team doesn't plan to work on this API right now.
3. I am happy to review with what you guys will come-up with and provide my
feedback.
Hope that makes things clear.
Konstantin
>
> > 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
