From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1D442A00C2; Fri, 6 Jan 2023 19:58:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 055BD40141; Fri, 6 Jan 2023 19:58:28 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 434EA400EF for ; Fri, 6 Jan 2023 19:58:26 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 870E6208FFC1; Fri, 6 Jan 2023 10:58:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 870E6208FFC1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1673031505; bh=3YhlCH4guksrwiIl2WLatAfmyh1qX3GLYnGVjGFojm8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eOdUG7hEnxnSoJCfB9l8M9mB0zxRlIVg5DEmAe9aKOA6QQem3iw5EtMmdkx6kiHLR OeItw4zcN3eyBnJTendSQT4uzWcGZej8TriIX9Qts8ObV2MBvre5dUFaNfO03zWRKJ pb/3tySUfzhJGMHq7Yy63UXYtVphOebjN3Ym/llA= Date: Fri, 6 Jan 2023 10:58:25 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: Bruce Richardson , Stephen Hemminger , david.marchand@redhat.com, dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= , honnappa.nagarahalli@arm.com, jerinj@marvell.com, ktraynor@redhat.com, maxime.coquelin@redhat.com Subject: Re: [PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction Message-ID: <20230106185825.GB20685@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1669241687-18810-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D8762F@smartserver.smartshare.dk> <836507794.0ifERbkFSE@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <836507794.0ifERbkFSE@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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.