Hi Thomas, > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Tuesday, April 14, 2020 2:24 PM > To: Yigit, Ferruh <ferruh.yi...@intel.com>; Trahe, Fiona > <fiona.tr...@intel.com> > Cc: Coyle, David <david.co...@intel.com>; dev@dpdk.org; Doherty, Declan > <declan.dohe...@intel.com>; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; Ryan, > Brendan <brendan.r...@intel.com>; shreyansh.j...@nxp.com; > hemant.agra...@nxp.com; > akhil.go...@nxp.com; Anoob Joseph <ano...@marvell.com>; Ruifeng Wang > <ruifeng.w...@arm.com>; Liron Himi <lir...@marvell.com>; Nagadheeraj Rottela > <rnagadhee...@marvell.com>; Srikanth Jampala <jsrika...@marvell.com>; > Gagandeep Singh > <g.si...@nxp.com>; Jay Zhou <jianjay.z...@huawei.com>; Ravi Kumar > <ravi1.ku...@amd.com>; > Richardson, Bruce <bruce.richard...@intel.com>; Trahe, Fiona > <fiona.tr...@intel.com> > Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function > processing > > 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? [Fiona] Based on that logic rawdev should be deprecated. But the community has agreed that it has a place. 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? We suggested it, but did not get community engagement and have dropped our generic API requirement, instead focussing on this specialised case. > 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.
