From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1A29C352BE for ; Fri, 17 Apr 2020 09:42:40 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 0EAC62072D for ; Fri, 17 Apr 2020 09:42:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EAC62072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ashroe.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 72FC61DEF1; Fri, 17 Apr 2020 11:42:39 +0200 (CEST) Received: from qrelay160.mxroute.com (qrelay160.mxroute.com [172.82.139.160]) by dpdk.org (Postfix) with ESMTP id 381E61DEEC for ; Fri, 17 Apr 2020 11:42:37 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay160.mxroute.com (ZoneMTA) with ESMTPA id 1718784addf0000d83.002 for ; Fri, 17 Apr 2020 09:42:31 +0000 X-Zone-Loop: ba41d1e02297c781585603a88af4db8d41914a7cd37b 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 32C253EACF; Fri, 17 Apr 2020 09:42:26 +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 1jPN6j-00022Z-Lr; Fri, 17 Apr 2020 05:16:22 -0400 To: Bruce Richardson Cc: Thomas Monjalon , "Trahe, Fiona" , "dev@dpdk.org" , "Kusztal, ArkadiuszX" , Neil Horman , Luca Boccassi , Kevin Traynor , "Yigit, Ferruh" References: <20200318204136.10508-1-arkadiuszx.kusztal@intel.com> <20200416095124.GA1691@bricha3-MOBL.ger.corp.intel.com> <4271918.xgJ6IN8ObU@thomas> <24735aee-93d4-49fd-acf3-95673a2334bf@ashroe.eu> <20200417093129.GA1701@bricha3-MOBL.ger.corp.intel.com> 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: <147b0819-6dba-7992-488c-2088d0baae75@ashroe.eu> Date: Fri, 17 Apr 2020 10:42:17 +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: <20200417093129.GA1701@bricha3-MOBL.ger.corp.intel.com> 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 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. > >>> The same function can have a different version in 20.02, 20.05 and 20.08. >>> If you name it fn_v20 in 20.05, what will be the name for the new version >>> in 20.08? I suggest using the release number when versioning a function. >>> >> >> ok - so this is exactly _not_ what we wanted at the outset. >> >> We committed to support a single ABI, that is the 19.11 (v20) ABI until the 20.11 (v21) ABI. >> We do _not_ support ABI stability in quarterly releases, as the support overhead would balloon overtime. >> >> Really why would we do this - who would benefit? >> >> Do we envisage a situation that someone who built against the say 20.02 shared libraries. >> would expect their binaries to port to 20.05 without a rebuild? >> > I would have expected that, yes, as all have the v20 ABI. > Maybe I need to change my expectations, though. You are correct. However I guess, I would still see them as slightly different levels of commitment. > > /Bruce > >> It would also defeat the purpose of EXPERIMENTAL, if the community where willing to support any permutation of an API. >> Why would ever bother to use experimental? >> >> I have a bit more checking to do, but IMHO the following we should fix the following commits such that APIs are either EXPERIMENTAL or staged for v21. >> >> root@ashroe.eu:/build/dpdk# find . -name *.map | xargs grep 20.0.1 >> ./lib/librte_meter/rte_meter_version.map:DPDK_20.0.1 { >> ./drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map:DPDK_20.0.1 { >> ./drivers/net/ionic/rte_pmd_ionic_version.map:DPDK_20.0.1 { >> ./drivers/common/octeontx2/rte_common_octeontx2_version.map:DPDK_20.0.1 { >> ./drivers/common/mlx5/rte_common_mlx5_version.map:DPDK_20.0.1 { >> ./drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map:DPDK_20.0.1 { >> >> Thanks, >> >> Ray K >> >>