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.
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. 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.
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.
Thanks,
Anoob
> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Marcin Smoczynski
> Sent: Monday, September 23, 2019 5:14 PM
> To: Anoob Joseph <ano...@marvell.com>; akhil.go...@nxp.com;
> konstantin.anan...@intel.com
> Cc: dev@dpdk.org; Marcin Smoczynski <marcinx.smoczyn...@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
