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 C2A0EA00C2; Fri, 6 Jan 2023 11:09:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A75CB400EF; Fri, 6 Jan 2023 11:09:50 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 4107E400D4 for ; Fri, 6 Jan 2023 11:09:49 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C3D485C02FF; Fri, 6 Jan 2023 05:09:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 06 Jan 2023 05:09:48 -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=1672999788; x= 1673086188; bh=Wqj+qw9zqnMyBBb0ZWTfvCIEsCHc2ia3Qei0parz+yQ=; b=Y 8Ei/WMkWvAfQFxdNiPGkiCYjJspQAEPLPrb6C4IqtpYrpyMg+vNuh96s99f/Zrkh ES++QfofG7Qk5eAPgp7jwn3E9LPiQg6GyQVYyAHn8VQmaeSsedWaDtIiPaM/TTFk 7MSsKa1cGYW9u/nu4LpYXrXEpIKJzRHEfHMjxWTxkTDXWY7GnhUgWS07FHcCRMGL fcBK38ukLQvU62fZiHXw0QiLJzXeTjoUnwsQ9CdqvltlUWvd53iywKrVU/5CUkjC eF4PODNLpqfoNaa29YMIEjoVE90mJhovsdOzGvVtvDKawvcNWrfCq0uoDf2lfa6d Vc8duUse31Sy7hjeorNjA== 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=1672999788; x= 1673086188; bh=Wqj+qw9zqnMyBBb0ZWTfvCIEsCHc2ia3Qei0parz+yQ=; b=N yyBSy5BapZ2qQGcQy7tBrNVxBXVOyQgCtcZED6/NIuth3p4DBWBt+Qp89Pzy50mm SCJeK+3w4pDBe63XyUJfQuE9rHJrxaTfybh4k9YRC4Z3ea6D36t9OirVed0rFuD+ wN0+wzkjOlXj1Dx3ejtwA1a/JHdvi5zgMwSAfiFrlB6DsV1JwnchVAC6Kc3bcTQY HtqrccDr3rEvZgEMVamw9GOnKpOO94Z+tmFb2fDRqGCrVEx/2kgBnVj/3c0VhDrE 4dwBqrChHISe+Culm+RaDAFienkaM3Wn8wb8pkzkdiFwbnwZdgd9MqlHn1HDkpgp gf8EEXD5dkGg9+cVp9JNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkedtgddufecutefuodetggdotefrodftvf 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:09:47 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , Tyler Retzlaff Cc: 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:09:46 +0100 Message-ID: <1883454.taCxCBeP46@thomas> In-Reply-To: <20230106010446.GA18805@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1669241687-18810-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D8762D@smartserver.smartshare.dk> <20230106010446.GA18805@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 06/01/2023 02:04, Tyler Retzlaff: > On Fri, Jan 06, 2023 at 12:10:45AM +0100, Morten Br=F8rup wrote: > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > Sent: Thursday, 5 January 2023 23.06 > > >=20 > > > doesn't create a new kind of mess. > > >=20 > > > so i fudged around a bit to see if i could get a happy medium. i ended > > > up with this. > > >=20 > > > remove include of rte_debug.h from rte_bitops.h > > >=20 > > > * had to remove the RTE_ASSERT from existing rte_bitops.h functions > > > * this breaks a good piece of the cycle debug -> log -> common -> > > > bitops -> debug > > > * deal breaker? i don't think it was right that we were getting all > > > of log, common just for using bitops anyway. > > >=20 > > > move pow2 functions from rte_common.h -> rte_pow2ops.h > > > * new header includes rte_bitops.h > > >=20 > > > move log2 functions from rte_common.h -> rte_log2ops.h > > > * new header includes rte_bitops.h, rte_pow2ops.h > > >=20 > > > include rte_bitops.h, rte_pow2ops.h and rte_log2ops.h back into > > > rte_common.h > > >=20 > > > * this is done to reduce the impact of compatibility break by > > > continuing to expose the pow2/log2/bitops via rte_common.h > > >=20 > > > so we end up with 3 standalone headers, where the whole tree builds > > > without having to add a pile of includes for the new headers. we can > > > later deprecate the exposure of the inline functions when including > > > rte_common.h > > >=20 > > > * one caveat is that there was some contamination coming in via the > > > removed rte_debug.h where rte_bitops.h was used. so technically > > > a break of api too. > > >=20 > > > objections? > > >=20 > > > if this is no good i'll just fold my new functions into rte_common.h > > > and > > > leave the mess for the next person, though i am trying not to do that. > > >=20 > > > thanks for the discussion. > >=20 > > Here's some long term thinking: EAL has grown into a trashcan where too= much is thrown in. It should only be a thin shim to abstract the underlyin= g hardware and O/S environment. A step in that direction could be splitting= the current EAL into a true EAL and a Utils library. Not now, but perhaps = some day in a rosy future. > >=20 > > Your proposal effectively makes rte_common.h even bigger by including r= te_bitops.h (which was intended for accessing hardware). I am not sure it i= s a step in the right direction. On the other hand, introducing yet another= header file for bit-mathematical functions is probably worse than adding t= hem to rte_bitops.h. > >=20 > > I can't come up with something good myself, but I lean towards simply a= dding your functions to rte_common.h and live with the existing mess. If yo= u think your proposal is better, I will not object. I'm only voicing my tho= ughts. >=20 > it's hard when we are starting with something monolithic and trying to > split it. you always end up with these iterative transitions toward what > you want because you have to keep some kind of compat. >=20 > >=20 > > @Thomas may have another perspective on the matter. >=20 > Thomas any last word after this back and forth? This change isn't > necessarily blocking me but is a distraction i'd like to finish/offload. I think it is better to move all in rte_bitops.h rte_common must have almost zero dependency. If log2 and pow2 are based on bitops operations, it is not a bad fit for rt= e_bitops.h.