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 CAC10A058A; Fri, 17 Apr 2020 11:31:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90C0D1DEE5; Fri, 17 Apr 2020 11:31:36 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 555E91DEE2 for ; Fri, 17 Apr 2020 11:31:35 +0200 (CEST) IronPort-SDR: 10d1eZZwYq4Nw3ryAcLZyQlci0XVJaM0if2ZGIGluXHEGSkN6DNQh3y/6qUnjBv/ZIBanFdods 19w0+nfHeB8A== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Apr 2020 02:31:34 -0700 IronPort-SDR: pGDpWCA0Lkmyx9YeI3Wgn8e/HN1z9e5ubR4HDLAGI+5rocKiktJPdfQ4DfjRZda3+6X7BLcTqe FSnM5lMW/bQA== X-IronPort-AV: E=Sophos;i="5.72,394,1580803200"; d="scan'208";a="289211301" Received: from bricha3-mobl.ger.corp.intel.com ([10.212.38.175]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 17 Apr 2020 02:31:32 -0700 Date: Fri, 17 Apr 2020 10:31:29 +0100 From: Bruce Richardson To: Ray Kinsella Cc: Thomas Monjalon , "Trahe, Fiona" , "dev@dpdk.org" , "Kusztal, ArkadiuszX" , Neil Horman , Luca Boccassi , Kevin Traynor , "Yigit, Ferruh" Message-ID: <20200417093129.GA1701@bricha3-MOBL.ger.corp.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24735aee-93d4-49fd-acf3-95673a2334bf@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 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. > > 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. /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 > >