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
