> > From: Akhil Goyal [mailto:gak...@marvell.com] > > Sent: Thursday, 3 October 2024 09.01 > > > > 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. > > > > > Can we move forward with above suggestion? > > Sorry about the late reply, Akhil. > > It seems Ferruh and David have picked up this discussion with good arguments. > > I have no preferences for a generic solution, especially if this is an > isolated case. A > generic solution can be added at any time later.
Ok, since we are not talking about a generic solution. We can remove RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END And RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END. These enums are not used anywhere and are not required at all. And for RTE_CRYPTO_ASYM_OP_LIST_END, we can keep it as is. The rte_crypto_asym_op_type is not expected to grow in future and We need the list end for loops as well as arrays. Hence sending a patch to remove RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END And RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END. This is inline with symmetric crypto xform type list.
