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 B2209A00C2; Fri, 6 Jan 2023 11:00:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C0A1400EF; Fri, 6 Jan 2023 11:00:21 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 7D34F400D4 for ; Fri, 6 Jan 2023 11:00:20 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6E4875C02F2; Fri, 6 Jan 2023 05:00:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 06 Jan 2023 05:00:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1672999217; x= 1673085617; bh=gecE4ALCJNQsneC/mFpDayAg1/IIUrPGuWI6be1vY4o=; b=T 5cWxQ1jDMvxL0Nl9zXHQlI1L973kTBHwVjEq4rFFmm23BF2KchMnVqohfp7P66Wn erJsXvpjzsK2ApgA5nD8DK2oY3lnk4hnru0Afax89ZKWDtGmH9OQHMheu5N8TfBl rjKSweblpP8TD63hdAZUnwZSDvvVySEfVJwoMGBfLO8Wp8HRmWMwa1HkSoYuX5/L 2zTLO/dmUSbld9PjpTPvBfRxr+dLr7BAG+eTl2kd9nHRKdLWoEbp0nHve5oIYuWK PlDaVwEYCP5D9/RWwBerX3qBdLCxZcQqjUEwNe02YbCh76m1slAkvcWOmk2LrJje 3zwryEcOA/6o6CO3TexiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1672999217; x= 1673085617; bh=gecE4ALCJNQsneC/mFpDayAg1/IIUrPGuWI6be1vY4o=; b=s A4qMfnre8oswerUJmVe4/T5OTbByBX0D+Op3/VL72EG81SDNUOAJ0rBG/0o1PEaU WlRFsbY+zHMb/oARLJElAiP08oq7wVeVe5C/5Tf5HhzwJJ/Kf1TiV4azejSqRUz1 QWUlQdzR04lo5WsLCrk97bsjeMqFMD3JZyIYGmI4OMkDMzfs5uXlpq3nv1PtxLOF YjkBD1NQ6aI2UCvjOcTahcBQfpmqR1HuxfT09G89cD4myT+WesUJHIauVC+hLmEM umZi4iWloRaGAnKoNMjwFhVeMw9Wkkd5A4wWSMEazq5q3EM5z9wA4yuE1WwXpqTP qbgt19MeEVpq3V3BfALCg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkedtgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 6 Jan 2023 05:00:16 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff Cc: 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 Date: Fri, 06 Jan 2023 11:00:14 +0100 Message-ID: <2135492.Mh6RI2rZIc@thomas> In-Reply-To: <20230105172712.GD9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1669241687-18810-1-git-send-email-roretzla@linux.microsoft.com> <20230105172349.GC9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230105172712.GD9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 05/01/2023 18:27, Tyler Retzlaff: > On Thu, Jan 05, 2023 at 09:23:49AM -0800, Tyler Retzlaff wrote: > > On Thu, Jan 05, 2023 at 10:04:46AM +0100, Thomas Monjalon wrote: > > > 28/11/2022 18:27, Tyler Retzlaff: > > > > On Mon, Nov 28, 2022 at 06:22:10PM +0100, Morten Br=F8rup wrote: > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > > Sent: Monday, 28 November 2022 18.14 > > > > > >=20 > > > > > > On Thu, Nov 24, 2022 at 11:17:23AM +0100, Morten Br=F8rup wrote: > > > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > > > > Sent: Thursday, 24 November 2022 00.43 > > > > > > > > > > > > > > > > Provide an abstraction for leading and trailing zero bit co= unting > > > > > > > > functions to hide compiler specific intrinsics and builtins. > > > > > > > > > > > > > > > > Signed-off-by: Tyler Retzlaff > > > > > >=20 > > > > > > let me unpack what is being asked for here. > > > > > >=20 > > > > > > > Related functions already exist in lib/eal/include/rte_common= =2Eh. > > > > > >=20 > > > > > > i don't understand. are you saying these inline functions dupli= cate > > > > > > existing bit counting functionality? if so i'll relocate any you > > > > > > identify. > > > > >=20 > > > > > Sorry about not being clear about my intentions with the feedback. > > > > >=20 > > > > > I'm not asking for anything; I only wanted to point at the simila= r family of functions in rte_common.h, to make sure that you were aware of = them. > > > >=20 > > > > oh! not a problem. i'm very keen to catch any mistakes, thought i h= ad > > > > missed something. > > >=20 > > > I think we should move all bit-related functions together. > > > Please could you add another patch to your series > > > moving "ms1b"/"bsf"/"fls" functions in this file? > > >=20 > > >=20 > >=20 > > okay, so there is already a rte_bitops.h. i guess everything should go > > there including the leading/trailing count functions instead of adding a > > new header. Yes good idea to gather all in rte_bitops.h. > > i'll introduce a new patch to the series that gathers the existing > > functions into rte_bitops.h and place the new functions there too. > >=20 > > thanks >=20 > just as a further follow up, you do understand that this is technically > an api break? Yes > moving functions from rte_common.h to rte_bitops.h will make translation > units that included only rte_common.h but used these functions will > fail to compile without being updated to include rte_bitops.h. These functions are not used a lot, it is a "small" API break.