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 6D420A0553; Mon, 17 Feb 2020 15:23:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5A7681DA9F; Mon, 17 Feb 2020 15:23:33 +0100 (CET) Received: from qrelay153.mxroute.com (qrelay153.mxroute.com [172.82.139.153]) by dpdk.org (Postfix) with ESMTP id 6C9CF1DA9E for ; Mon, 17 Feb 2020 15:23:31 +0100 (CET) Received: from filter003.mxroute.com ([168.235.111.26] 168-235-111-26.cloud.ramnode.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay153.mxroute.com (ZoneMTA) with ESMTPA id 1705388548a000088e.002 for ; Mon, 17 Feb 2020 14:23:28 +0000 X-Zone-Loop: 2db63459f695d19491af799cfb3ff6a188ff6f505e05 X-Originating-IP: [168.235.111.26] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter003.mxroute.com (Postfix) with ESMTPS id E99966000C; Mon, 17 Feb 2020 14:23:22 +0000 (UTC) Received: from [134.191.227.39] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1j3gyX-0007ZF-7H; Mon, 17 Feb 2020 09:02:17 -0500 To: Neil Horman , Bruce Richardson Cc: Luca Boccassi , Ferruh Yigit , Cristian Dumitrescu , Eelco Chaudron , dev@dpdk.org, Thomas Monjalon , David Marchand , Ian Stokes References: <20200129122953.2016199-1-ferruh.yigit@intel.com> <20200202185334.GA6783@localhost.localdomain> <7beadbbd-bf0d-e545-d9bb-0e3ae8228b71@intel.com> <20200204120230.GA13754@hmswarspite.think-freely.org> <8eaaec5dedcfcf09ae69b15cc80ac1ff1a1f4a30.camel@debian.org> <20200205113245.GA17468@hmswarspite.think-freely.org> <20c7c2a7-54f7-996f-923a-82202ebc66eb@ashroe.eu> <20200214023820.ogc2neraxwwtolde@penguin.lxd> <20200214113634.GA853@bricha3-MOBL.ger.corp.intel.com> <20200214204848.GA27176@hmswarspite.think-freely.org> From: Ray Kinsella Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <6226ac31-525e-724f-64e4-bbd4a4742350@ashroe.eu> Date: Mon, 17 Feb 2020 14:23:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200214204848.GA27176@hmswarspite.think-freely.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal 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" On 14/02/2020 20:48, Neil Horman wrote: > On Fri, Feb 14, 2020 at 11:36:34AM +0000, Bruce Richardson wrote: >> On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: >>> On Thu, Feb 13, 2020 at 05:40:43PM +0000, Ray Kinsella wrote: >>>> >>>> >>>> On 05/02/2020 11:32, Neil Horman wrote: >>>>> On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: >>>>>> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: >>>>>>>> But if we can do the versioning in the master, LTS can backport it >>>>>>>> and can have mature version of that API in LTS without breaking >>>>>>>> the existing users. >>>>>>>> >>>>>>> >>>>>>> But why bother? The only thing you've changed is the version >>>>>>> tagging. Its ok to leave that alone in LTS, you just cant change >>>>>>> it. >>>>>>> >>>>>>> Thats part of the burden of an LTS release, it will have some drift >>>>>>> from the upstream head, because you have to keep things stable. So >>>>>>> you stabilize the upstream ABI version for this API and just never >>>>>>> backport it to the current LTS release. >>>>>> >>>>>> Hi, >>>>>> >>>>>> A customer (OVS) explicitly and specifically requested backporting >>>>>> the symbol change to 19.11, as they don't want to enable >>>>>> experimental APIs in their releases. I replied that it would only be >>>>>> acceptable with aliasing to keep compatibility, and Ferruh very >>>>>> kindly did the work to implement that. >>>>>> >>>>> but, thats part of the agreement, no? You can't always have new >>>>> features and stability at the same time. >>>>> >>>>> I get that this is an odd corner case, because strictly speaking you >>>>> could waive the ABI change that libabigail is reporting, and most >>>>> application users (like OVS) could get away with it, because their >>>>> application does all the right things to make it ok, but I don't >>>>> think you can make a decsion like this for all users based on the >>>>> request of a single user. >>>>> >>>>> It seems like the right thing is for OVS to augment their build time >>>>> configuration to allow developers to select the ability to use >>>>> experimental apis at compile time, and then the decision is placed in >>>>> the hands of end users. >>>> >>>> So this is not isolated case right ... it is common from API's to >>>> graduate from experimental to mature, we _want_ that to happen, we >>>> _want_ APIs to mature. >>>> >>> Sure, I can absolutely agree with that, though I would suggest that the >>> maturity of the ABI is orthogonal to its labeling as such (more on that >>> below) >>> >>>> I am worried what you are proposing will encourage a behavior whereby >>>> maintainers to wait until the declaration of the next major ABI version >>>> to make these symbol changes, causing these kinds of changes to queue >>>> up for that release. >>>> >>> I think you're probably right about that, and would make the agrument >>> that thats perfectly fine (again I'll clarify below) >>> >>>> And you would have to ask why? In the case of a reasonably mature API, >>>> there will be no functional or signature change - its mature! So what >>>> is the harm of providing an alias back to Experimental until the next >>>> ABI version is declared? >>>> >>> From a philosophical standpoint, there is absoluely no harm, and I don't >>> think anyone would disagree, the harm comes from the details of the >>> implementation, as you've noted. >>> >>>> So while yes, you are 100% right - experimental mean no guarantees. >>>> But if the API is baked, it is not going to change, so I don't see the >>>> harm. >>>> >>>> We don't want the unnecessary triumph of policy over pragmatism. >>>> >>> I would make the converse argument here. While I agree that when an API >>> is mature, theres no point in calling it experimental anymore, I would >>> also suggest that, if an API is mature, and not expected to change, >>> theres no harm in leaving its version tag as experimental for an LTS >>> release. This is what I was referring to above. Once an application >>> developer has done the work to integrate an API from DPDK into its >>> application, that work is done. If the API remains stable, then I >>> honestly don't know that they care that the version label is EXPERIMENTAL >>> versus 20.11 or 20.05 or whatever. They care about the API being stable >>> more so than its version label. As such, it seems....reasonable to me to >>> have developers queue their migration of experimental APIs to official >>> versioned APIs at the next major release deliniation point. >>> >>> I'd welcome counter arguments, but it seems pretty natural to me to make >>> these sorts of changes at the major release mark. People using >>> experimantal apis have already implicity agreed to manage changes to >>> them, so if we just hold it stable in an LTS release (and don't update >>> the version label), its just gravy for them. >>> >> The counter argument that I see is that while the experimental tag remains >> in place the user has no way to know that an API is stable or not, and so >> in many projects cannot use the API. If for example an API that is >> experimental in 19.11 is unchanged through 20.05 at which point we decide >> to promote it to stable. Once the change to the exp tag it is made, any >> users of 19.11 can then see that it is an unchanged and now-stable ABI and >> can start using it in their software, if they wish, without having to wait >> for the 20.11 release. Changing the tag early allows ABIs to be potentially >> used immediately. >> > > I would agree with this, however, when using an LTS release, in my mind at > least, part of the agreement there is you get stability in the fuctions that > were declared stable at the time of release. I'm not sure there should be an > expectation of additional stabilization within the lifetime of the release > (thats really what the 12 month LTS release cycle is for, no)? You never have > to wait more than a year for a new set of stable features. If you want faster > feature integration than that, you can choose to enable the experimental API's > and accept the benefits and drawbacks thereof. > > That said, if (as I understand it) the goal is to provide a mechanism to allow > experimental features to be promoted to stable status, perhaps we can find a > happy middle ground. What if we were to create a construct such as this: > > #pragma push_macro("ALLOW_EXPERIMENTAL_APIS") > #undef ALLOW_EXPERIMENTAL_APIS > void __rte_experimental func(...); > #pragma pop_macro("ALLOW_EXPERIMENTAL_APIS") > > Such a consruct would allow the maintainer of an API to pseudo-promote an API > from a experimental to stable status, at least so far as compilation would be > concerned. Its messy and clunky, and it wouldn't change the function version at > all, but the end result would be that: > a) such a wraped experimental function would no longer issue a warning when used > during compilation/linking > and > b) provide a semi-easy grepable pattern for application writers to look for when > considering the use of an API that was previously experimental > > such a construct would have to be used very judiciously, in that once its > implemented, the API has to be treated as stable, even though its 'excused' from > the normal checking, but it could provide something of the more rapid promotion > path being sought. > > Thoughts? > Neil >> Regards, >> /Bruce >> Then method above seems clunky, and it is unclear to me if it solves the original problem. It seems simpler to me to promote a symbol the next ABI version, and then provide an alias. At the declaration of the next major ABI version (v21), we would then only need to check for those symbols that are both EXPERIMENTAL and v21, to know which aliases need to be removed. Thanks, Ray K