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

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

Hi Thomas, David, Ferruh,

> -----Original Message-----
> Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing
> 
> 14/04/2020 12:21, Ferruh Yigit:
> > On 4/10/2020 11:55 PM, Thomas Monjalon wrote:
> > > Hi,
> > >
> > > Adding more people (crypto PMD maintainers) as Cc.
> > >
> > > 10/04/2020 16:27, David Coyle:
> > >> Introduction
> > >> ============
> > >>
> > >> This patchset adds a new AESNI-MB Multi-Function raw device PMD for
> > >> utilizing multi-function capabilities of the Intel IPSec Multi Buffer
> > >> library.
> > >>
> > >> The aim of this rawdev PMD is to provide a way of combining one or more
> > >> common packet-processing functions into a single operation, focused on
> > >> DOCSIS and GPON MAC workloads. This allows these functions to be performed
> > >> in parallel by the Intel IPSec Multi Buffer library. These functions
> > >> include cryptography and CRC/BIP calculations. Performing these functions
> > >> in parallel as a single operation can enable a significant performance
> > >> improvement.
> > >
> > > I don't know crypto but I don't think using rawdev for crypto operations
> > > is an API improvement.
> > >
> > > Repeating the initial comments from v1 (because got no reply):
> > > "
> > > As a first impression, I feel it is not the right API.
> > > DPDK is based on classes: ethdev, crypto, compress, baseband, regex
> > > I want to understand why your features cannot fit in a class.
> >
> > Hi Thomas,
> >
> > I asked similar question, and there is already a detailed answer with some
> > background of the issue:
> 
> Good to see that you get some reply, Ferruh.
> 
> >
> 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.


> 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