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 D3579A057C; Fri, 27 Mar 2020 15:15:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A35F71C1EB; Fri, 27 Mar 2020 15:15:39 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 999201C1D8 for ; Fri, 27 Mar 2020 15:15:37 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2BD975C0508; Fri, 27 Mar 2020 10:15:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 27 Mar 2020 10:15:36 -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=mesmtp; bh=8mKaPR9SdD7Yru1acWHF8y7gvCmrvpvYHeHGXZRMIc4=; b=sRi+xePbpMwi nrLvfY0TMEQDdQq+u3gjmPcnw+axVinSHSFja1EGE208u4E7KAZ3QXGGTYtT27SK ZPMo5o4eUQ72b2/3eLQPDJOBtGFaBZqLKMqltNZtFQGFt4JBzG13U8SRzdBkq1sa kBuW0qxDyxQlcUWoGay+GQ47WVneJPI= 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=fm2; bh=8mKaPR9SdD7Yru1acWHF8y7gvCmrvpvYHeHGXZRMI c4=; b=pAI9iUYLrRdqHoO3ZieIqpuTSiDDGHV9O3k7HoCgXqx7zcQPyfdvw4Mf/ Vez6caXnq3fx9h1i34RZNvnz2ABF703nni0w5msNP0fj3kPIfFKhNDjHWCE5iwl4 Bl94BlGI0WtLZCHh2Eca1C9cQrn8AZgiOiZ6SvDnFXO+qWfZ72n6uXxvdRTF5wpQ XjABBm1m5zQZYbemWQ7qifXGa9MhYU8KLgeHvlqiLzPHsR8W8PizOsF7PRx0W2fS jKluaHc/zU+AG+c40aesgzsJIwOVPeUKNRmm13LKUNrN8wLBe1lI5k6ThkmsTu2u DK3rcR33vaxITr2cQJs/n5CGCCW3w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehledgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehtrhgrvhhishdqtghirdgtohhmnecukfhppeejjedrudefgedrvddtfedr udekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 D2ED8306C228; Fri, 27 Mar 2020 10:15:33 -0400 (EDT) From: Thomas Monjalon To: Neil Horman , Dodji Seketeli , mdr@ashroe.eu Cc: David Marchand , Kevin Laatz , dev , Bruce Richardson , Van Haaren Harry , Honnappa Nagarahalli Date: Fri, 27 Mar 2020 15:15:32 +0100 Message-ID: <1849712.2IRrRt1zHL@xps> In-Reply-To: <20200327134441.GA3540715@hmswarspite.think-freely.org> References: <20200324114921.7184-1-kevin.laatz@intel.com> <20200327134441.GA3540715@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] eal/cpuflags: add x86 based cpu 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" 27/03/2020 14:44, Neil Horman: > On Fri, Mar 27, 2020 at 01:24:12PM +0100, David Marchand wrote: > > On Wed, Mar 25, 2020 at 12:11 PM Kevin Laatz wrote: > > > --- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h > > > +++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h > > > @@ -113,6 +113,24 @@ enum rte_cpu_flag_t { > > > /* (EAX 80000007h) EDX features */ > > > RTE_CPUFLAG_INVTSC, /**< INVTSC */ > > > > > > + RTE_CPUFLAG_AVX512DQ, /**< AVX512 Doubleword and Quadword */ > > > + RTE_CPUFLAG_AVX512IFMA, /**< AVX512 Integer Fused Multiply-Add */ > > > + RTE_CPUFLAG_AVX512CD, /**< AVX512 Conflict Detection*/ > > > + RTE_CPUFLAG_AVX512BW, /**< AVX512 Byte and Word */ > > > + RTE_CPUFLAG_AVX512VL, /**< AVX512 Vector Length */ > > > + RTE_CPUFLAG_AVX512VBMI, /**< AVX512 Vector Bit Manipulation */ > > > + RTE_CPUFLAG_AVX512VBMI2, /**< AVX512 Vector Bit Manipulation 2 */ > > > + RTE_CPUFLAG_GFNI, /**< Galois Field New Instructions */ > > > + RTE_CPUFLAG_VAES, /**< Vector AES */ > > > + RTE_CPUFLAG_VPCLMULQDQ, /**< Vector Carry-less Multiply */ > > > + RTE_CPUFLAG_AVX512VNNI, /**< AVX512 Vector Neural Network Instructions */ > > > + RTE_CPUFLAG_AVX512BITALG, /**< AVX512 Bit Algorithms */ > > > + RTE_CPUFLAG_AVX512VPOPCNTDQ, /**< AVX512 Vector Popcount */ > > > + RTE_CPUFLAG_CLDEMOTE, /**< Cache Line Demote */ > > > + RTE_CPUFLAG_MOVDIRI, /**< Direct Store Instructions */ > > > + RTE_CPUFLAG_MOVDIR64B, /**< Direct Store Instructions 64B */ > > > + RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register Intersection */ > > > + > > > /* The last item */ > > > RTE_CPUFLAG_NUMFLAGS, /**< This should always be the last! */ > > > > This is seen as an ABI break because of the change on _NUMFLAGS: > > https://travis-ci.com/github/ovsrobot/dpdk/jobs/302524264#L2351 > > > It shouldn't be, as the only API calls we expose that use rte_cpu_flag_t accept > it as an integer parameter to see if the flag is enabled. Theres no use of the > enum in a public array or any struct that is sized based on the number of flags, > so you should be good to go Indeed I cannot imagine an ABI incompatibility in this case. The only behaviour change is to accept new (higher) RTE_CPUFLAG values in functions rte_cpu_get_flag_enabled() and rte_cpu_get_flag_name(). Is changing the range of valid values an ABI break? Why is it flagged by libabigail?