From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B033A04A5; Thu, 18 Jun 2020 14:22:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B76EB1BEF2; Thu, 18 Jun 2020 14:22:28 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 695691BEDF for ; Thu, 18 Jun 2020 14:22:27 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C1BCB5C0124; Thu, 18 Jun 2020 08:22:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 18 Jun 2020 08:22:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= /nC+KTzmGfbOHVItNjlAkdb4Cv8sc85cfLi+Z2Zrg1I=; b=LxX9IDXAA5bcH+HI YEi+4mP4yEWw/zqfQ5qFbqo4oBWwPNFNRPoVp6/ZQPerwm1o+V7IH1Gwa1YAC6eD /jeosQwD3JtlY99n3YFwPMUXVju+7G28SMZ2PjGzmxQ1nqMZiZo4CJpRMZKnrTVc 3Re02wNydW0sTYMfz33VULCK8C4BopTkiMADqUIx1QAAcDcCJwdhcwGyJHV5QyT8 DGXHpKq9Hco1wRjcz5pJS6aJ6ec4SY9BE/dETTHwcNbDw7r4JlFtdOc1s1emzt9I EJ0zFP6IO+Sw93ytdJaH3UBweMxAAuJ6QbdhFq1ucMI7a3A6i4CtsW4uU8Gx5XeD /L+w0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/nC+KTzmGfbOHVItNjlAkdb4Cv8sc85cfLi+Z2Zrg 1I=; b=SuOigjHFF/lXqqVW3n8SSayLowPCT+mojx9tTa/evgxaq3Fn4x85nGkLQ Ucp7GSRgsVMSZTIy1xwO2xaWfB4o5VY14NDDoM4OHYGlByElC5c846voIsgjZRiE mTPCwfjty+1xVAAwy6pIL55NyQ1wMlYZfwuTgLOJnUF4JD6UZUAkNjLLcMXgznDq +ntZRAppkElrg+nfnS5VtryPknxS3/ws1Kw9ARPkcaX8TaPYsulZgrkwZ3cI/xMp p95WXX+klMHIfOBKGCvcsTYth4J1QJ40MkXhrt8lgewukNdjI/ca4/+AKStAPnGX vCPogt1QgDt39cSJlgKMZQqjpZI0Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejgedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfeegffeihfeftedthfdvgfetkeffffdukeevtdevtddvgfevuedu veegvdeggedtnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 17B983060FE7; Thu, 18 Jun 2020 08:22:24 -0400 (EDT) From: Thomas Monjalon To: Parav Pandit , =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: "dev@dpdk.org" , "ferruh.yigit@intel.com" , Ori Kam , Matan Azrad , joyce.kong@arm.com, phil.yang@arm.com, honnappa.nagarahalli@arm.com, mb@smartsharesystems.com Date: Thu, 18 Jun 2020 14:22:22 +0200 Message-ID: <2125265.EUd4R9OQLY@thomas> In-Reply-To: References: <20200610171728.89-1-parav@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [RFC PATCH 1/6] eal: introduce macros for getting value for bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 18/06/2020 14:16, Parav Pandit: > From: Parav Pandit > > From: Thomas Monjalon > > > 15/06/2020 21:33, Ga=EBtan Rivet: > > > > On 10/06/20 17:17 +0000, Parav Pandit wrote: > > > > > There are several drivers which duplicate bit generation macro. > > > > > Introduce a generic bit macros so that such drivers avoid > > > > > redefining same in multiple drivers. > > > > > > > > > > Signed-off-by: Parav Pandit > > > > > --- > > > [...] > > > > > --- /dev/null > > > > > +++ b/lib/librte_eal/include/rte_bits.h > > > > > @@ -0,0 +1,10 @@ > > > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > > > + * Copyright 2020 Mellanox Technologies, Ltd. > > > > > + */ > > > > > + > > > > > +#ifndef _RTE_BITS_H_ > > > > > +#define _RTE_BITS_H_ > > > > > + > > > > > +#define RTE_BIT(bit_num) (1UL << (bit_num)) > > > > ^ The tab here should be replaced by a s= pace. > > > > > + > > > > > +#endif > > > > > > > > I'm not sure this kind of macro is needed, but if multiple drivers > > > > are using the patterns let's say ok. > > > > > > Yes. we certainly need it. Currently BIT() macro is used at 3000+ locat= ions and > > defined in 10+ drivers. > > Once we have this macro, it can gradually be replaced. > >=20 > > > > However I don't think it needs its own header. Would it be ok in > > > > lib/librte_eal/include/rte_common.h for example? > > > > > > If we want to reuse an existing file, it could be > > > lib/librte_eal/include/rte_bitops.h > > > > > o.k. > > I will rename file from rte_bits.h to rte_bitops.h More such macros wil= l be > > available here to avoid redefinitions in drivers. >=20 > I see that rte_bitops.h already exist and this new definition doesn't fit= well in the rte_bitops.h. > The intent of the rte_bitops.h is to have generic mostly macros to replac= e current duplication of: >=20 > Such as > BIT() > BIT_ULL() > BITS_PER_BYTE() > BITS_TO_LONGS() >=20 > They do not fit well in rte_bitops.h which works on the 'bitmap'. Current bitops functions are getting and setting a bit. I don't undertand why you say "works on the bitmap". In my opinion, bit definition fits in this include file.