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

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Jan 06, 2023 at 02:40:59PM +0100, Thomas Monjalon wrote:
> 06/01/2023 13:41, Morten Brørup:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Friday, 6 January 2023 12.48
> > > 
> > > 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@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@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 :-)
> > > 
> > > 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.
> 
> I am in favor of this baby step: define -std=c99 porject-wise
> and see what are the effects during the year.
> 
> 
> > The DPDK Getting Started Guide [1] says:
> > 
> > "Required Tools and Libraries:
> > [...]
> > a supported C compiler such as gcc (version 4.9+)"
> > 
> > GCC version 4.9 supports C11 [2]:
> > "GCC 4.9 Changes: "ISO C11 support is now at a similar level of completeness to ISO C99 support [...]"
> > 
> > So why are we not going to support C11?
> 
> We should make a plan to switch to C11 during next year.
> 
> 
> > Probably because of RHEL 7, which only provides GCC 4.8 [3].
> > 
> > RHEL 7 was released for GA on June 10, 2014 [4]. If someone has a server with a nine year old distro still used in production, it is probably because it is running some legacy application, which is difficult to get up and running on a newer distro. Partial conclusion: RHEL 7 is probably still widely used in production.
> > 
> > However, I have a hard time understanding why anyone would build and/or deploy a brand new DPDK application (based on DPDK 23.03) on such a server. Can someone please justify this?
> > 
> > Are we really going to postpone C11 support in DPDK until June 30, 2026, when RHEL 7 ends its Extended Life Cycle Support [4]?
> 
> RHEL does its own choices to support old software for long.
> Upstream development should move forward.
> 
> 
> > If so, then the GCC version mentioned in the DPDK Getting Started Guide should be corrected accordingly.
> 
> No let's keep GCC 4.9 as a minimum for now.
> If needed we could upgrade it later.

but i think the point Morten is making is that RHEL 7 gcc is 4.8 and
therefore we implicitly no longer support it if we document requiring
gcc 4.9.

> 
> 

so i think the way to do this is through clarification at the next
release / ltsc release. starting with dpdk 23.xx will require
compiler conforming to standard X and optional features / annexes from
standard X. anyone building applications targeting that version of dpdk
release will need a conforming implementation.

from there we just need to take care not to backport any code to
stable branches that depend on standard features that exceed the
requirements documented for that release.