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

[Radu Nicolau]

In this RFC we introduce a mechanism to support inline hardware acceleration of symmetric crypto processing of IPsec flows on Ethernet adapters within the cryptodev framework, specifically this RFC includes the initial enablement work for the Intel® 82599 10 GbE Controller (IXGBE).

A number of new concepts are proposed to support this model within DPDK.

1. Extension of the librte_cryptodev to support the programming of IPsec Security Association (SA) material as part of crypto session creation including the definition of a new crypto transform type for IPsec to allow programming of the IPsec specific material of the SA in hardware. 
By chaining the IPsec transform with the cipher and/or authentication then the user is able to specify all the information about the SA required by hardware to complete crypto processing inline as well as identify IPsec flows for processing on ingress/egress if the hardware is capable.

+---------------+
|  IPsec xform  |
|  *next;       |--->+----------------+
+---------------+    |  cipher xform  |
                      |  *next;        |-->+--------------+
                      +----------------+   |  auth xform  |
                                           |  *next;      |
                                           +--------------+

enum rte_crypto_ipsec_direction {
         RTE_CRYPTO_INBOUND = 1,
         RTE_CRYPTO_OUTBOUND
};

struct rte_crypto_ipsec_addr {
         enum ip_addr_type {
         	IPV4_ADDRESS,
                 IPV6_ADDRESS
         } type; /**< IP address type IPv4/v6 */

         union {
                 uint32_t  ipv4;         /**< IPv4 Address */
                 uint32_t  ipv6[4];      /**< IPv6 Address */
         }; /**< IP address */
};

struct rte_crypto_ipsec_xform {
         enum rte_crypto_ipsec_direction dir;  /**< Direction - In/Out */
         uint32_t spi;                         /**< SPI */

	struct rte_crypto_ipsec_addr src_ip;
         /**< Source IP */
         struct rte_crypto_ipsec_addr dst_ip;
         /**< Destination IP */
};


2. Introduce the ability to have shared device instance within DPDK. The inline crypto capabilities are provided through the devices phyiscal function, to allow inline processing capabilities to be introduced to DPDK within the minimum impact to the existing infrastructure we propose a model where a NIC and Crypto PMD can share a single pci device. This allows the application interfaces to be consistent with DPDKs existing APIs and programming models as well as providing a mechanism for sharing of access to the PCI bar.

+-----------+    +--------------+
|  NIC PMD  |    |  CRYPTO PMD  |
+-----------+    +--------------+
         \            /
       +----------------+
       | rte_pci_device |
       +----------------+
               |
       +----------------+
       |     PCI BAR    |
       +----------------+

3. The definition of new tx/rx mbuf offload flags to indicate that a packet requires inline crypto processing on to the NIC PMD on transmit and to indicate that a packet has been processed by the inline crypto hardware on ingress.

/**
  * Inline IPSec Rx processed packet
  */
#define PKT_RX_IPSEC_INLINE_CRYPTO  (1ULL << 17)

/**
  * Inline IPSec Rx packet authentication failed
  */
#define  PKT_RX_IPSEC_INLINE_CRYPTO_AUTH_FAILED (1ULL << 18)

/**
  * Inline IPSec Tx process packet
  */
#define PKT_TX_IPSEC_INLINE_CRYPTO  (1ULL << 43)

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;


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

-- 
2.7.4