[dpdk-dev] [PATCH 2/3] cryptodev: add security operation to crypto operation

[Coyle, David]

Hi Akhil

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal at nxp.com>
> Sent: Tuesday, June 23, 2020 7:38 PM
> > > >
> > > [DC] It's certainly an option and would work but I don't think it's
> > > a good idea to
> > be putting
> > > protocol specific structs like this in rte_cryptodev - that's what
> > > rte_security is
> > for.
> > > Do you think it would be ok to do this?
> >
> > I personally don't see a problem with this.
> > In fact, as an extra  thought - why we can't have docsis xform defined
> > in lib/librte_cryptodev/rte_crypto_sym.h too, and then just have it
> > as a member inside struct rte_crypto_sym_xform union?
> > Then we can have rte_cryptodev_sym_session that supports docsis stuff.
> 
> Adding DOCSIS alone is not an issue in the cryptodev. The intent of this
> patchset and Previous RFCs was chaining of two - DOCSIS and CRC which are
> supposed to be separate Blocks and we need a way to combine the two and
> use it in the application.
> rte_security provides a way to handle such protocols for algo combinations.
> However, IMO we do not really need a separate rte_security_docsis_op
> structure, As it has parameters which are already there in the
> rte_crypto_sym_op. This new op Struct is just adding extra bytes which can
> be avoided if we use sym_op->auth.data.offset And sym_op-
> >auth.data.length in place of crc offset and crc length.
> We may just need to add comment in the struct definition about its usage for
> CRC cases.
> 
[DC] I take your point that introducing the rte_security_docsis_op (and the outer
rte_security_op) structure is just adding extra bytes and as Konstantin mentioned,
unnecessary levels of indirection. I am happy to go with the approach of using the
auth offset and length from the sym_op for the CRC values, if there are no major
objections from others on this. This simplifies things and also means we can now
remove the 'uint8_t security[0]' field from rte_crypto_op which was never a nice
thing.

Konstantin also suggested moving the docsis xform to cryptodev. However, I
feel this would be a step too far for cryptodev and propose we keep the docsis
xform in rte_security. It is then consistent with the other protocols like IPSec.