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 31D8CA0353; Thu, 6 Aug 2020 18:01:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 759591C031; Thu, 6 Aug 2020 18:01:58 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 832A12B87; Thu, 6 Aug 2020 18:01:56 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 6CC8531F; Thu, 6 Aug 2020 12:01:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 06 Aug 2020 12:01:55 -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= qBlDSHYesmNMHyiLo4ohjVliEvjw703C1xgl5W+ck1Y=; b=hK1OkU8CqxNY/S+v CqdET1eHG3RxduXGoIzNM2Yf9h1CM8msJlNeJq2HaY2I+Leyjyi4ySBWk2GrDJOo sG/yhA0Bl+3xw3sskFrXLtvOHxhILaeB4oyt0Lbb25P81X3kM5mCp3+TZOMxTajS HuBPEwr+Mj3oZ08DP16yhVvXJehfZ+bOskaQjrkFX4qeJfABIZcLRcFVYpBuckdQ Nuzv9531s7yLXThICqo3ijwgWjlGsU32tZ1zNsU0bUYd0PBNznakWOsnYrnSNIxK CNTDx4fWa/xjblKD2pHRT9iC3QUs4uVb/aH7OFr9C85HsBlJhHY+DEGPizknW+vT ap3yFA== 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=qBlDSHYesmNMHyiLo4ohjVliEvjw703C1xgl5W+ck 1Y=; b=GheQxhZaoFTpwxqjUgIPBVOMAMTPSnTdZLg5T01uo4QdJB8novSgIvj2s MTEhn3IQpDKpalDWdupnUeX+tzhw1jx5zdX8AtrzN2ZUoWB3Pg25E9a4nRhjAuZo 26uFQo8dicWDu6R18yodnOTLbRjyuTRfGefN87U2L6s8I1n5/Ya7VMEwzLMiOsqA ntxxHVGrGZMtfEZYgwJOclerHHH9WKYUGOdBHUW3OIr56u9DUKBKZI5XCXYVYbck cfrgc2hZXbHJoVlFwn03iqEpmG6GRyCo4gw9hvvKXXm6YpkPL2bPFlxdjwzPin8j DaLCykCyO0TtPjuuY5v4sA7k7ziVA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 549FA30600A6; Thu, 6 Aug 2020 12:01:54 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: Bruce Richardson , techboard@dpdk.org Date: Thu, 06 Aug 2020 18:01:53 +0200 Message-ID: <3271269.QxqaOeczzM@thomas> In-Reply-To: <6344259.PTXK2i140R@thomas> References: <20200805142141.32337-1-bruce.richardson@intel.com> <20200805164504.GE1716@bricha3-MOBL.ger.corp.intel.com> <6344259.PTXK2i140R@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 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" Any other opinions? 05/08/2020 19:02, Thomas Monjalon: > 05/08/2020 18:45, Bruce Richardson: > > On Wed, Aug 05, 2020 at 05:15:31PM +0200, Thomas Monjalon wrote: > > > 05/08/2020 17:07, Bruce Richardson: > > > > On Wed, Aug 05, 2020 at 04:57:42PM +0200, Thomas Monjalon wrote: > > > > > 05/08/2020 16:21, Bruce Richardson: > > > > > > The RTE_MACHINE_CPUFLAGS_* macros in DPDK build just duplicate info from > > > > > > the compiler macros, so we can remove them and just use the compiler > > > > > > versions directly. > > > > > > > > > > > > Signed-off-by: Bruce Richardson > > > > > > --- > > > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > > > +* build macros: The macros defining RTE_MACHINE_CPUFLAG_* will be removed > > > > > > + from the build. The information provided by these macros is available > > > > > > + through standard compiler macros. For example, RTE_MACHINE_CPUFLAG_SSE3 > > > > > > + duplicates the compiler-provided macro __SSE3__. > > > > > > > > > > I see 2 advantages of having alias: > > > > > - if 2 compilers differ, we can manage > > > > > - we can find all such macros with grep RTE_MACHINE_CPUFLAG > > > > > > > > > > > > > Sure, if you think it's worthwhile keeping them, we can do so. It's just > > > > right now they seem to be largely a waste of space. For #2, I'm not sure > > > > when we would want to grep for them all, except possibly to remove them. > > > > :-) > > > > > > For instance, in a lib, I grep where we have CPU specific code. > > > > > > We probably need more opinions, I can change my mind. > > > > > Yes, we need some more opinions here. > > > > For the above point, yes it's useful to be able to grep for these things, > > but it does assume that everybody uses the DPDK-defines and doesn't use the > > compiler ones directly. There are a few instances where there seems to be > > x86, ARM or PPC compiler flags already directly used in the code. > > > > As well as brevity, the other big reason I see for removing them is to > > avoid having to maintain these lists of flags for future use. Right now, > > with -march=skylake-avx512, gcc will define 7 different AVX feature flags. > > DPDK, on the other hand, only provides equivalent defines for 3 of them. > > We have no automatic way of pulling all newly added flags from gcc/clang > > into our build, so we just add them on an as-needed basis, which makes it > > more awkward for those adding new features that may depend on the flags. If > > we always try to add in all flags to keep things in sync, we are just > > duplicating the efforts the compiler authors have already done for us, and > > wasting the effort for those flags that are unused. > > You see, you can provide good arguments :) > Maybe some of them deserve to be part of the patch. > > Acked-by: Thomas Monjalon