RE: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs

[Akhil Goyal <gakhil@marvell.com>]

> > From: Akhil Goyal [mailto:gakhil@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.