Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing

[Thomas Monjalon <thomas@monjalon.net>]

14/04/2020 15:04, Trahe, Fiona:
> > 14/04/2020 12:21, Ferruh Yigit:
> > http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30@MN2PR11MB3550.na
> > mprd11.prod.outlook.com/
> > 
> > I am not convinced.
> > I don't like rawdev in general.
> > Rawdev is good only for hardware support which cannot be generic
> > like SoC, FPGA management or DMA engine.
> 
> [Fiona] CRC and BIP are not crypto algorithms, they are error detection processes.
> So there is no class in DPDK that these readily fit into.
> There was resistance to adding another xxxddev, and even if one had been added
> for error_detection_dev, there would still have been another layer needed
> to couple this with cryptodev. Various proposals for this have been discussed on the ML
> in RFC and recent patches, there doesn't seem to be an appetite for this as a generic API. 
> So it seems that only Intel has software and hardware engines that provide this
> specialised feature coupling. In that case rawdev seems like the most
> appropriate vehicle to expose this.

Adding some vendor-specific API is not a good answer.
It will work in some cases, but it won't make DPDK better.
What's the purpose of DPDK if it's not solving a common problem
for different hardware?

> > Here the intent is to use rawdev because we don't find a good API.
> > API defeat is a no-go.
> 
> [Fiona] It's not that we haven't found a good API, but that there doesn't seem
> to be a general requirement for such a specialised API

There is a requirement to combine features of different classes.
In the past, rte_security was an "answer" to this issue with crypto and ethdev.
This is a real topic, please let's find a generic elegant solution.