DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <gakhil@marvell.com>
To: Ganapati Kundapura <ganapati.kundapura@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>
Cc: "abhinandan.gujjar@intel.com" <abhinandan.gujjar@intel.com>,
	"ciara.power@intel.com" <ciara.power@intel.com>,
	"fanzhang.oss@gmail.com" <fanzhang.oss@gmail.com>
Subject: RE: [EXTERNAL] [PATCH v1] crypto: fix build issues on crypto callbacks macro undefined
Date: Wed, 29 May 2024 08:35:23 +0000	[thread overview]
Message-ID: <CO6PR18MB44846BAA0AE75E789078B73FD8F22@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20240416081222.3002268-1-ganapati.kundapura@intel.com>

> Crypto callbacks macro is defined with value 1 and being used with ifdef,
> on config value is changed to 0 to disable, crypto callback changes
> still being compiled.

I believe we can use #if instead of ifdefs.
It seems convenient to enable/disable in my opinion.
We can use both, but whatever we use should be same as that for ethdev callbacks.

The same issue would be for ethdev callbacks too.
Ferruh, can you check?

> 
> Defined crypto callbacks macro without value, undef to disable
> 
> Wrapped crypto callback changes with RTE_CRYPTO_CALLBACKS macro
> to fix build issues when macro is undefined.
> 
> As callback head nodes have valid pointer, this patch checks the next
> node from the head if callbacks registered.
> 
> Fixes: 1c3ffb9 ("cryptodev: add enqueue and dequeue callbacks")
> Fixes: 5523a75 ("test/crypto: add case for enqueue/dequeue callbacks")
> 
> Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>


> diff --git a/config/rte_config.h b/config/rte_config.h
> index dd7bb0d35b..b647a69ba8 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -72,7 +72,7 @@
>  /* cryptodev defines */
>  #define RTE_CRYPTO_MAX_DEVS 64
>  #define RTE_CRYPTODEV_NAME_LEN 64
> -#define RTE_CRYPTO_CALLBACKS 1
> +#define RTE_CRYPTO_CALLBACKS	/* No Value, undef/comment out to
> disable */
> 
>  /* compressdev defines */
>  #define RTE_COMPRESS_MAX_DEVS 64


> diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
> index 00ba6a234a..b811b458d5 100644
> --- a/lib/cryptodev/rte_cryptodev.h
> +++ b/lib/cryptodev/rte_cryptodev.h
> @@ -1910,7 +1910,7 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id,
> uint16_t qp_id,
>  	nb_ops = fp_ops->dequeue_burst(qp, ops, nb_ops);
> 
>  #ifdef RTE_CRYPTO_CALLBACKS
> -	if (unlikely(fp_ops->qp.deq_cb != NULL)) {
> +	if (unlikely(fp_ops->qp.deq_cb[qp_id].next != NULL)) {
>  		struct rte_cryptodev_cb_rcu *list;
>  		struct rte_cryptodev_cb *cb;
> 
> @@ -1977,7 +1977,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id,
> uint16_t qp_id,
>  	fp_ops = &rte_crypto_fp_ops[dev_id];
>  	qp = fp_ops->qp.data[qp_id];
>  #ifdef RTE_CRYPTO_CALLBACKS
> -	if (unlikely(fp_ops->qp.enq_cb != NULL)) {
> +	if (unlikely(fp_ops->qp.enq_cb[qp_id].next != NULL)) {
>  		struct rte_cryptodev_cb_rcu *list;
>  		struct rte_cryptodev_cb *cb;
> 
This is a separate issue. Please create a separate patch.

  parent reply	other threads:[~2024-05-29  8:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  8:12 Ganapati Kundapura
2024-04-16  9:16 ` Gujjar, Abhinandan S
2024-04-17 11:40 ` Power, Ciara
2024-05-22  8:51   ` Kundapura, Ganapati
2024-05-22  8:55     ` Akhil Goyal
2024-05-22 13:51       ` Akhil Goyal
2024-05-22 14:45         ` Kundapura, Ganapati
2024-05-22 18:36           ` Akhil Goyal
2024-05-23  8:54             ` Kundapura, Ganapati
2024-05-29  8:35 ` Akhil Goyal [this message]
2024-05-29  9:57   ` [EXTERNAL] " Kundapura, Ganapati
2024-05-29 11:40     ` Akhil Goyal
2024-05-29 14:40 ` [PATCH v2 1/2] crypto: fix build issues on unsetting crypto callbacks macro Ganapati Kundapura
2024-05-29 14:40   ` [PATCH v2 2/2] crypto: validate crypto callbacks from next node Ganapati Kundapura
2024-05-30  8:13     ` [EXTERNAL] " Akhil Goyal
2024-05-30  8:12   ` [EXTERNAL] [PATCH v2 1/2] crypto: fix build issues on unsetting crypto callbacks macro Akhil Goyal
2024-05-30 11:01     ` Akhil Goyal
2024-05-30 11:13       ` Morten Brørup
2024-05-30 11:41         ` Kundapura, Ganapati
2024-05-30 11:45           ` Morten Brørup
2024-05-30 11:40       ` Kundapura, Ganapati
2024-05-30 11:46         ` Akhil Goyal
2024-05-30 11:52           ` Morten Brørup
2024-05-30 14:22           ` Kundapura, Ganapati
2024-05-30 14:49             ` Morten Brørup
2024-06-06  9:44               ` Akhil Goyal
2024-06-13 18:03                 ` Akhil Goyal
2024-06-20 14:34                   ` Kundapura, Ganapati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO6PR18MB44846BAA0AE75E789078B73FD8F22@CO6PR18MB4484.namprd18.prod.outlook.com \
    --to=gakhil@marvell.com \
    --cc=abhinandan.gujjar@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=ciara.power@intel.com \
    --cc=dev@dpdk.org \
    --cc=fanzhang.oss@gmail.com \
    --cc=ferruh.yigit@amd.com \
    --cc=ganapati.kundapura@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).