From: Akhil Goyal <gakhil@marvell.com>
To: fengchengwen <fengchengwen@huawei.com>,
"Morten Brørup" <mb@smartsharesystems.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: [EXTERNAL] Re: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs
Date: Fri, 6 Sep 2024 07:45:09 +0000 [thread overview]
Message-ID: <CO6PR18MB4484EB643A0A3C248A84BA57D89E2@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <1d17f91a-fbfe-229b-9772-c149ed9d335a@huawei.com>
> >
> > Here's an idea...
> >
> > We can introduce a generic design pattern where we keep the _LIST_END enum
> value at the end, somehow marking it private (and not part of the API/ABI), and
> move the _list_end() function inside the C file, so it uses the _LIST_END enum
> value that the library was built with. E.g. like this:
> >
> >
> > In the header file:
> >
> > enum rte_crypto_asym_op_type {
> > RTE_CRYPTO_ASYM_OP_VERIFY,
> > /**< Signature Verification operation */
> > #if RTE_BUILDING_INTERNAL
> > __RTE_CRYPTO_ASYM_OP_LIST_END /* internal */
> > #endif
> > }
> >
> > int rte_crypto_asym_op_list_end(void);
> >
> >
> > And in the associated library code file, when including rte_crypto_asym.h:
> >
> > #define RTE_BUILDING_INTERNAL
> > #include <cryptodev/rte_crypto_asym.h>
> >
> > int
> > rte_crypto_asym_op_list_end(void)
> > {
> > return __RTE_CRYPTO_ASYM_OP_LIST_END;
> > }
>
> It's more generic, and also keep LIST_END in the define, we just add new enum
> before it.
> But based on my understanding of ABI compatibility, from the point view of
> application,
> this API should return old-value even with the new library, but it will return new-
> value
> with new library. It could also break ABI.
>
> So this API should force inline, just as this patch did. But it seem can't work if
> move
> this API to header file and add static inline.
>
Yes, moving to c file does not seem to solve the purpose.
So should we move with the way the patch is submitted or we have some other suggestion?
Regards,
Akhil
next prev parent reply other threads:[~2024-09-06 7:45 UTC|newest]
Thread overview: 29+ 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 ` Akhil Goyal [this message]
2024-10-04 3:56 ` [EXTERNAL] " Ferruh Yigit
2024-09-06 7:54 ` Morten Brørup
2024-09-23 20:41 ` Akhil Goyal
2024-10-03 7:00 ` Akhil Goyal
2024-10-06 11:10 ` Morten Brørup
2024-10-09 11:21 ` Akhil Goyal
2024-10-04 4:00 ` Ferruh Yigit
2024-10-04 17:26 ` [EXTERNAL] " Akhil Goyal
2024-10-04 3:54 ` Ferruh Yigit
2024-10-04 7:04 ` David Marchand
2024-10-04 17:27 ` [EXTERNAL] " Akhil Goyal
2024-10-10 0:49 ` Ferruh Yigit
2024-10-10 6:18 ` [EXTERNAL] " Akhil Goyal
2024-10-28 11:15 ` Dodji Seketeli
2024-10-04 9:38 ` Dodji Seketeli
2024-10-04 17:45 ` [EXTERNAL] " Akhil Goyal
2024-10-28 10:55 ` Dodji Seketeli
2024-10-10 0:35 ` Ferruh Yigit
2024-10-28 10:12 ` Dodji Seketeli
2024-10-09 11:24 ` [PATCH] cryptodev: remove unnecessary list end Akhil Goyal
2024-10-09 12:52 ` Morten Brørup
2024-10-09 20:38 ` Akhil Goyal
2024-10-09 14:06 ` Hemant Agrawal
2024-10-10 0:51 ` Ferruh Yigit
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=CO6PR18MB4484EB643A0A3C248A84BA57D89E2@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).