From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DEA2C54798 for ; Tue, 5 Mar 2024 18:01:56 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7A0F040271; Tue, 5 Mar 2024 19:01:55 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id E983440270 for ; Tue, 5 Mar 2024 19:01:53 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 37045F0F2 for ; Tue, 5 Mar 2024 19:01:53 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 0F4EDF0F1; Tue, 5 Mar 2024 19:01:53 +0100 (CET) Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 35730F0EF; Tue, 5 Mar 2024 19:01:51 +0100 (CET) Message-ID: <998026ed-8fe6-43bd-93d7-bcf30e8e36cc@lysator.liu.se> Date: Tue, 5 Mar 2024 19:01:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 1/7] eal: extend bit manipulation functions To: Tyler Retzlaff Cc: Stephen Hemminger , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, Heng Wang 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> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240304163434.GA16065@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 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). > 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.