DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <gakhil@marvell.com>
To: "Kundapura, Ganapati" <ganapati.kundapura@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>,
	"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"fanzhang.oss@gmail.com" <fanzhang.oss@gmail.com>,
	"ciara.power@intel.com" <ciara.power@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>
Subject: RE: [EXTERNAL] [PATCH v2 1/2] crypto: fix build issues on unsetting crypto callbacks macro
Date: Thu, 30 May 2024 11:46:45 +0000	[thread overview]
Message-ID: <CO6PR18MB4484CB9A7040AE71A6E7411CD8F32@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <MW4PR11MB5911BEB3B95B8C0FCACD9D2B87F32@MW4PR11MB5911.namprd11.prod.outlook.com>

> > > #if may not be needed in application.
> > > Test should be skipped if API is not available/supported.
> > >
> It's needed otherwise application developer has to check the implementation for
> supported/not supported or else
> run the application to get to know whether api is supported or not.
> 

Application is always required to check the return value
or else it will miss the other errors that the API can return.

> > > > diff --git a/lib/cryptodev/rte_cryptodev.c
> > > > b/lib/cryptodev/rte_cryptodev.c index 886eb7a..2e0890f 100644
> > > > --- a/lib/cryptodev/rte_cryptodev.c
> > > > +++ b/lib/cryptodev/rte_cryptodev.c
> > > > @@ -628,6 +628,7 @@
> > rte_cryptodev_asym_xform_capability_check_hash(
> > > >  	return ret;
> > > >  }
> > > >
> > > > +#if RTE_CRYPTO_CALLBACKS
> > > >  /* spinlock for crypto device enq callbacks */  static
> > > > rte_spinlock_t rte_cryptodev_callback_lock =
> > > RTE_SPINLOCK_INITIALIZER;
> > > >
> > > > @@ -744,6 +745,7 @@ cryptodev_cb_init(struct rte_cryptodev *dev)
> > > >  	cryptodev_cb_cleanup(dev);
> > > >  	return -ENOMEM;
> > > >  }
> > > > +#endif /* RTE_CRYPTO_CALLBACKS */
> > >
> > >
> > > > @@ -1485,6 +1491,7 @@ rte_cryptodev_queue_pair_setup(uint8_t
> > dev_id,
> > > > uint16_t queue_pair_id,
> > > >  			socket_id);
> > > >  }
> > > >
> > > > +#if RTE_CRYPTO_CALLBACKS
> > > >  struct rte_cryptodev_cb *
> > > >  rte_cryptodev_add_enq_callback(uint8_t dev_id,
> > > >  			       uint16_t qp_id,
> > > > @@ -1763,6 +1770,7 @@ rte_cryptodev_remove_deq_callback(uint8_t
> > dev_id,
> > > >  	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> > > >  	return ret;
> > > >  }
> > > > +#endif /* RTE_CRYPTO_CALLBACKS */
> > >
> > > There is an issue here.
> > > The APIs are visible in .h file and are available for application to use.
> > > But the API implementation is compiled out.
> > > Rather, you should add a return ENOTSUP from the beginning of the APIs
> > > if RTE_CRYPTO_CALLBACKS  is enabled.
> > > With this approach application will not need to put #if in its code.
> API declarations wrapped under the macro changes in next patch.

No, that is not the correct way. Application should check the return value.
And we cannot force it to add ifdefs.

  reply	other threads:[~2024-05-30 11:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  8:12 [PATCH v1] crypto: fix build issues on crypto callbacks macro undefined 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 ` [EXTERNAL] " Akhil Goyal
2024-05-29  9:57   ` 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 [this message]
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=CO6PR18MB4484CB9A7040AE71A6E7411CD8F32@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=mb@smartsharesystems.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).