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 B1DF3A0597; Fri, 17 Apr 2020 18:01:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8D1FA1E981; Fri, 17 Apr 2020 18:01:31 +0200 (CEST) Received: from qrelay136.mxroute.com (qrelay136.mxroute.com [172.82.139.136]) by dpdk.org (Postfix) with ESMTP id 1E7021DD82 for ; Fri, 17 Apr 2020 18:01:30 +0200 (CEST) Received: from filter003.mxroute.com ([168.235.111.26] 168-235-111-26.cloud.ramnode.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay136.mxroute.com (ZoneMTA) with ESMTPA id 17188df9ef70000d83.002 for ; Fri, 17 Apr 2020 16:01:28 +0000 X-Zone-Loop: eada2e7325743c00a2341eb87cac9a66382df7abe966 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 503D36003F; Fri, 17 Apr 2020 16:01:23 +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 1jPT1R-0006he-Pq; Fri, 17 Apr 2020 11:35:18 -0400 To: "Trahe, Fiona" , Thomas Monjalon , "Richardson, Bruce" Cc: "dev@dpdk.org" , "Kusztal, ArkadiuszX" , Neil Horman , Luca Boccassi , Kevin Traynor , "Yigit, Ferruh" References: <20200318204136.10508-1-arkadiuszx.kusztal@intel.com> <20200417093129.GA1701@bricha3-MOBL.ger.corp.intel.com> <147b0819-6dba-7992-488c-2088d0baae75@ashroe.eu> <3220159.VZ3vTMCxA0@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: Date: Fri, 17 Apr 2020 17:01:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: 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] cryptodev: version rte_cryptodev_info_get function 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 17/04/2020 12:46, Trahe, Fiona wrote: > Hi all, > >> -----Original Message----- >> From: Ray Kinsella >> Sent: Friday, April 17, 2020 11:34 AM >> To: Thomas Monjalon ; Richardson, Bruce >> Cc: Trahe, Fiona ; dev@dpdk.org; Kusztal, ArkadiuszX >> ; Neil Horman ; Luca Boccassi >> ; Kevin Traynor ; Yigit, Ferruh >> Subject: Re: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function >> >> >> >> On 17/04/2020 11:17, Thomas Monjalon wrote: >>> 17/04/2020 11:42, Ray Kinsella: >>>> On 17/04/2020 10:31, Bruce Richardson wrote: >>>>> On Fri, Apr 17, 2020 at 08:24:30AM +0100, Ray Kinsella wrote: >>>>>> On 16/04/2020 11:01, Thomas Monjalon wrote: >>>>>>> 16/04/2020 11:51, Bruce Richardson: >>>>>>>> On Wed, Apr 15, 2020 at 06:24:19PM +0100, Trahe, Fiona wrote: >>>>>>>>> 5a. If in 20.05 we add a version of a fn which breaks ABI 20.0, what should the name of the >> original function be? fn_v20, or fn_v20.0 >>>>>>>> >>>>>>>> In technical terms it really doesn't matter, it's just a name that will be >>>>>>>> looked up in a table. I don't think we strictly enforce the naming, so >>>>>>>> whatever is clearest is best. I'd suggest the former. >>>>>>> >>>>>>> Each release can have a new ABI. >>>>>> >>>>>> How many ABI's do we want to support? >>>>>> >>>>> It's not how many we want to support, but for me it's a matter of how many >>>>> do we need to support. If an API is part of the stable set, it can't just >>>>> drop to being experimental for one or two releases - it's always stable >>>>> until deprecated. We also shouldn't have a situation where release 20.08 is >>>>> ABI compatible with 19.11 but not 20.02 and 20.05. >>>> >>>> True. Let me say it differently. >>>> >>>> Our only commitment is to support v20 - 19.11 >>>> However you are correct, if something gets committed as v21 in 20.02, in practise should also be >> there in 20.05+ also. >>>> Because if it is committed as v21 and not as experimental, it should not be changing once >> committed. >>>> >>>> In answering Thomas, >>>> I was more commenting on the proliferation of ABI numbers & symbols we need to track in the >> build. >>>> With v20, v21 & Experimental we need to keep track of 3. >>>> If we start allowing quarterly builds to have managed ABI's, it will get confusing. >>> >>> I don't remember why we are using intermediate ABI versions >>> between v20 and v21. >>> If we can use v21 for new ABI and make sure compatibility is maintained >>> between all versions from 19.11 to 20.08, I'm fine. > [Fiona] Here's a hypothetical case, but it illustrates why I don't think there > should be an expectation to maintain ABI compatibility here. > Example: in 20.05 add a new info_get_v21() which includes ChaChaPoly. > In 20.08 add another new algorithm. info_get_v21() return now includes this. > info_get_v21() will become stable in 20.11 and compatibility must be maintained from then on. Yes, and the v20 version gets removed in 20.11. > In the meantime, the fn is not experimental - that wouldn't be appropriate as it was a stable API. Well it could be ... these are just labels after all. So it entirely possible and permitted to have a info_get@DPDK_20.0 and info_get@EXPERIMENTAL simultaneously. In fact, if it is your expectation that new version will change in successively quarterly releases. That suggests it should be experimental. There in a gap here, we appear to be missing the required MACROS to support a v20.0 + EXPERIMENTAL simultaneously. As I remember this api was particularly sensitive to size of an enumeration? Has that been resolved to make the api less brittle? > But an app either wants stability and so should build against 19.11, or if prepared to move up to > one non-stable-ABI quarterly release should be willing to rebuild for the next non-stable-ABI quarterly release. > I think it's an unnecessary burden to require ABI compatibility across quarterly releases. I generally agree with this point. Our only cast iron solid commitment is compatibility with 19.11. That said, once any API has dropped the EXPERIMENTAL label, it shouldn't be changing. All things being equal quarterly releases should be compatible with each other, as v21 APIs should not be changing. > And if required could end up with the version tracking hassle Ray referred to above with fn versions > of 20.0.1, 20.0.2, 20.0.3, v21, and potentially several versions of same fn. > >