[dpdk-dev] Inline/look-aside transformation API (Crypto, IPsec, VLAN insertion, Compression, ...)

[dpdk-dev] Inline/look-aside transformation API (Crypto, IPsec, VLAN insertion, Compression, ...)

[Nelio Laranjeiro]

Hi all,

I would like to raise an issue to open a more generic discussion,

This concern comes from the issues I am currently facing with rte_security
where there will be 3 different configuration code paths and 2 different
datapath depending on the NIC capability [1][2].  This bring a real
complexity for an application as it will have to use different code
paths for each device/port.

This brings a more general issue concerning such devices which are able to
offload any kind of transformation.  For that, new API are starting to appear
(rte_security, Compression) from a generic point of view, it is a
transformation API which is necessary with transformation actions.

Looking into this last point, seems we already have a generic way to
handle it through the generic flow API which matches a pattern and make
actions on it, those actions can finally be something like:

 xfrm-crypto algo <algo> hashkey <key> salt <salt> offset <offset>

or

 xfrm-compress algo <algo> ...

It could also be used to make multiple transformation on a single flow
like:

 xfrm-vlan tci 10 / xfrm-compress ... / xfrm-ipsec-encap ... / xfrm-crypto ...
 .................................... / xfrm-macsec-encap ... / xfrm-crypto ...

The missing point seems to be the metadata such offloads may need to
handle the job which is per packet.  For such situation we could
eventually use a pointer to a list of offloads request passing among the
packet directly inside the mbuf or in a new argument of {rx,tx}_burst().
This part is more complex to design to avoid huge performance
degradation in both applications and PMD.

The point is, adding new offload bits in the mbuf are not unlimited whereas
the possibilities of those "smart" NIC are, at some moment we will be stuck.
We can avoid it with such kind of approach.

Pros:

 - Adding new actions/offloads don't break API/ABI.
 - No need for offload capabilities bits/API, an offload request through
   rte_flow is enough to know both: offload capabilities and if it is
   applicable on the pattern.
 - An easier and flexible way to combine transformations.

This is still an idea which needs more meditation.

Thoughts?

Thanks,

[1] https://dpdk.org/browse/dpdk/tree/examples/ipsec-secgw/ipsec.c#n50
[2] https://dpdk.org/ml/archives/dev/2017-December/083983.html

-- 
Nélio Laranjeiro
6WIND