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

[Doherty, Declan]

On 14/04/2020 3:44 PM, Thomas Monjalon wrote:
> 14/04/2020 16:02, Trahe, Fiona:
>> Hi Thomas,
>>
>> From: Thomas Monjalon <thomas at 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?
>>
The current proposal in rawdev could easily be supported by any hardware 
which supports chaining multiple functions/services into a single 
operation, in this case symmetric crypto and error detection, but it 
could conceivably support chaining symmetric/asymmetric crypto 
operations or chaining symmetric crypto and compression operations.

>> [Fiona] Based on that logic rawdev should be deprecated.
>> But the community has agreed that it has a place.
> 
> No, as I said above, rawdev is good for SoC, FPGA management or DMA engine.

I distinctly remember when rawdev was being proposed one of the uses 
cases proposed was that a new classes of APIs could be prototyped and 
developed under rawdev and when a solid consensus was reached then 
migrated to a mainstream DPDK library. I think every effort has been 
made here to engage the community to develop a generic approach. As 
Fiona notes there hasn't really been much of an appetite for this.

Therefore I think the option to use rawdev makes sense, it allows an 
initial proposal to be deployed,  without a generic solution agreement, 
it will also give others in the community to see how this approach can 
work and hopefully lead to more engagement on a generic solution. Also 
as APIs in rawdev are essentially treated as private APIs the onus is on 
Intel to support this going forward.

> 
>> And the common problem here is device exposure.
>> With a specialised service on top.
>>
>>
>>>>> 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.
>>
>> [Fiona] Can you point me to that requirement please?
> 
> Yes, rte_security is trying to address this exact issue.
> 

I don't agree rte_security addresses the problem of different device 
types supporting the same services. The problem being addressed here is 
a single device which supports the chaining of multiple services (sym 
crypto & error detection)

>> We suggested it, but did not get community engagement and have
>> dropped our generic API requirement, instead focussing on this specialised case.
> 
> I did not see such generic proposal, sorry.
> 
>>> 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.
> 
> 
>