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 <tho...@monjalon.net> > >>> 14/04/2020 15:04, Trahe, Fiona: > >>>>> 14/04/2020 12:21, Ferruh Yigit: > >>>>> > >>> http://inbox.dpdk.org/dev/mn2pr11mb35507d4b96677a41e66440c5e3...@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.
