Re: [dpdk-dev] [PATCH v2 2/6] security: add support for DOCSIS protocol

["Coyle, David" <david.coyle@intel.com>]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, June 23, 2020 7:07 PM
> >
> > +/**
> > + * DOCSIS operation parameters
> > + */
> > +struct rte_security_docsis_op {
> > +	struct rte_crypto_sym_op crypto_sym;
> > +	/**< Symmetric crypto operation parameters */
> > +
> > +	struct {
> > +		uint16_t offset;
> > +		/**<
> > +		 * Starting point for CRC processing, specified
> > +		 * as the number of bytes from start of the packet in
> > +		 * the source mbuf in crypto_sym
> > +		 */
> > +		uint16_t length;
> > +		/**<
> > +		 * The length, in bytes, of the source mbuf on which the
> > +		 * CRC will be computed
> > +		 */
> > +	} crc;
> > +	/**< CRC operation parameters */
> 
> As per my understanding, CRC is a kind of authentication. Can we reuse the
> fields of rte_crypto_sym_op Auth.data.offset and auth.data.length. This way
> you can save the unnecessary 4 bytes here. Probably add Comment in the
> structure definition that it can be used as offset and length for CRC.
> 
> And if you feel that reserved field is needed in near future, then you can add
> a proper name to it or else You can do away with the rte_security_docsis_op
> itself as there will be no other fields in it.

[DC] As per my reply on the v1 patchset, I am happy to use the auth offset and
length fields for CRC if there are no objections from others on this approach.

Strictly speaking, a CRC is not an authentication algorithm like the other auth
algos in cryptodev - if it were we would have just added CRC as a new auth algo.
However, using the auth offset and length fields of the crypto op does simplify
things, removes unnecessary bytes and levels of indirection. It also means the
'uint8_t security[0]' field can be removed from rte_crypto_op.

The 'reserved' field was to accommodate other DOCSIS protocol features which
could be offloaded in the future - such as the DOCSIS header checksum. For this
feature, we would need to know the DOCSIS header length. The header length
though is equal to the CRC offset, so we can get the header length that way.
The reserved field and the entire rte_security_docsis_op can therefore be
removed