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 C75EFA0C47; Tue, 26 Oct 2021 09:45:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4C4ED40A4B; Tue, 26 Oct 2021 09:45:23 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 2A8064003E for ; Tue, 26 Oct 2021 09:45:22 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2021 09:45:20 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86C5E@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <4152307.NZnTyprsWH@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Thread-Index: AdfJ1Ik9mCUuzEZbQ222x+tTUn5tSgAZaGUA References: <1615418650-19513-1-git-send-email-roretzla@linux.microsoft.com> <1615836878-23213-1-git-send-email-roretzla@linux.microsoft.com> <4152307.NZnTyprsWH@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" , , "Tyler Retzlaff" Cc: , , , , , , Subject: Re: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use 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 Sender: "dev" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Monday, 25 October 2021 21.14 >=20 > 15/03/2021 20:34, Tyler Retzlaff: > > The proposal has resulted from request to review [1] the following > > functions where there appeared to be inconsistency in return type > > or parameter type selections for the following inline functions. > > > > rte_bsf32() > > rte_bsf32_safe() > > rte_bsf64() > > rte_bsf64_safe() > > rte_fls_u32() > > rte_fls_u64() > > rte_log2_u32() > > rte_log2_u64() > > > > [1] http://mails.dpdk.org/archives/dev/2021-March/201590.html > > > > Signed-off-by: Tyler Retzlaff > > --- > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > +* eal: Fix inline function return and parameter types for > rte_{bsf,fls} > > + inline functions to be consistent. > > + Change ``rte_bsf32_safe`` parameter ``v`` from ``uint64_t`` to > ``uint32_t``. > > + Change ``rte_bsf64`` return type to ``uint32_t`` instead of > ``int``. > > + Change ``rte_fls_u32`` return type to ``uint32_t`` instead of > ``int``. > > + Change ``rte_fls_u64`` return type to ``uint32_t`` instead of > ``int``. >=20 > It seems we completely forgot this. > How critical is it? Not updating has near zero effect on bug probability: Incorrectly = returning signed int instead of unsigned int is extremely unlikely to = cause problems. Updating has near zero performance improvement: The unnecessary = expansion of a parameter value from 32 to 64 bits is cheap. The update's only tangible benefit is API consistency. :-) -Morten