[dpdk-dev] [RFC][PATCH 0/5] cryptodev: Adding support for inline crypto processing of IPsec flows

[Boris Pismenny]

> 5. The addition of inline crypto metadata into the rte_mbuf structure to allow the required egress metadata to be given to the NIC PMD to build the necessary transmit descriptors in tx_burst processing when the PKT_TX_IPSEC_INLINE_CRYPTO is set. We are looking for feedback on a better approach to handling the passing of this metadata to the NIC as it is understood that different hardware accelerators which support this offload may have different requirements for metadata depending on implementation and other capabilities in the device. One possibility we have consider is that the last 16 bytes of mbuf is reserved for device specific metadata, which layout is flexible depending on the hardware being used.
> 
> struct rte_mbuf {
> ...
> 	/** Inline IPSec metadata*/
> 	struct {
> 	        uint16_t sa_idx;        /**< SA index */
> 	        uint8_t  pad_len;       /**< Padding length */
> 	        uint8_t  enc;
> 	} inline_ipsec;
> } __rte_cache_aligned;

Assuming that you see the packet with PKT_TX_IPSEC_INLINE_CRYPTO, could you infer these parameters from the packet itself?

> 
> 
> The figure below demonstrates how the new functionality allows the inline crypto acceleration to be integrated into an existing IPsec stack egress path which is using the cryptodev APIs. It is important to note on the data path that the crypto PMD is only processing the metadata of the mbuf and is not modifying the packet payload in anyway. The main function of the crypto PMD in this approach is to support the configuration of the SA material in the hardware using the cryptodev APIs and to enable transparent integration of the inline crypto acceleration into IPsec data path. Only the IPsec stacks control path is aware of the inline processing and is required to use the extra IPsec transform outlined above.
> 
> 
>   Egress Data Path
>           |
> +--------|--------+
> |  egress IPsec   |
> |        |        |
> | +------V------+ |
> | | SABD lookup | |   <------ SA maps to cryptodev session
> | +------|------+ |
> | +------V------+ |
> | |   Tunnel    | |   <------ Add tunnel header to packet
> | +------|------+ |
> | +------V------+ |
> | |     ESP     | |   <------ Add ESP header/trailer to packet
> | +------|------+ |
> | +------|------+ |
> | |      \--------------------\
> | |    Crypto   | |           |  <- Crypto processing through
> | |      /----------------\   |     inline crypto PMD
> | +------|------+ |       |   |
> +--------V--------+       |   |
>           |                |   |
> +--------V--------+       |   |  create   <-- SA is added to hw
> |    L2 Stack     |       |   |  inline       using existing create
> +--------|--------+       |   |  session      sym session APIs
>           |                |   |    |
> +--------V--------+   +---|---|----V---+
> |                 |   |   \---/    |   | <- Set inline crypto offload
> |     NIC PMD     |   |   INLINE   |   |    flag and required metadata
> |                 |   | CRYPTO PMD |   |    to mbuf. Packet data remains
> +--------|--------+   +------------V---+    unmodified.
> 	 |                         |
> +--------|------------+         Add/Remove
> | HW ACCELERATED NIC  |          SA Entry
> |        |-----\      |            |
> |        | +---|----+ |            |
> |        | | Inline |<-------------/
> |        | | Crypto | |
> |        | +---|----+ |  <-- Packet Encryption/Decryption and
> |        |-----/      |      Authentication happens inline
> +--------|------------+
> 	 V
> 
> 
> IXGBE enablement details:
>   - Only AES-GCM 128 ESP Tunnel/Transport mode and Authentication only mode are supported.
> 
> IXGBE PMD:
> 
> Rx Path
>   - To enable decryption for incoming packets 3 tables have to be programmed
>     in the IXGBE device: IP table, SPI table, and Key table. First one has
>     128 entries, the other 2 have 1024. An encrypted packet that need to be
>     decrypted inline needs matching entries in all tables to be processed:
>     destination IP needs to match an entry in the IP table, SPI needs to
>     match and entry in the SPI table, and the SPI table entry needs to have
>     a valid index into the Key table. If all conditions are met then the
>     packet is decrypted and the crypto status is set in the rx descriptors.
>   - After the inline crypto processing the packet is presented to host as a
>     regular rx packet but all IPsec related header are still attached to the packet.
>   - The IXGBE net driver rx path checks the descriptors and based on the
>     crypto status sets additional flags in the rte_mbuf.ol_flags field.
>   - If decryption is succesful, the received packet contains the decrypted
>   data where the encrypted data was when the packet arrived.
>   - In the DPKD crypto PMD side, the rte_mbuf.ol_flags are checked and
>     decryption status set accordingly.
> 
> 
> TX path:
> - For encryption of the outgoing packets there is only one table that
>    contains the key as all the other operations are performed by software.
>    The host need to program this table and set the tx descriptors.
> 
> - The IXGBE net driver tx path checks the additional field
>    rte_mbuf.inline_ipsec, and if the packet needs to be encrypted then the
>    tx descriptors are set accordingly.
> 
> Crypto IXGBE PMD:
> 
>   - implemented IXGBE Crypto driver; mostly pass-through plus error
>   checking for the enque-deque operations and IXGBE crypto engine setup
>   and configuration
> 
> IPsec Gateway Sample Application
> 
>   - ipsec gateway example updated to support inline ipsec
> 
> 
> Radu Nicolau (5):
>   cryptodev: Updated API to add suport for inline IPSec.
>   pci: allow shared device instances.
>   mbuff: added inline IPSec flags and metadata
>   cryptodev: added new crypto PMD supporting inline IPSec for IXGBE
>   examples: updated IPSec sample app to support inline IPSec
> 
>  config/common_base                                 |   7 +
>  drivers/crypto/Makefile                            |   2 +
>  drivers/crypto/ixgbe/Makefile                      |  63 +++
>  drivers/crypto/ixgbe/ixgbe_crypto_pmd_ops.c        | 576 +++++++++++++++++++++
>  drivers/crypto/ixgbe/ixgbe_crypto_pmd_private.h    | 180 +++++++
>  drivers/crypto/ixgbe/ixgbe_rte_cyptodev.c          | 474 +++++++++++++++++
>  .../crypto/ixgbe/rte_pmd_ixgbe_crypto_version.map  |   3 +
>  drivers/net/ixgbe/ixgbe_ethdev.c                   | 128 ++---
>  drivers/net/ixgbe/ixgbe_rxtx.c                     |  22 +-
>  drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c             |  34 ++
>  examples/ipsec-secgw/esp.c                         |   7 +-
>  examples/ipsec-secgw/ipsec.h                       |   2 +
>  examples/ipsec-secgw/sa.c                          | 165 ++++--
>  lib/librte_cryptodev/rte_crypto_sym.h              |  34 +-
>  lib/librte_cryptodev/rte_cryptodev.h               |   5 +-
>  lib/librte_eal/common/eal_common_pci.c             |  15 +-
>  lib/librte_eal/common/include/rte_pci.h            |  18 +-
>  lib/librte_mbuf/rte_mbuf.h                         |  22 +
>  mk/rte.app.mk                                      |   1 +
>  19 files changed, 1625 insertions(+), 133 deletions(-)
>  create mode 100644 drivers/crypto/ixgbe/Makefile
>  create mode 100644 drivers/crypto/ixgbe/ixgbe_crypto_pmd_ops.c
>  create mode 100644 drivers/crypto/ixgbe/ixgbe_crypto_pmd_private.h
>  create mode 100644 drivers/crypto/ixgbe/ixgbe_rte_cyptodev.c
>  create mode 100644 drivers/crypto/ixgbe/rte_pmd_ixgbe_crypto_version.map
> 

This is a nice approach.

We are also working on adding support for IPsec inline crypto in DPDK.
I hope we could submit a RFC with working code soon.

We considered 3 approaches for IPsec inline support:
1. IPsec inline as a cryptodev (like this RFC)
2. IPsec inline as a rte_flow action. (see details below)
3. Mix between approach 2 and approach 3.

In approach 2, there is no need for an additional crypto PMD.
Inline IPsec is exposed as another feature of a NIC PMD.

For the control-path, we introduce a new rte_flow_action_type for crypto
and a flag to mark flows as egress flows.
Then, it is possible to program the SA by calling rte_flow_create with
an appropriate pattern of IP and ESP header fields, and an action that
contains rte_crypto_ipsec_xform as the configuration.

The main benefit of using the rte_flow API is that we can reuse, the
existing API with patterns and actions. For example, it would be
possible to add support for UDP encapsulation of IPsec without
changing the API. Support for VLAN/VXLAN/GRE/etc could be added
similarly to UDP encapsulation.

For the data-path, all is handled in the NIC PMD, during rx/tx_burst.
While, the application marks the packets for encryption in the
transmit path. And it receives packets marked as decrypted/auth-fail
on the receive side.

In approach 3, there is a crypto PMD for configuring the keys, then
the rte_flow_action_type configuration contains the crypto session
and the data-path could go through the crypto PMD as in approach 1.