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 57E5D43B76; Tue, 5 Mar 2024 19:06:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 48B5142D45; Tue, 5 Mar 2024 19:06:29 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 19D5B40270 for ; Tue, 5 Mar 2024 19:06:27 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 40E2220B74C0; Tue, 5 Mar 2024 10:06:26 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 40E2220B74C0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1709661986; bh=Hcuu/gVyWEQ+gqwRC64VVpSb0TCAZ71RMdvhdjFZSp4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jFnyvfkktzTjjAebZGMlkWcoCglAHgARcAXXTJrSkIA1BVngo4XEMvSmunf27dGPL KaqXgWfh7dcdVTfxHzAr6bUJtPkNTZssiekIT2dQrG8Gkc/WvGxYJzeuF178Ax+TTp 0nw00MN18gxmS7fXzGpKq3d5TfFfjnWNa7MINbPE= Date: Tue, 5 Mar 2024 10:06:26 -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: <20240305180626.GA23797@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> <20240304163434.GA16065@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <998026ed-8fe6-43bd-93d7-bcf30e8e36cc@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <998026ed-8fe6-43bd-93d7-bcf30e8e36cc@lysator.liu.se> 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 Tue, Mar 05, 2024 at 07:01:50PM +0100, Mattias Rönnblom wrote: > On 2024-03-04 17:34, Tyler Retzlaff wrote: > >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 > > GCC documentation discourages statement expressions *of a particular > form* from being included in headers to be consumed by C++. > > They would be fine to use here, especially considering they wouldn't > be a part of the public API (i.e., only invoked from the static > inline functions in the API). agreed, there should be no problem. > > >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.