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 42241A00C2; Fri, 6 Jan 2023 19:47:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD3CA40141; Fri, 6 Jan 2023 19:47:08 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id D8E06400EF for ; Fri, 6 Jan 2023 19:47:06 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 1A5C120B928C; Fri, 6 Jan 2023 10:47:06 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1A5C120B928C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1673030826; bh=ZgQTJZvMEVlFPGOznzY69gZA4urFRqzevffwiFKd4W4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J8l1b1/05Pw2FAQOQkxS0oxSry+TmoSGRNCB+uIQthk/qf0/18V7XaE3VH/xQIXA+ it4gyW1U8ZjwJM+gZKRIP6oQ3PqC7IdxGiqZ+Xyq2seTa6lUTMwUN+PwHZykNyoOEc UPakDZr0pLTPDW96SWwBEEKmJzyYWxFj7dIjOrLI= Date: Fri, 6 Jan 2023 10:47:06 -0800 From: Tyler Retzlaff To: Bruce Richardson Cc: Stephen Hemminger , Thomas Monjalon , Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, david.marchand@redhat.com Subject: Re: [PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction Message-ID: <20230106184706.GA20685@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1669241687-18810-1-git-send-email-roretzla@linux.microsoft.com> <1669246997-30592-2-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D87624@smartserver.smartshare.dk> <3710898.kQq0lBPeGt@thomas> <20230105172118.GB9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230105163240.78eefebb@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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 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 :-) * 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. a prominent example is atomics from C11, but for other reasons in our code base that i won't go into even if we required C11 we would still need to abstract atomics. fwiw i'm working on this patch series now and hope to provide a first draft in the next week or two. finally, i do think it would be good to document a minimum C compiler conformance level rather than specific gcc versions. though i admit we also have a hard dependency on gcc right now. my goal is to improve portability to a level where we could just state "you need a C compliant compiler" (or as close to it as possible). ty