On Sat, Dec 21, 2019 at 9:37 PM Honnappa Nagarahalli
<honnappa.nagaraha...@arm.com> wrote:
> > > +__rte_experimental
> > > +static inline uint32_t
> > > +rte_get_bit32_relaxed(unsigned int nr, uint32_t *addr) {
> > Why not pass the memory order as a parameter? It would reduce the number
> > of API calls by half.
> I think these APIs should be modelled according to C11 __atomic_xxx APIs.
> Otherwise, the programmers have to understand another interface. It will also
> help reduce the number of APIs.
> Converting these into macros will help remove the size based duplication of
> APIs. I came up with the following macro:
>
> #define RTE_GET_BIT(nr, var, ret, memorder) \
> ({ \
> if (sizeof(var) == sizeof(uint32_t)) { \
> uint32_t mask1 = 1U << (nr)%32; \
> ret = __atomic_load_n(&var, (memorder)) & mask1;\
> } \
> else {\
> uint64_t mask2 = 1UL << (nr)%64;\
> ret = __atomic_load_n(&var, (memorder)) & mask2;\
> } \
> })
>
> The '%' is required to avoid a compiler warning/error. But the '%' operation
> will get removed by the compiler since 'nr' is a constant.
> IMO, the macro itself is not complex and should not be a pain for debugging.
>
> Currently, we have 20 APIs in this patch (possibly more coming in the future
> and creating an explosion with memory order/size combinations). The above
> macro will reduce this to 5 macros without further explosion in number of
> combinations.
>
> Any thoughts? What do others think?
# I think, the most common use case for register manipulation is
getting/setting of "fields"(set of consecutive bits). IMO, Linux
kernel bit manipulation APIs makes more sense.
At least have implementation similar to FIELD_GET() and FIELD_SET().
https://github.com/torvalds/linux/blob/master/include/linux/bitfield.h
# FIELD_GET will be superset API. A single bit can get through width = 1
# I think, it good to two versions of Macro/API. RTE_FIELD_GET(without
atomics) and RTE_FIELD_GET_ATOMIC(with C11 atomics)
