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 96CDE43B8F; Mon, 4 Mar 2024 17:34:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D0F240695; Mon, 4 Mar 2024 17:34:36 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id C46064027D for ; Mon, 4 Mar 2024 17:34:34 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 0DB6920B74C0; Mon, 4 Mar 2024 08:34:34 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0DB6920B74C0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1709570074; bh=ufPvLR1j7BwcNrcnUnRCwLSHFb2pSPD88RMtGx3+RWg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rLzvs1ntgtFTe4AGwrD7/J9t3GpapzcERiy6wLGlLQeYvWNamTMCfz20XLk9SnzN7 s6EZWBHi7Nd17MSe7p8YA1QpFqBTCO6BTjidTUs22JLuYjylmuCbZZ/XFlHykhMguE g3AQO1faYA8bNpavZudo0dcvFspBiTYOuXxQ0L2o= Date: Mon, 4 Mar 2024 08:34:34 -0800 From: Tyler Retzlaff To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Stephen Hemminger , Mattias =?iso-8859-1?Q?R=F6nnblom?= , dev@dpdk.org, Heng Wang Subject: Re: [RFC 1/7] eal: extend bit manipulation functions Message-ID: <20240304163434.GA16065@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240302135328.531940-1-mattias.ronnblom@ericsson.com> <20240302135328.531940-2-mattias.ronnblom@ericsson.com> <20240302090540.0e79e42b@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 Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote: > On 2024-03-02 18:05, Stephen Hemminger wrote: > >On Sat, 2 Mar 2024 14:53:22 +0100 > >Mattias Rönnblom wrote: > > > >>diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h > >>index 449565eeae..9a368724d5 100644 > >>--- a/lib/eal/include/rte_bitops.h > >>+++ b/lib/eal/include/rte_bitops.h > >>@@ -2,6 +2,7 @@ > >> * Copyright(c) 2020 Arm Limited > >> * Copyright(c) 2010-2019 Intel Corporation > >> * Copyright(c) 2023 Microsoft Corporation > >>+ * Copyright(c) 2024 Ericsson AB > >> */ > > > >Unless this is coming from another project code base, the common > >practice is not to add copyright for each contributor in later versions. > > > > Unless it's a large contribution (compared to the rest of the file)? > > I guess that's why the 916c50d commit adds the Microsoft copyright notice. > > >>+/** > >>+ * Test if a particular bit in a 32-bit word is set. > >>+ * > >>+ * This function does not give any guarantees in regards to memory > >>+ * ordering or atomicity. > >>+ * > >>+ * @param addr > >>+ * A pointer to the 32-bit word to query. > >>+ * @param nr > >>+ * The index of the bit (0-31). > >>+ * @return > >>+ * Returns true if the bit is set, and false otherwise. > >>+ */ > >>+static inline bool > >>+rte_bit_test32(const uint32_t *addr, unsigned int nr); > > > >Is it possible to reorder these inlines to avoid having > >forward declarations? > > > > Yes, but I'm not sure it's a net gain. > > A statement expression macro seems like a perfect tool for the job, > but then MSVC doesn't support statement expressions. You could also > have a macro that just generate the function body, as oppose to the > whole function. statement expressions can be used even with MSVC when using C. but GCC documentation discourages their use for C++. since the header is consumed by C++ in addition to C it's preferrable to avoid them. > > I'll consider if I should just bite the bullet and expand all the > macros. 4x duplication. > > >Also, new functions should be marked __rte_experimental > >for a release or two. > > Yes, thanks.