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 2D2A8A0524; Thu, 30 Jan 2020 21:18:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D03C31C032; Thu, 30 Jan 2020 21:18:16 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 5F72F1C031 for <dev@dpdk.org>; Thu, 30 Jan 2020 21:18:15 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 8C3E785CF; Thu, 30 Jan 2020 15:18:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 30 Jan 2020 15:18:14 -0500 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=nAN7HQRT9FZaiZciGEPMdNCCzpAsvsyNsjYsG7gQ50Y=; b=NB3UQJjEaR3P zFU2FBKObokw6iXAOiqMwM8cYiGr8Pq5LL5maQIZ+3kR0Bj4eb5QzA66vT+SHZ9F nB+SUlHniVIEmblyDVFT4+NVAB0FJpjthXKLbJToscfmJPiMjnOhMMvhwxN8Yz8n /inX98PytvecFxhS2ZZOeC0TCzKoMgQ= 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=fm1; bh=nAN7HQRT9FZaiZciGEPMdNCCzpAsvsyNsjYsG7gQ5 0Y=; b=XuLdEZbIxEr192WlnngY9LgKZeT4POOU8Iu03CefPmXMEWJifgdGW5UoK Uds6GhTGL+NyhCem7XlE1tGfeAM4Cfr8nV/xF5H19nAt/UUC4tARjCYcyTyJXJoJ 9Q8zqdClD8x/ujW9i8YueUzSLND8hI+IVjUGDQa02DzfQNK6p8QV/WiYNw8hZUBt gZIC9tSFT0TzmAV66V6ynkG52tJAaGY3zJWeMREvOW6JhPebwpVpNBdxVGagztTU KGkYCmfWnkxVW41BKp1ukHwlIEfLPtveKkI/lq1rdJidUTPBc9c3cTkCvRyuco1O q+WMOnKN3xgjS2apsqlUKuduZijSQ== X-ME-Sender: <xms:BTozXmUYuwN6UjxUZnPaOdGB79NjftelL-Wlg5Kc7fHicWn74n2AKg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeekgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:BTozXoFATww3Y_jDZHZPMMwX95aTGHePOJPQAH2rmXM8FACsRjzUTQ> <xmx:BTozXiv0uCi4ASMQ4ZBXaKf33xCh6fYAH4JsQ3JmEtapTMzqdt5GeA> <xmx:BTozXrZXeX-pK1ixdhsKAVvI-Bg7gIMmNxaGw8W-nlFQUVyPF0cpHA> <xmx:BjozXuDr58o0CV0kiRWzioGuC99IfbA0zBtcPPegRSDh9-nyN3Qj1w> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 76AF03280062; Thu, 30 Jan 2020 15:18:12 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Akhil Goyal <akhil.goyal@nxp.com>, David Marchand <david.marchand@redhat.com>, Anoob Joseph <anoobj@marvell.com>, "Trahe, Fiona" <fiona.trahe@intel.com>, "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com> Cc: "dev@dpdk.org" <dev@dpdk.org>, "bruce.richardson@intel.com" <bruce.richardson@intel.com>, "nhorman@tuxdriver.com" <nhorman@tuxdriver.com>, John McNamara <john.mcnamara@intel.com>, "dodji@seketeli.net" <dodji@seketeli.net>, Andrew Rybchenko <arybchenko@solarflare.com> Date: Thu, 30 Jan 2020 21:18:10 +0100 Message-ID: <6121442.K2JlShyGXD@xps> In-Reply-To: <1ef7ca98-cff6-4c5d-5a71-ddbdf893ee73@intel.com> References: <20191220152058.10739-1-david.marchand@redhat.com> <VE1PR04MB663927B559D1077DF558222FE6050@VE1PR04MB6639.eurprd04.prod.outlook.com> <1ef7ca98-cff6-4c5d-5a71-ddbdf893ee73@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks 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> 30/01/2020 17:09, Ferruh Yigit: > On 1/29/2020 8:13 PM, Akhil Goyal wrote: > > > > > >> > >> On Wed, Jan 29, 2020 at 7:10 PM Anoob Joseph <anoobj@marvell.com> wrote: > >>> The asymmetric crypto library is experimental. Changes to experimental code > >> paths is allowed, right? > >> > >> The asymmetric crypto enum is referenced by a function part of the stable ABI. > >> It is possible to waive this enum, if we are sure no use out of the > >> experimental asym crypto APIs is possible. > >> > >> The rest of the changes touch stable symbols. > >> > >> Adding the abidiff report: > >> > >> [C]'function void rte_cryptodev_info_get(uint8_t, > >> rte_cryptodev_info*)' at rte_cryptodev.c:1115:1 has some indirect > >> sub-type changes: > >> parameter 2 of type 'rte_cryptodev_info*' has sub-type changes: > >> in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:468:1: > >> type size hasn't changed > >> 1 data member change: > >> type of 'const rte_cryptodev_capabilities* > >> rte_cryptodev_info::capabilities' changed: > >> in pointed to type 'const rte_cryptodev_capabilities': > >> in unqualified underlying type 'struct > >> rte_cryptodev_capabilities' at rte_cryptodev.h:176:1: > >> type size hasn't changed > >> 1 data member change: > >> type of '__anonymous_union__ ' changed: > >> type size hasn't changed > >> 1 data member change: > >> type of 'rte_cryptodev_asymmetric_capability > >> __anonymous_union__::asym' changed: > >> type size hasn't changed > >> 1 data member change: > >> type of > >> 'rte_cryptodev_asymmetric_xform_capability > >> rte_cryptodev_asymmetric_capability::xform_capa' changed: > >> type size hasn't changed > >> 1 data member change: > >> type of 'rte_crypto_asym_xform_type > >> rte_cryptodev_asymmetric_xform_capability::xform_type' changed: > >> type size hasn't changed > >> 2 enumerator insertions: > >> > >> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDSA' value '7' > >> > >> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' value '8' > >> 1 enumerator change: > >> > >> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END' > >> from > >> value '7' to '9' at rte_crypto_asym.h:60:1 > >> > > > > I believe these enums will be used only in case of ASYM case which is experimental. > > Independent from being experiment and not, this shouldn't be a problem, I think > this is a false positive. > > The ABI break can happen when a struct has been shared between the application > and the library (DPDK) and the layout of that memory know differently by > application and the library. > > Here in all cases, there is no layout/size change. > > As to the value changes of the enums, since application compiled with old DPDK, > it will know only up to '6', 7 and more means invalid to the application. So it > won't send these values also it should ignore these values from library. Only > consequence is old application won't able to use new features those new enums > provide but that is expected/normal. If library give higher value than expected by the application, if the application uses this value as array index, there can be an access out of bounds. > >> [C]'function int > >> rte_cryptodev_get_aead_algo_enum(rte_crypto_aead_algorithm*, const > >> char*)' at rte_cryptodev.c:239:1 has some indirect sub-type changes: > >> parameter 1 of type 'rte_crypto_aead_algorithm*' has sub-type changes: > >> in pointed to type 'enum rte_crypto_aead_algorithm' at > >> rte_crypto_sym.h:346:1: > >> type size hasn't changed > >> 1 enumerator insertion: > >> 'rte_crypto_aead_algorithm::RTE_CRYPTO_AEAD_CHACHA20_POLY1305' > >> value '3' > >> 1 enumerator change: > >> 'rte_crypto_aead_algorithm::RTE_CRYPTO_AEAD_LIST_END' from > >> value '3' to '4' at rte_crypto_sym.h:346:1 > > Same as above, no layout change. > > >> > >> > >> [C]'const char* rte_crypto_aead_algorithm_strings[1]' was changed at > >> rte_crypto_sym.h:358:1: > >> size of symbol (in bytes) changed from 24 to 32 > >> > > The shared memory size changes, but this is global variable in the library, and > the values application can request 'RTE_CRYPTO_AEAD_AES_CCM' & > 'RTE_CRYPTO_AEAD_AES_GCM' is already there, so there is no backward > compatibility issue here. For this one, I don't know what is the breakage. > > +Fiona and Arek > > > > We may need to revert the chacha-poly patches. > > > > I don't see any ABI break in this case, can someone explain if I am missing > anything here?