[dpdk-dev] [PATCH v4 01/10] eal: introduce macros for getting valuefor bit
Morten Brørup
mb at smartsharesystems.com
Mon Jul 6 12:53:43 CEST 2020
> 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?
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
>
More information about the dev
mailing list