RE: [PATCH v4 1/2] security: add fallback security processing and Rx inject

[Akhil Goyal <gakhil@marvell.com>]

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Tuesday, October 10, 2023 4:02 PM
> To: Akhil Goyal <gakhil@marvell.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Vidya Sagar
> Velumuri <vvelumuri@marvell.com>; david.coyle@intel.com; kai.ji@intel.com;
> kevin.osullivan@intel.com; Ciara Power <ciara.power@intel.com>
> Subject: [PATCH v4 1/2] security: add fallback security processing and Rx inject
> 
> Add alternate datapath API for security processing which would do Rx
> injection (similar to loopback) after successful security processing.
> 
> With inline protocol offload, variable part of the session context
> (AR windows, lifetime etc in case of IPsec), is not accessible to the
> application. If packets are not getting processed in the inline path
> due to non security reasons (such as outer fragmentation or rte_flow
> packet steering limitations), then the packet cannot be security
> processed as the session context is private to the PMD and security
> library doesn't provide alternate APIs to make use of the same session.
> 
> Introduce new API and Rx injection as fallback mechanism to security
> processing failures due to non-security reasons. For example, when there
> is outer fragmentation and PMD doesn't support reassembly of outer
> fragments, application would receive fragments which it can then
> reassemble. Post successful reassembly, packet can be submitted for
> security processing and Rx inject. The packets can be then received in
> the application as normal inline protocol processed packets.
> 
> Same API can be leveraged in lookaside protocol offload mode to inject
> packet to Rx. This would help in using rte_flow based packet parsing
> after security processing. For example, with IPsec, this will help in
> flow splitting after IPsec processing is done.
> 
> In both inline protocol capable ethdevs and lookaside protocol capable
> cryptodevs, the packet would be received back in eth port & queue based
> on rte_flow rules and packet parsing after security processing. The API
> would behave like a loopback but with the additional security
> processing.
> 
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> Signed-off-by: Vidya Sagar Velumuri <vvelumuri@marvell.com>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> ---
> v4:
> Updated release notes
> 
> v3:
> * Resolved compilation error with 32 bit build
> 
> v2:
> * Added a new API for configuring security device to do Rx inject to a specific
>   ethdev port
> * Rebased
> 
>  doc/guides/cryptodevs/features/default.ini |  1 +
>  doc/guides/rel_notes/release_23_11.rst     | 19 +++++
>  lib/cryptodev/rte_cryptodev.h              |  2 +
>  lib/security/rte_security.c                | 22 ++++++
>  lib/security/rte_security.h                | 85 ++++++++++++++++++++++
>  lib/security/rte_security_driver.h         | 44 +++++++++++
>  lib/security/version.map                   |  3 +
>  7 files changed, 176 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 6f637fa7e2..f411d4bab7 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -34,6 +34,7 @@ Sym raw data path API  =
>  Cipher multiple data units =
>  Cipher wrapped key     =
>  Inner checksum         =
> +Rx inject              =
> 
>  ;
>  ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/rel_notes/release_23_11.rst
> b/doc/guides/rel_notes/release_23_11.rst
> index be51f00dbf..6853c907c9 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -107,6 +107,25 @@ New Features
>    enhancements to ``rte_crypto_op`` fields to handle all datapath requirements
>    of TLS and DTLS. The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
> 
> +* **Added support for rte_security Rx inject API.**
> +
> +  Added Rx inject API to allow applications to submit packets for protocol
> +  offload and have them injected back to ethdev Rx so that further ethdev Rx
> +  actions (IP reassembly, packet parsing and flow lookups) can happen based on
> +  inner packet.
> +
> +  The API when implemented by an ethdev, may be used to process packets that
> the
> +  application wants to process with inline protocol offload enabled rte_security
> +  session. These can be packets that are received from other non-inline capable
> +  ethdevs or can be packets that failed inline protocol offload (such as
> +  receiving fragmented ESP packets in case of inline IPsec offload).
> +
> +  The API when implemented by a cryptodev, can be used for injecting packets
> to
> +  ethdev Rx after IPsec processing and take advantage of ethdev Rx processing
> +  for the inner packet. The API helps application to avail ethdev Rx actions
> +  based on inner packet while working with rte_security sessions which cannot
> +  be accelerated in inline protocol offload mode.
> +
Reworded the above release notes as below.

* **Added support for rte_security Rx inject API.**

  Added Rx inject API to allow applications to submit packets for protocol
  offload and have them injected back to ethdev Rx so that further ethdev Rx
  actions (IP reassembly, packet parsing and flow lookups) can happen based on
  inner packet.

  The API when implemented by an ethdev, application would be able to process
  packets that are received without/failed inline offload processing
  (such as fragmented ESP packets with inline IPsec offload).
  The API when implemented by a cryptodev, can be used for injecting packets
  to ethdev Rx after IPsec processing and take advantage of ethdev Rx actions
  for the inner packet which cannot be accelerated in inline protocol offload mode.

Applied to dpdk-next-crypto

Thanks.