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 5716AC3DA7A for ; Thu, 5 Jan 2023 20:57:49 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3418640697; Thu, 5 Jan 2023 21:57:48 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 4B10A4067C for ; Thu, 5 Jan 2023 21:57:47 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 987A620B92A6; Thu, 5 Jan 2023 12:57:46 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 987A620B92A6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1672952266; bh=exmdFixZr3XPJPu+wUCS1BtC0/jpHg/ZFpezGA5/Tyc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iH63PeAs2sZO0aRQKJwc/YSl7vv2+r/HcECJz9d4OGPFA0ffesmluFCpUmKwMPbFI kRJ5FpB36aUgMMu1l9sThJiOd2Awds0rJCtlBEo8lBYliyTgw2UwrvR40QUIVh2/Y/ rH1Tb1CgjjLOQDfFm7FDDN2a9Iu95jnWzu+wqNBg= Date: Thu, 5 Jan 2023 12:57:46 -0800 From: Tyler Retzlaff To: Thomas Monjalon 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 Message-ID: <20230105205746.GA15559@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1669241687-18810-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D87520@smartserver.smartshare.dk> <20221128172756.GC28869@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <3140231.5fSG56mABF@thomas> <20230105172349.GC9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230105172712.GD9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230105172712.GD9408@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 Thu, Jan 05, 2023 at 09:27:12AM -0800, Tyler Retzlaff wrote: > On Thu, Jan 05, 2023 at 09:23:49AM -0800, Tyler Retzlaff wrote: > > > > oh! not a problem. i'm very keen to catch any mistakes, thought i had > > > > missed something. > > > > > > 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? > > > > > > > > > > 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. > > > > 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. > > > > thanks > > just as a further follow up, you do understand that this is technically > an api break? > > 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. > > anyway, i'll submit v3 with this change anyway. so when attempting to do this it became immediately obvious that moving just the bit op functions out is going to create a circular dependency between rte_common.h, rte_bitops.h once the bit ops are moved out of common there are still other inline functions that remain in comman that require bringing bitops back in, but bitops depends on common. my compromise will be to break log2 and pow2 inline functions into their own files to break the cycle (common no longer depends on bitops). i'll submit patches for this but it ends up touching a lot more of the tree to add back includes for log/pow inline use. alternatively i can just not move the remaining bit manipulation functions, let me know which is preferred. thanks