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

[Akhil Goyal <gakhil@marvell.com>]

> > 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);
> >
> 
> I assume Morten suggests his macros to escape from maintenance cost of
> updating inline function each time a new enum is added.

Except for the maintenance cost, is there any other issue with this?
Will the ABI break for any new additions?

I believe this is a simple change to define and maintain LIST_END wherever required.
We can add a comment in the enum for asking people to update it for new additions.

The macros suggested by Morten seem a bit complex and
would add #if in the enum to compile it as internal.
Also we would need to expose "_ ## name ## _enum_list_end" function also in version.map
While the "name ## _enum_list_end" would be used by the application.

I would suggest to remove the list_end from crypto library instead of adding #if in enum.
Like it was suggested long back. Application can live without it.
https://patches.dpdk.org/project/dpdk/patch/20211008204516.3497060-1-gakhil@marvell.com/

The list_end were removed for all symmetric crypto enums when we worked on ABI stability.
But asymmetric was left as it was experimental at that time and we missed them as it was not complaining.
But now since it is marked as stable. We need to deal with it as soon as possible.

> 
> But with above suggestion, that cost is still there, so I don't think
> this one has a benefit against the original suggestion.

Yes the idea is same for both.
It is just that this approach is generalized to be used anywhere.