DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <gakhil@marvell.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	fengchengwen <fengchengwen@huawei.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	Anoob Joseph <anoobj@marvell.com>,
	"pablo.de.lara.guarch@intel.com" <pablo.de.lara.guarch@intel.com>,
	"fiona.trahe@intel.com" <fiona.trahe@intel.com>,
	"declan.doherty@intel.com" <declan.doherty@intel.com>,
	"matan@nvidia.com" <matan@nvidia.com>,
	"g.singh@nxp.com" <g.singh@nxp.com>,
	"fanzhang.oss@gmail.com" <fanzhang.oss@gmail.com>,
	"jianjay.zhou@huawei.com" <jianjay.zhou@huawei.com>,
	"asomalap@amd.com" <asomalap@amd.com>,
	"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
	"konstantin.v.ananyev@yandex.ru" <konstantin.v.ananyev@yandex.ru>,
	"radu.nicolau@intel.com" <radu.nicolau@intel.com>,
	"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
	Nagadheeraj Rottela <rnagadheeraj@marvell.com>,
	"mdr@ashroe.eu" <mdr@ashroe.eu>
Subject: RE: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs
Date: Mon, 23 Sep 2024 20:41:31 +0000	[thread overview]
Message-ID: <CO6PR18MB4484DA9201E6A66186079C00D86F2@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6AD@smartserver.smartshare.dk>

Hi Morten,

Apologies for delayed response.
> Maybe a combination, returning the lowest end of the two versions of the list,
> would work...
> 
> ----------------------------------
> Common header file (rte_common.h):
> ----------------------------------
> 
> /* Add at end of enum list in the header file. */
> #define RTE_ENUM_LIST_END(name) \
> _ # name # _ENUM_LIST_END /**< @internal */
> 
> /* Add somewhere in header file, preferably after the enum list. */
> #define rte_declare_enum_list_end(name) \
> /** @internal */ \
> int _# name # _enum_list_end(void); \
> \
> static int name # _enum_list_end(void) \
> { \
> 	static int cached = 0; \
> \
> 	if (likely(cached != 0)) \
> 		return cached; \
> \
> 	return cached = RTE_MIN( \
> 			RTE_ENUM_LIST_END(name), \
> 			_ # name # _enum_list_end()); \
> } \
> \
> int _# name # _enum_list_end(void)
> 
> /* Add in the library/driver implementation. */
> #define rte_define_enum_list_end(name) \
> int _# name # _enum_list_end(void) \
> { \
> 	return RTE_ENUM_LIST_END(name); \
> } \
> \
> int _# name # _enum_list_end(void)
> 
> --------------------
> Library header file:
> --------------------
> 
> enum rte_crypto_asym_op_type {
> 	RTE_CRYPTO_ASYM_OP_VERIFY,
> 	/**< Signature Verification operation */
> 	RTE_ENUM_LIST_END(rte_crypto_asym_op)

Will the ABI check be ok for adding anything in between 
RTE_CRYPTO_ASYM_OP_VERIFY and RTE_ENUM_LIST_END(rte_crypto_asym_op)?
Don’t we need to add exception for that if we somehow make it internal by adding a comment only?
Library is actually not restricting the application to not use RTE_ENUM_LIST_END(rte_crypto_asym_op) directly.

Also we may need to expose the .c file internal function as experimental in version.map

> }
> 
> rte_declare_enum_list_end(rte_crypto_asym_op);
> 
> ---------------
> Library C file:
> ---------------
> 
> rte_define_enum_list_end(rte_crypto_asym_op);

If we want to make it a generic thing in rte_common.h
Will the below change be ok?
----------------------------------
Common header file (rte_common.h):
----------------------------------
#define rte_define_enum_list_end(name, last_value) \
static inline int name ## _enum_list_end(void) \
{ \
       return last_value + 1; \
}

----------------
Lib header file
----------------
//After the enum definition define the list end as below
rte_define_enum_list_end(rte_crypto_asym_op, RTE_CRYPTO_ASYM_OP_VERIFY);


And wherever list end is needed use rte_crypto_asym_op_enum_list_end()?

With this change, abi check will not complain for any new addition at the end of enum.
And we do not need to expose any internal API in version.map.





      reply	other threads:[~2024-09-23 20:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-05 10:14 Akhil Goyal
2024-09-05 15:09 ` Morten Brørup
2024-09-05 15:26   ` Kusztal, ArkadiuszX
2024-09-06  6:32   ` fengchengwen
2024-09-06  7:45     ` [EXTERNAL] " Akhil Goyal
2024-09-06  7:54     ` Morten Brørup
2024-09-23 20:41       ` Akhil Goyal [this message]

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=CO6PR18MB4484DA9201E6A66186079C00D86F2@CO6PR18MB4484.namprd18.prod.outlook.com \
    --to=gakhil@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=anoobj@marvell.com \
    --cc=asomalap@amd.com \
    --cc=david.marchand@redhat.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fanzhang.oss@gmail.com \
    --cc=fengchengwen@huawei.com \
    --cc=fiona.trahe@intel.com \
    --cc=g.singh@nxp.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=matan@nvidia.com \
    --cc=mb@smartsharesystems.com \
    --cc=mdr@ashroe.eu \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=radu.nicolau@intel.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=ruifeng.wang@arm.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).