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

[Thomas Monjalon]

16/04/2020 00:19, Doherty, Declan:
> On 14/04/2020 3:44 PM, Thomas Monjalon wrote:
> > 14/04/2020 16:02, Trahe, Fiona:
> >> 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.

Because hardware support is pending,
we should accept an Intel-only "temporary" solution,
opening the door to more vendor-specific APIs?

What is the benefit for the DPDK project?


> >> 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)

Doing IPsec processing in Rx or Tx of a NIC is not chaining?


> >> 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.