Hi Akhil > -----Original Message----- > From: Akhil Goyal <akhil.go...@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.