Re: [dpdk-dev] [PATCH v2 0/4] introduce multi-function processing support

["Coyle, David" <david.coyle@intel.com>]

Hi Ferruh, see below

> >
> > While DPDK's rte_cryptodev and rte_compressdev allow many
> > cryptographic and compression algorithms to be chained together in one
> > operation, there is no way to chain these with any error detection or
> > checksum algorithms. And there is no way to chain crypto and
> > compression algorithms together. The multi-function  interface will
> > allow these chains to be created, and also allow any future type of
> operation to be easily added.
> 
> I was thinking if the cryptodev can be used instead but this paragraph already
> seems explained it. But again can you please elaborate why rawdev is used?

[DC] There are a number of reasons the rawdev approach was ultimately chosen:

1) As the paragraph above explains, our primary use-case was to chain a crypto operation with error detection algorithms such as CRC or BIP as this could leverage optimized multi-function implementations such as in the IPSec Multi-Buffer library and have a significant impact on performance of network access dataplane processing such as for vCMTS (DOCSIS MAC).
However such error detection algorithms are not Crypto functions so some early advice we took was that it would not be suitable to add these to cryptodev.
Also, with a view to the future, the multi-function rawdev approach allows crypto operations to be chained with compression operations.
Again, neither cryptodev or compressdev allows this type chaining.

2) An earlier version of multi-function suggested adding a new library called rte_accelerator, as described here http://mails.dpdk.org/archives/dev/2020-February/157045.html
We received some comments on the dev mailing list that we should not add yet another acceleration library to DPDK.
And we also subsequently felt that the rawdev approach is better - that rationale is described below.

rte_accelerator was also built on top of crypto and compress devices which already existed e.g. drivers/crypto/aesni_mb, drivers/crypto/qat and drivers/compress/qat .
We subsequently realized that this was somewhat confusing when performing multi-function type operations. For example, for combined Crypto-Compression operations in the future, it would use either an existing crypto or compress device, but neither really made sense when the operations are combined.
What was needed was a raw device which allowed an application to configure any type of device and it's queue pairs and send any type of operation to that device.

For both of these reasons, we decided to go down the rawdev route, with a multi-function interface which can be used by several raw device drivers.

3) rawdev is the ideal place to try out a new approach like this to accessing devices.
Adding it here allows potential consumers of this such as VNF solution providers to study and try out this approach, and take advantage of the multi-function operations already supported in the IPSec Multi-Buffer library such as Crypto-CRC and Crypto-CRC-BIP, all without DPDK committing to a new library upfront.
We would hope that the multi-function rawdev approach will mature over time (through feedback from customers, new use-cases arising etc.), at which point it could be potentially be moved into the main DPDK library set.

> 
> >
> >
> >
> 
> <...>