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 C3D20A053D; Wed, 5 Aug 2020 19:02:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D3D922C23; Wed, 5 Aug 2020 19:02:07 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id D1CB8A3; Wed, 5 Aug 2020 19:02:05 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2A8515C0100; Wed, 5 Aug 2020 13:02:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 05 Aug 2020 13:02:04 -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= hocTBjMgdvtdGcuAWfwWUo7fQ4mhqsV/3PE+njZjNG0=; b=K0KV1y0ogcfx7ehm IyhVACeZhYWMmemMw0wO5ckaIBZ0UctWKrhZnMqXTLa1tbv4pqjK9zWOdcF8TNVX UOQQ+o1top6bI0ddKxdwenHVGx8iPqlilBsnLOsWgOhYq7oG51BQBRY8SwMI4JuG qDehOIz3V64Ur/klNwXUOISbmYq/sUHHzq/1kWDp3aBPNRaLlqs3fktC+mFFiGJp RDcghqidWlJsH7qJhaTyqwBJmpRaRlwKZi/+/WCqmRQCpnSqPpYRlYmG6cczvmn8 7CGRATNDAXXnCUbvPn0PG5RALrjXM3cIuWClGN7WoUmzWyKLj38X1efs3AgsT3tN KRdn5w== 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=hocTBjMgdvtdGcuAWfwWUo7fQ4mhqsV/3PE+njZjN G0=; b=ZTOtb1rfAtviSRaPZ1jJ6aycxfNUAJ2J3sBvW8jzcUBW3glLsalFDKh4P ly/php3S3xucg/LwdO/+FBKHQgHCfCiZ3CZvRmP2pu7DsBE1VsnV7tSulkr24S3W TZFhPaw2BFA+C96PrhSbNaLmcitmoWvBaL0A3PZbUl4y4U0zb5zEldlIr1cJ7uSS udjqB29lFGBoVkB1F/yL9hjmmp5OL1Zfo1uLBbrAF9A4Fo2kneObqlD7zEhgOqr/ 8sb/KHLIQVBDGPB1rq2xWD5hmormI15O19MPcSy/76UfwUVZz1XWzvvH5sHSRgis h4H2ObaiXucsgol8uYqD2Y0b/pALw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeekgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf 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 448523060272; Wed, 5 Aug 2020 13:02:03 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, techboard@dpdk.org Date: Wed, 05 Aug 2020 19:02:02 +0200 Message-ID: <6344259.PTXK2i140R@thomas> In-Reply-To: <20200805164504.GE1716@bricha3-MOBL.ger.corp.intel.com> References: <20200805142141.32337-1-bruce.richardson@intel.com> <2902184.3RBbl2PCEx@thomas> <20200805164504.GE1716@bricha3-MOBL.ger.corp.intel.com> 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" 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