Re: [dpdk-dev] [PATCH v3 0/3] add fallback session

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi Anoob,
Answers/comments inline.
Marcin, please correct me, if I missed something.
Konstantin

> 
> Hi Marcin, Konstantin,
> 
> I've few more observations regarding the proposed feature.
> 
> 1. From what I understood, if an ESP packet ends up on an unprotected interface and doesn't have 'PKT_RX_SEC_OFFLOAD' bit set, then the
> packet would be looked up to see the associated SA and then fallback session is figured out and then further processing is done.
> 
> Can you confirm if I understood the sequence correctly? If yes, then aren't we doing an extra lookup in the s/w? The packet may be looked
> by the h/w using rte_flow and that information could be used to determine the SA. Also, if the ESP packet is expected to be forwarded, then
> the above logic will add an unnecessary lookup even after your h/w has detected that the packet need not be security processed.

Not sure I understood your whole statement above.
AFAIK, right now (with dpdk master) for unprotected iface it works like that:

1.  slit incoming traffic into 3 groups: ESP packets, IPv4 packets, IPv6 packets.
For ESP packets: 
2. perform SAD lookup
    a. if it fails (non SA found for that SPI), then drop the packet.
    b. otherwise (SA found) process the packet using found SA

What fall-back patch adds:
Before step 2.b check:
does that SA has its primary session  with type INLINE-CRYPTO and   
does HW fail to do IPsec realted processing for it (by some reason)?
If yes, then mark this packet to be processed by fall-back session.
if (MBUF_NO_SEC_OFFLOAD(pkt) && sa->fallback_sessions > 0) {
                uintptr_t intsa = (uintptr_t)sa;
                intsa |= IPSEC_SA_OFFLOAD_FALLBACK_FLAG;
                result_sa = (void *)intsa;
 }

So from my perspective, no additional lookup where introduced.
Also AFAIK, right now there is no possibility to configure ipsec-secgw
to BYPASS some ESP traffic.
Should we do it (to conform to ipsec RFC) - that's probably subject of
another discussion.
 
> 
> 2. The solution proposed here seems like adding the handling in ipsec-secgw instead of ipsec library. In other words, this feature is not
> getting added in ipsec library, which was supposed to simplify the whole ipsec usage in DPDK, but fails to handle the case of fragmentation.

What we have right now with ipsec library is SA (low) level API.
It can handle multi-segment packets properly, but expects someone else to do other steps (fragmentation/reassembly).
ipsec-secgw demonstrates how librte_ip_frag and librte_ipsec can be used together to deal with fragmented IPsec traffic
in a proper manner.
Probably in future we'll consider adding some high-level API that will be able to do whole processing under hood
(SPD/SAD lookup, fragment/reassembly, actual IPsec packet processing, matching inbound selectors, etc.),
but right now it is not the case.  

> Also, since the fallback feature is entirely done in the application, it begs the question why the same feature is omitted for legacy use case.

Because legacy mode doesn't support multi-seg packets at first place.
Also it is an extra overhead to support 2 code-paths (legacy and library)
for the same app, so we'd like in future to deprecate and later remove legacy code-path.
As a first step we propose to make library code-path a default one:
http://patches.dpdk.org/cover/58247/

> 
> 3. It seems like ordering won't be maintained once this processing is done. Again, this is the sequence I understood. Please correct me if I
> missed something,
>        a. Application receives a bunch of packets (let's say 6 packets), in which few are fragmented (P3 & P4) and the rest can be inline
> processed.
>        b. Application receives P1->P2->P3->P4->P5->P6 (in this, P1, P2, P5, P6 are inline processed successfully) and P4 & P5 are the fragments
>        c. Application groups packets. P1->P2->P5->P6 becomes one group and P3->P4 becomes another and goes for fallback processing.
> Now how is ordering maintained? I couldn't figure out how that is done in this case.

You right, fallback session can introduce packet reordering.
At least till we'll have ability to process packets in sync mode too.
See our presentation at dpdk userspace (slides 17, 18):
https://static.sched.com/hosted_files/dpdkbordeaux2019/8f/DPDK-IPSECu9.pdf
Right now the only way to deal with it - have replay window big enough to sustain
reordering and async processing latency.
That's actually another reason why we add this feature into ipsec-secgw sample app:
so people can evaluate it on their platforms, determine what replay window size
would be needed, what issues/slowdowns it might cause, etc.

> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Marcin Smoczynski
> > Sent: Monday, September 23, 2019 5:14 PM
> > To: Anoob Joseph <anoobj@marvell.com>; akhil.goyal@nxp.com;
> > konstantin.ananyev@intel.com
> > Cc: dev@dpdk.org; Marcin Smoczynski <marcinx.smoczynski@intel.com>
> > Subject: [dpdk-dev] [PATCH v3 0/3] add fallback session
> >
> > Add fallback session feature allowing to process packets that inline processor
> > is unable to handle (e.g. fragmented traffic). Processing takes place in a
> > secondary session defined for SA in a configuration file.
> >
> > This feature is limited to ingress IPsec traffic only. IPsec anti-replay window
> > and ESN are supported in conjunction with fallback session when following
> > conditions are met:
> >  * primary session is 'inline-crypto-offload,
> >  * fallback sessions is 'lookaside-none'.
> >
> > v2 to v3 changes:
> >  - doc and commit log update - explicitly state feature limitations
> >
> > 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      |  20 ++-
> >  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, 361 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.17.1