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

["Trahe, Fiona" <fiona.trahe@intel.com>]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, April 14, 2020 2:24 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Cc: Coyle, David <david.coyle@intel.com>; dev@dpdk.org; Doherty, Declan
> <declan.doherty@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Ryan,
> Brendan <brendan.ryan@intel.com>; shreyansh.jain@nxp.com; hemant.agrawal@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>; Trahe, Fiona <fiona.trahe@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/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?
[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.