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

[Akhil Goyal]

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