From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:hgp-XoTs-XsfzQ-yEg-A9pGdgzh40uWKkh2Iocis_Dle-bLfwyP64A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehledgiedtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff
homhgrihhnpehtrhgrvhhishdqtghirdgtohhmnecukfhppeejjedrudefgedrvddtfedr
udekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
hthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:hgp-XvcuJbP7GhhC4EzF31O_G14tB2qYBCp3zkociI9-JRQETWkxOQ>
<xmx:hgp-XlIqHCzHAVAz4_QQhwPbI60mTDZu-sxSPWgmDwzEdfKL-O2hMQ>
<xmx:hgp-XkHPnEUtUo9uxVkwI4d1J1sPN6H12Rg7Fw43WsCQzYAxZkf0EA>
<xmx:iAp-Xrfsjt0AHJZ_R0pDY9TObV4EmIVl4Wzm47qxShgg0jhUEVOnxQ>
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 <thomas@monjalon.net>
To: Neil Horman <nhorman@tuxdriver.com>, Dodji Seketeli <dodji@redhat.com>,
mdr@ashroe.eu
Cc: David Marchand <david.marchand@redhat.com>,
Kevin Laatz <kevin.laatz@intel.com>, dev <dev@dpdk.org>,
Bruce Richardson <bruce.richardson@intel.com>,
Van Haaren Harry <harry.van.haaren@intel.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
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>
<CAJFAV8yaPq0Cjgu=gbcq3qBp7eyq4Qv8-m24NxS9KoMhUh6JkA@mail.gmail.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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <kevin.laatz@intel.com> 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?