> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Parav Pandit > Sent: Friday, July 3, 2020 3:47 PM > > There are several drivers which duplicate bit generation macro. > Introduce a generic bit macros so that such drivers avoid redefining > same in multiple drivers. > > Signed-off-by: Parav Pandit <pa...@mellanox.com> > Acked-by: Matan Azrad <ma...@mellanox.com> > --- > Changelog: > v1->v2: > - Addressed comments from Thomas and Gaten. > - Avoided new file, added macro to rte_bitops.h > --- > lib/librte_eal/include/rte_bitops.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/librte_eal/include/rte_bitops.h > b/lib/librte_eal/include/rte_bitops.h > index 740927f3b..d72c7cd93 100644 > --- a/lib/librte_eal/include/rte_bitops.h > +++ b/lib/librte_eal/include/rte_bitops.h > @@ -17,6 +17,8 @@ > #include <rte_debug.h> > #include <rte_compat.h> > > +#define RTE_BIT(bit_num) (1UL << (bit_num))
Is the return value 32 or 64 bit, or is intended to depend on the target architecture? Please be explicit by using UINT32_C(1) or UINT64_C(1) instead of 1UL, if you want a specific size. It could be a static inline __attribute__((__pure__)) function instead of a macro, but it's not important for me. The macro/function needs a description for the documentation. I'm also concerned about the name of the macro being too generic. But the effort of changing all the drivers where it is being used already could be too big if the name changes too. And the macro/function is new, so shouldn't it - in theory - be marked as experimental? > + > /*------------------------ 32-bit relaxed operations ----------------- > -------*/ > > /** > -- > 2.26.2 >
