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 61B48A00C2; Sat, 25 Apr 2020 18:04:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E03C0397D; Sat, 25 Apr 2020 18:04:19 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 356252BE9 for ; Sat, 25 Apr 2020 18:04:18 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id EB6747E3; Sat, 25 Apr 2020 12:04:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 25 Apr 2020 12:04:17 -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= S1IH1ozhDkZ1uqo7X4fmj0Jotw4Af/nOF2hLe5/CL2k=; b=ULNWnW2ZlegDkCPV Sn9wI9ovPteBDLNwyPWGi7CrtwDsJsMpG0YNj/F6pT3oBrLfucZV7EBkn+I8p+CI HSep0ALWi95IDRTYizYNnV0ZMhg/hWwBeNRAgKBLf/YhzGytAsn4+9gaAOjjd3ih 7BNK1sJIHeNh+o51PAxODQRWAC82bDzmwFLF7ZdVNlWH5sZWBhdj9OekSMF9dxJS wze225Lt2WADrDZEX6KCBC6PIXEDgZignzI8F/jUQlxPEp2GhOriG91JRLa++WGX pH8lbort6F2/Y+M2rCwmKyeFc//a8/vvotp+s/zpGv740bdEuAXI9VNkDjXzyGtP SmRkng== 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=S1IH1ozhDkZ1uqo7X4fmj0Jotw4Af/nOF2hLe5/CL 2k=; b=fNGffcyWlhq1o3mqbaeMR0iW/Vbm198oG3fmkgjkLHgsl5btHjU8RlAVO XThv8uE1HdhB/KJNySbQxhmkkATXJYs+FY+4gG/NWuaWesyoMdIrGVye3Yb3E/gB 3lf84dSbg4ftCQUgRkicAt8YLaM+19KTrOdeTmmW1PiyhEDSf3txC3YU6QJH9La1 Z5f0qUiO5uOAWftJw6MpenYIdktaBS+bJvHrYHiMvcyc6y9XQ4t/bvg+WTNVuluZ 73wXOeUxeIjeGlvmF0awbkaiHclvw+Khr4UXscwYPFRL6AEwpy+MNGpSnWzvIrhL QU6A5W24/U0vDb8kNa54gi9NzE/9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheeggdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 615703280063; Sat, 25 Apr 2020 12:04:15 -0400 (EDT) From: Thomas Monjalon To: ray.kinsella@intel.com, nhorman@tuxdriver.com, Kevin Laatz Cc: dev@dpdk.org, bruce.richardson@intel.com, harry.van.haaren@intel.com, david.marchand@redhat.com Date: Sat, 25 Apr 2020 18:04:14 +0200 Message-ID: <1651663.4herOUoSWf@thomas> In-Reply-To: <20200416110040.42819-1-kevin.laatz@intel.com> References: <20200330121502.25555-1-kevin.laatz@intel.com> <20200416110040.42819-1-kevin.laatz@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] 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" 16/04/2020 13:00, Kevin Laatz: > This patch adds CPU flags which will enable the detection of ISA > features available on more recent x86 based CPUs. [...] > --- a/devtools/libabigail.abignore > +++ b/devtools/libabigail.abignore > +; Ignore this enum update as it should not be allocated by the application > +[suppress_type] > + type_kind = enum > + name = rte_cpu_flag_t > + changed_enumerators = RTE_CPUFLAG_NUMFLAGS The justification is not correct. The application is allowed to use RTE_CPUFLAG_NUMFLAGS in array allocation. But no API is returning a CPU flag, so the new flags will remain unknown to the application. However, there is a behaviour change: The functions rte_cpu_get_flag_name() and rte_cpu_get_flag_enabled() will now accept new values, which were previously considered as an error. Is it an ABI breakage? I would say no. PS: Who is REALLY maintaining the ABI? We really miss someone who carefully check all these things, and take care of the doc and tooling.