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.
