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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 4/7/2020 12:27 PM, Coyle, David wrote:
> 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.
> 

Sounds good to me, thank you for detailed explanation.