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 C8622A04A2 for ; Mon, 18 May 2020 14:14:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A69331D421; Mon, 18 May 2020 14:14:02 +0200 (CEST) Received: from wnew1-smtp.messagingengine.com (wnew1-smtp.messagingengine.com [64.147.123.26]) by dpdk.org (Postfix) with ESMTP id ADE2D1D158; Mon, 18 May 2020 14:13:59 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id F2F09580; Mon, 18 May 2020 08:13:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 18 May 2020 08:13:56 -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= U9PHWBsJWe5BBJQwbsC1i3nF58kqu0Vi+H/Xwj88+E4=; b=CaTBLBrNmjRzNa4c vihN5E530LIRoX/n4Br5y//0/Z72BE1Xwqd4jnqVrQzqw8ULAQjyUoFpppmXh4zR jCkVlb+KZK2BVp5uZrXQMOmVQQRTad/L+fMq49Kx3s+UPQGO4+QOoeTNbT/p/ANs MLHrhAdEJUVpWIrbJYaQBxVtYD/cJgtoORCeeeHCKIkpclQqIL8v07r5bUWndtY7 zSp9lR65DjxpWMx20LY/6GSNxpa81AkSP7PTp1yTGEXg14Q+204aenjHrr4FazO+ IUr9961/+JxVanvSVoOEOkTKv/ZZe/fyPh/mHxAQYXjRswy6eAWcnNw/9nAV5P/S qwluAA== 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=U9PHWBsJWe5BBJQwbsC1i3nF58kqu0Vi+H/Xwj88+ E4=; b=2jUf0/Chgk+3aXXfU7Kogg67lGN6gMwyumiONEPQ3jQg+Yb3jcx5OQ5HJ jqaYHK4cajqUmX1+wY2rutzu3aArXA7tM96O+x1B5mL0QvkfFS7y5RctK7UtfeEn zdy58tvzkeKH06hznve4TdM593nKzGTdNQo8Lba9HZcfWRByu9XdeszQHLCOf5K1 jT7QgL6R+Z7jnV7HGwIkaV/z1DuFnWeZP07qQsj0culLWVIPfQT5gOW6ESi7DsdA RgpYIeiVv+f/ArdViCEO2hoBfalKH1e2lKX4C4iJD8d0+hGr2BlrbtuBAnmBSswK GrEMnWiFMvJJPmgK/sqQSOGpFN25A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddthedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 ECDEE328005E; Mon, 18 May 2020 08:13:52 -0400 (EDT) From: Thomas Monjalon To: "Yigit, Ferruh" , "Dumitrescu, Cristian" , Ray Kinsella Cc: Neil Horman , Eelco Chaudron , "dev@dpdk.org" , David Marchand , "stable@dpdk.org" , Luca Boccassi , "Richardson, Bruce" , "Stokes, Ian" , Andrzej Ostruszka Date: Mon, 18 May 2020 14:13:50 +0200 Message-ID: <9695064.U7f9L36N0a@thomas> In-Reply-To: <2fd78dc9-b63a-6a86-f9f5-ccb40b41118a@ashroe.eu> References: <20200513121149.2283385-1-ferruh.yigit@intel.com> <69122822.RN2Pgac3cq@thomas> <2fd78dc9-b63a-6a86-f9f5-ccb40b41118a@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [PATCH v4] meter: provide experimental alias of API for old apps X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 18/05/2020 13:48, Ray Kinsella: > On 18/05/2020 11:46, Thomas Monjalon wrote: > > 18/05/2020 11:30, Ray Kinsella: > >> On 18/05/2020 10:22, Thomas Monjalon wrote: > >>> 18/05/2020 08:29, Ray Kinsella: > >>>> On 17/05/2020 20:52, Dumitrescu, Cristian wrote: > >>>>> From: Yigit, Ferruh > >>>>>> > >>>>>> On v20.02 some meter APIs have been matured and symbols moved from > >>>>>> EXPERIMENTAL to DPDK_20.0.1 block. > >>>>>> > >>>>>> This can break the applications that were using these mentioned APIs on > >>>>>> v19.11. Although there is no modification on the APIs and the action is > >>>>>> positive and matures the APIs, the affect can be negative to > >>>>>> applications. > >>>>>> > >>>>>> Since experimental APIs can change or go away without notice as part of > >>>>>> contract, to prevent this negative affect that may occur by maturing > >>>>>> experimental API, a process update already suggested, which enables > >>>>>> aliasing without forcing it: > >>>>>> https://patches.dpdk.org/patch/65863/ > >>>>>> > >>>>> > >>>>> Personally, I am not convinced this is really needed. > >>>>> > >>>>> Are there any users asking for this? > >>>> > >>>> As it happens it is all breaking our abi regression test suite. > >>>> One of the things we do is to run the unit tests binary from v19.11 against the latest release. > >>>> > >>>>> Is there any other library where this is also applied, or is librte_meter the only library? > >>>> > >>>> librte_meter is the only example AFAIK. > >>>> But then we only have one example of needing symbol versioning also at the moment (Cryptodev). > >>>> > >>>> This is going to happen with experimental symbols that have been around a while, > >>>> that have become used in applications. It is a non-mandatory tool a maintainer can use > >>>> to preserve abi compatibility. > >>> > >>> If you want to maintain ABI compatibility of experimental symbols, > >>> it IS a mandatory tool. > >>> You cannot enforce your "ABI regression test suite" and at the same time > >>> say it is "non-mandatory". > >>> > >>> The real question here is to know whether we want to maintain compatibility > >>> of experimental symbols. We said no. Then we said we can. > >>> The main concern is the message clarity in my opinion. > >>> > >> > >> There is complete clarity, there is no obligation. > >> Our lack of obligation around experimental, is upfront in the policy is upfront in the policy. > >> > >> "Libraries or APIs marked as experimental may change without constraint, as they are not considered part of an ABI version. Experimental libraries have the major ABI version 0." > >> > >> Later we give the _option_ without obligation to add an alias to experimental.pls see the v6. > >> > >> + - In situations in which an ``experimental`` symbol has been stable for some > >> + time. When promoting the symbol to become part of the next ABI version, the > >> + maintainer may choose to provide an alias to the ``experimental`` tag, so > >> + as not to break consuming applications. > >> > >> So it is something a Maintainer, _may_ choose to do. > >> I use the word, "may" not "will" as there is no obligation's associated with experimental. > > > > > > OK Ray, this is my understanding as well. > > > > The only difficult part to understand is when claiming > > "it is all breaking our abi regression test suite" > > to justify the choice. > > Justification, is the same as any other consumer of DPDK saying you broke my APP. > > > As the maintainer (Cristian) says he does not like this change, > > it means the regression test suite should skip this case, right? > > So the regression test run the v19.11 Unit Test's against the v20.05 rc. > My thought was that would provide reasonably good coverage of the ABI to catch more subtly regression. > Those regressions that affect the behavior of the ABI (the contract), instead of ABI itself. I understand the goal. And I think, because of this goal, you will try to maintain ABI compat of *ALL* experimental symbols maturing as stable symbol.