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

From: "Doherty, Declan" <declan.doherty@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>
Cc: "Coyle, David" <david.coyle@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Ryan, Brendan" <brendan.ryan@intel.com>,
	"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Ruifeng Wang <ruifeng.wang@arm.com>,
	Liron Himi <lironh@marvell.com>,
	Nagadheeraj Rottela <rnagadheeraj@marvell.com>,
	Srikanth Jampala <jsrikanth@marvell.com>,
	Gagandeep Singh <g.singh@nxp.com>,
	Jay Zhou <jianjay.zhou@huawei.com>,
	Ravi Kumar <ravi1.kumar@amd.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing
Date: Wed, 15 Apr 2020 23:19:54 +0100	[thread overview]
Message-ID: <2fa52616-2e81-4eae-a28b-4549154742fe@intel.com> (raw)
In-Reply-To: <4421330.vfdyTQepKt@thomas>

On 14/04/2020 3:44 PM, Thomas Monjalon wrote:
> 14/04/2020 16:02, Trahe, Fiona:
>> Hi Thomas,
>>
>> From: 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?
>>
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.
> 
> 
> 