[dpdk-dev] [PATCH v2 3/6] crypto/aesni_mb: add support for DOCSIS protocol

De Lara Guarch, Pablo pablo.de.lara.guarch at intel.com
Tue Jun 23 19:57:06 CEST 2020


Hi David,

> -----Original Message-----
> From: Coyle, David <david.coyle at intel.com>
> Sent: Tuesday, June 23, 2020 11:14 AM
> To: akhil.goyal at nxp.com; Doherty, Declan <declan.doherty at intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Trahe, Fiona
> <fiona.trahe at intel.com>; Zhang, Roy Fan <roy.fan.zhang at intel.com>;
> Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: dev at dpdk.org; thomas at monjalon.net; Yigit, Ferruh
> <ferruh.yigit at intel.com>; Ryan, Brendan <brendan.ryan at intel.com>;
> hemant.agrawal at nxp.com; anoobj at marvell.com; ruifeng.wang at arm.com;
> lironh at marvell.com; rnagadheeraj at marvell.com; jsrikanth at marvell.com;
> G.Singh at nxp.com; jianjay.zhou at huawei.com; ravi1.kumar at amd.com;
> Richardson, Bruce <bruce.richardson at intel.com>; olivier.matz at 6wind.com;
> honnappa.nagarahalli at arm.com; stephen at networkplumber.org;
> alexr at mellanox.com; jerinj at marvell.com; Coyle, David
> <david.coyle at intel.com>; O'loingsigh, Mairtin <mairtin.oloingsigh at intel.com>
> Subject: [PATCH v2 3/6] crypto/aesni_mb: add support for DOCSIS protocol
> 
> Add support to the AESNI-MB PMD for the DOCSIS protocol, through the
> rte_security API. This, therefore, includes adding support for the rte_security API
> to this PMD.
> 
> Signed-off-by: David Coyle <david.coyle at intel.com>
> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh at intel.com>

...

> +static inline void
> +verify_docsis_sec_crc(JOB_AES_HMAC *job, uint16_t crc_len, uint8_t
> +*status) {
> +	uint16_t crc_offset;
> +	uint8_t *crc;
> +
> +	if (!job->msg_len_to_hash_in_bytes)
> +		return;
> +
> +	crc_offset = job->hash_start_src_offset_in_bytes +
> +			job->msg_len_to_hash_in_bytes -
> +			job->cipher_start_src_offset_in_bytes;
> +	crc = job->dst + crc_offset;
> +
> +	/* Verify CRC (at the end of the message) */
> +	if (memcmp(job->auth_tag_output, crc, crc_len) != 0)

I'd say we can use direct RTE_ETHER_CRC_LEN here, as there is no other possible case, right?
It should perform better.

> +		*status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED; } #endif
> +
>  static inline void
>  verify_digest(JOB_AES_HMAC *job, void *digest, uint16_t len, uint8_t *status)  {
> @@ -1196,9 +1452,27 @@ static inline struct rte_crypto_op *
> post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)  {
>  	struct rte_crypto_op *op = (struct rte_crypto_op *)job->user_data;
> -	struct aesni_mb_session *sess = get_sym_session_private_data(
> -							op->sym->session,
> -							cryptodev_driver_id);
> +	struct aesni_mb_session *sess = NULL;
> +
> +#ifdef AESNI_MB_DOCSIS_SEC_ENABLED
> +	struct rte_security_op *sec_op = NULL;
> +
> +	if (unlikely(op->type == RTE_CRYPTO_OP_TYPE_SECURITY)) {

Not sure if this unlikely is actually needed. I don't expect to have multiple types enqueued in the same queue,
so this or the other branch will always be taken.

> +		/*
> +		 * Assuming at this point that if it's a security type op, that
> +		 * this is for DOCSIS
> +		 */
> +		sec_op = (struct rte_security_op *)&op->security;
> +		struct rte_crypto_sym_op *crypto_sym =
> +						&sec_op->docsis.crypto_sym;
> +		sess = get_sec_session_private_data(crypto_sym-
> >sec_session);

...

> -		retval = set_mb_job_params(job, qp, op, &digest_idx);
> +#ifdef AESNI_MB_DOCSIS_SEC_ENABLED
> +		if (unlikely(op->type == RTE_CRYPTO_OP_TYPE_SECURITY))

Same comment as above.

> +			retval = set_sec_mb_job_params(job, qp, op,
> +						&digest_idx);
> +		else
> +#endif



More information about the dev mailing list