[dpdk-dev] [PATCH v4 01/10] eal: introduce macros for getting valuefor bit

Parav Pandit parav at mellanox.com
Tue Jul 7 13:38:10 CEST 2020



> From: Morten Brørup <mb at smartsharesystems.com>
> Sent: Monday, July 6, 2020 4:24 PM
> 
> > From: dev [mailto:dev-bounces at 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 <parav at mellanox.com>
> > Acked-by: Matan Azrad <matan at 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?
>
It should be 64-bit.
 
> Please be explicit by using UINT32_C(1) or UINT64_C(1) instead of 1UL, if you
> want a specific size.
> 
Will do UINT64_C(1).

> 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.
> 
In this header file or outside?

> 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.
>
Right. Currently drivers have generic name as BIT(). Close to 3000 entries.
So doing at RTE_BIT to match other rte_ APIs.
Drivers can slowly migrate at their pace to this one.
 
> And the macro/function is new, so shouldn't it - in theory - be marked as
> experimental?

How to mark a macro as experimental?


More information about the dev mailing list