On 10/05/2017 5:07 PM, Boris Pismenny wrote:
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?
In our case this isn't really possible as each packet in a burst could
be be associated with a different security association/crypto session
and will also have different lengths/padding etc. We could use some sort
of cookie to store this, but I think it would have a big performance
impact. I do think that this structure in the mbuf should not be device
specific as it is now for the required metadata, but I would like to
guarantee that the metadata is in the mbuf.
....
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.
Iis your device capable of full IPsec protocol processing, ESP header
insertion, encap/decap etc? In our case the inline functionality is
limited to the crypto processing, so we are working on the assumption
that the user will be integrating with an existing IPsec stack. On
ingress the lookup is based on the Destination IP and SPI, on egress the
metadata is
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.
This make sense when hw is capable of full offload. So the rte_flow
actions might be VxLAN and ESP Tunnel for a flow. The other approach is
that to separate rules are created one for IPsec, then a second for the
VxLAN tunnel which trigger on the IPsec flow, but this probably implies
that either the PMD flattens these flow actions into a single action or
the hw supports re circulation. One concern I would have is population
of the namespace of rte_flow with IPsec/crypto session material, but I
guess it should be possible to come up with a clean way of supporting this.
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.
when you say the application marks the packet, this is essentially the
IPsec stack? The main benefit in the approach of this RFC is that it is
possible to integrate the inline crypto processing transparently in the
data path. The crypto PMD can handle setting and interpreting the
metadata required and the IPsec stack is just using the crypto PMD as it
would any other crypto PMD.
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.
