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 BBB40A0093; Mon, 18 May 2020 13:49:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2C48A1D405; Mon, 18 May 2020 13:49:01 +0200 (CEST) Received: from relay0146.mxlogin.com (relay0146.mxlogin.com [199.181.239.146]) by dpdk.org (Postfix) with ESMTP id 0F47F1C435 for ; Mon, 18 May 2020 13:48:59 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by relay0146.mxlogin.com (ZoneMTA) with ESMTPSA id 172279d9771000e6c4.002 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 18 May 2020 11:48:58 +0000 X-Zone-Loop: ab96ce5c6f6bc32829cff5ce2d85c6b4bdad357f89d4 X-Originating-IP: [149.28.56.236] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter004.mxroute.com (Postfix) with ESMTPS id 21B6A3EDAB; Mon, 18 May 2020 11:48:50 +0000 (UTC) Received: from [192.198.151.43] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1jadoO-0008I5-Qu; Mon, 18 May 2020 07:20:01 -0400 To: Thomas Monjalon , "Yigit, Ferruh" , "Dumitrescu, Cristian" Cc: Neil Horman , Eelco Chaudron , "dev@dpdk.org" , David Marchand , "stable@dpdk.org" , Luca Boccassi , "Richardson, Bruce" , "Stokes, Ian" , Andrzej Ostruszka References: <20200513121149.2283385-1-ferruh.yigit@intel.com> <3888163.3T5rpR7ggn@thomas> <69122822.RN2Pgac3cq@thomas> 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: <2fd78dc9-b63a-6a86-f9f5-ccb40b41118a@ashroe.eu> Date: Mon, 18 May 2020 12:48:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <69122822.RN2Pgac3cq@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v4] meter: provide experimental alias of API for old apps 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 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.