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

[Thomas Monjalon <thomas@monjalon.net>]

09/05/2017 16:57, 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).

We must stop after this first introduction and think about what
inline crypto processing is.

At the beginning are two types of processing:
- networking Rx/Tx
- crypto
Then we want to combine them in the same device.
We could also try to combine more processing:
- compression
- pattern matching
- etc
We will also probably have in future some devices able to combine
processing or do them separately (inline crypto or simple crypto).

Is there a good way to specify these combinations?
I'm dreaming of a pipeline model with a JIT compiler...

Here we are adding one more layer to the combination of Rx/Tx + crypto:
it is a specific API for IPsec.

One more thing in this landscape:
How the eventdev model propose to combine such processing?

[...]
> 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)

We won't be able to add an offload flag for every protocols.
Can we define a more generic flag for Rx crypto failure?
The type of Rx crypto can be defined as a packet type.
IPsec is exactly the same thing as VLAN to this regard.
Olivier, what do you plan for VLAN flags and packet types?

Where is the item 4? :)

> 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;

I really think we should stop adding such things in the mbuf.
It is convenient for performance, but have we looked at other options?

We cannot reserve a metadata block and share it with other layers, because
it would prevent us from combining offloads of different layers.
And we won't have enough space for every layers.

There was the same discussion when introducing cryptodev. And the
conclusion was to not directly link any crypto metadata to the mbuf.