[PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction

[Bruce Richardson]

On Fri, Jan 06, 2023 at 10:47:06AM -0800, Tyler Retzlaff wrote:
> On Fri, Jan 06, 2023 at 11:48:17AM +0000, Bruce Richardson wrote:
> > On Thu, Jan 05, 2023 at 04:32:40PM -0800, Stephen Hemminger wrote:
> > > On Thu, 5 Jan 2023 09:21:18 -0800
> > > Tyler Retzlaff <roretzla at linux.microsoft.com> wrote:
> > > 
> > > > On Thu, Jan 05, 2023 at 10:01:31AM +0100, Thomas Monjalon wrote:
> > > > > 05/01/2023 08:09, Morten Brørup:  
> > > > > > > From: Tyler Retzlaff [mailto:roretzla at linux.microsoft.com]
> > > > > > > +/**
> > > > > > > + * @warning
> > > > > > > + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> > > > > > > notice
> > > > > > > + *
> > > > > > > + * Get the count of leading 0-bits in v.
> > > > > > > + *
> > > > > > > + * @param v
> > > > > > > + *   The value.
> > > > > > > + * @return
> > > > > > > + *   The count of leading zero bits.
> > > > > > > + */
> > > > > > > +__rte_experimental
> > > > > > > +static inline unsigned int
> > > > > > > +rte_clzl(unsigned long v)  
> > > > > > 
> > > > > > Don't use l (long) and ll (long long) for names (and types), use explicit bit lengths, 32 and 64.
> > > > > > 
> > > > > > E.g.: rte_clz32(uint32_t v)  
> > > > > 
> > > > > I agree on using numbers.
> > > > >   
> > > > 
> > > > love the idea, fewer functions too.
> > > > 
> > > > though it is a shame we cannot adopt C11 standard because we could just
> > > > do away with the bit suffixes entirely.
> > > 
> > > We could but the project needs to support older RHEL releases
> > > which have older tool sets. Though probably this is moot point given
> > > how much meson seems to change.
> > 
> > True, though meson tends to be a bit easier to update than GCC on a system
> > - no "pip3 install --upgrade gcc", sadly :-)
> 
> * on linux. :)
> 
> > 
> > If we can't go all the way to C11 support, how about at least going to C99
> > support? As far as I know DPDK has never updated its minimum C-standard
> > version, and it might be a good idea to start the process of doing so, even
> > if it is a baby step.
> 
> the thing that blurs the line a bit is how the gcc version that is
> holding us back does actually allow the use of some C99 optional
> features. for example we use the C99 fixed width integer types so
> technically some of the code already requires C99.
> 
> i also notice at least one driver is explicitly specifying -std=gnu99 so
> maybe that driver just isn't being built when the old gcc is detected?
> 
> anyway, i think we are stuck pre-c99 so long as we have RHEL 7 to
> contend with. the rationale is if we could use a compiler conforming to
> the new standard we could just directly use those features, but so long
> as we have to support non conforming compiler at a particular level we
> have to introduce an abstraction and that is where all the extra work
> comes from.
> 

AFAIK the gcc 4.8 compiler on RHEL 7/Centos 7 does support C99, it's just
missing full support for C11 (which comes in 4.9). Therefore I see using
C99 as hopefully being unproblematic, and allowing us to try moving forward
revision and seeing what issues - if any - we hit. It should also allow us
to put in place infrastructure to support such version changes, since, for
example, we likely need to ensure that our headers still work with C90
compilation.

/Bruce