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

From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Coyle, David" <david.coyle@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>
Cc: "techboard@dpdk.org" <techboard@dpdk.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	 "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
	"Ryan, Brendan" <brendan.ryan@intel.com>,
	"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>,
	Hemant Agrawal <hemant.agrawal@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>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"alexr@mellanox.com" <alexr@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing
Date: Wed, 22 Apr 2020 10:51:21 +0000	[thread overview]
Message-ID: <VI1PR04MB3168E9EBC37EEAABC6A5F027E6D20@VI1PR04MB3168.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <MN2PR11MB3550E8BF5E2662924C646DDFE3D50@MN2PR11MB3550.namprd11.prod.outlook.com>

Hi David,
> > >>
> > >> 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?
> > >
> > I wouldn't consider an inline crypto offload or full IPsec offload a chained
> > operation in the vein being proposed here where completely independent
> > services (in the view of DPDK which are currently on independent devices
> > and APIs) are linked together.
> >
> > We did look at using rte_security here but it wasn't considered suitable for a
> > chaining of non-crypto operations such as CRC or possibly compression in the
> > future, as it would still run into the issue of having to use the cryptodev
> > enq/deq API in the lookaside offload case.
> >
> >
I did not look at your patches completely, but looking at the ops that you have added
For rawdev are pretty much same as that of a crypto device.

I see that there are 2 types of ops that you need
- session create/destroy
- enq/deq

On the first impression of your patchset, I see that you want to enq to driver only once for both
The operations - CRC and crypto.

So what is the issue in using the cryptodev_enqueue for processing in the existing AESNI-MB driver.
For session creation, the cryptodev layer will not give flexibility to add CRC+crypto kind of sessions.
But in case of rte_security, you can define your new session xform based on your requirement.

And while doing the cryptodev enq/deq, based on the session type, you can process the packet
Specific to your usecase in your aesni-mb PMD

Now if you want to add compression also along with crypto, then you can define another xform which
Will be combination of crypto+compression and the aesni-mb PMD can have another mode which
Can make sessions based on the new xform and the enq and deq can be done using the cryptodev enq/deq.
For all your cases you will be having only one action type - lookaside protocol and can define different
Protocols (that may not be standard).

So to conclude, your AESNI-MB will have 3 types of operations
- plain crypto
- crc+crypto
- compression+crypto

I believe this is doable or did I miss something very obvious?

Regards,
Akhil