[dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs

[Honnappa Nagarahalli]

<snip>
> >
> > >
> > > On Sat, 21 Dec 2019 16:07:23 +0000
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com> wrote:
> > >
> > > > 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;\
> > > >     } \
> > > > })
> > >
> > > Macros are more error prone. Especially because this is in exposed header
> file
> > That's another question I have. Why do we need to have these APIs in a
> public header file? These will add to the ABI burden as well. These APIs
> should be in a common-but-not-public header file. I am also not sure how
> helpful these APIs are for applications as these APIs seem to have considered
> requirements only from the PMDs.
> 
> Why do we have to wrap every C atomic builtin? What value is there in that?
As long as we stick to requirements from PMD we do not need to worry about every atomic builtin. We seem to be making these APIs public, which requires us to keep these APIs generic considering possible future requirements.