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 F0A6BA04F5; Thu, 12 Dec 2019 10:55:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 87F7E1BEC4; Thu, 12 Dec 2019 10:55:37 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 98A671BE3D for ; Tue, 10 Dec 2019 16:40:36 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2019 07:40:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,300,1571727600"; d="scan'208";a="363294914" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 10 Dec 2019 07:40:34 -0800 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Dec 2019 07:40:34 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Dec 2019 07:40:34 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.168) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Dec 2019 07:40:34 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EUX7uCNSdifp5h9W0YT1n/ljt61bVT4YZR8KXSH9pOjVML1GTjJ8LxN2fZQknE4G4kA4tpy8r46t9Y2SE0aVVD2aCzQPACdlWrVxRgTlFn3xBtQKY94ZE+K1oiwrA7syb2Jn8vD0BdbJ1qA/H9AgsaXj1EyxC5LptRmhXN7PWUg6hjkbsuVDESh12+5H+AREGTlSa8t8zFlLCEChCj+GGtfvF8PhVj1sxJgLZ6Mu/1a3T2yM6q+e6P1CK5PwYRLI3Tdvs2JUW2hE7F9UHKoU/eAomxjGgt1R+2wzMJSHFyHfUnUhJXA4r7WZsd3GuZCjGieyxQNs2g47HLNv4GQBjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u/TSmJbWvZ660dWQPo6zwZe4WiHYWj6ZZ7tee7AonF8=; b=Vdh4UfynkjlzsXplBUj/5TZK/PUiFr77lQZJpYisfTCyjY45QPfgVK5mi13PsXz0iol6aiAKmNo2EdTDYo6WP7HdvloQytVB8dgm15TN6kkpXFHF0wSVdW8TVahZHxG3MgQqsvN3mpILKAUpATkwTO49an0gvhq6bvpjQr+g5KxzvwTQ1kjoyQD/T54DygGc7He31sriW/QeHU7aBcH7g5RHqVLC9+xUkqUdWnG9dckImWPXwSU2i3J8u61OVKWHdbhwLBce6nC+QiPqWLZcXqwdxy5HZrk+H3FBj0GmsoB/EZncxTD0fUL4q/+FXWZPjHBzQCYD3HQfLdjRzrGT1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u/TSmJbWvZ660dWQPo6zwZe4WiHYWj6ZZ7tee7AonF8=; b=WYgMBubphU7ZydYKweY2hSrbU5WzCMxVpDOwXzYCu56UF6sLJxRDB7cPngquxzsyLDzP/h2Oys51JXgTqYYd5rTAvYiGIM2yolgp1jHUkcdE1QSUSdxjORbbBaIrnKvuS+B9P6fhuZzWVMG0Acxw8SrtfPT3HR2rAi4hjqS4cNM= Received: from BN6PR11MB4145.namprd11.prod.outlook.com (10.255.129.84) by BN6PR11MB1316.namprd11.prod.outlook.com (10.173.26.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Tue, 10 Dec 2019 15:40:30 +0000 Received: from BN6PR11MB4145.namprd11.prod.outlook.com ([fe80::ce0:6cf9:b567:a5bd]) by BN6PR11MB4145.namprd11.prod.outlook.com ([fe80::ce0:6cf9:b567:a5bd%4]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 15:40:30 +0000 From: "Kinsella, Ray" To: "Richardson, Bruce" , "Yigit, Ferruh" CC: Thomas Monjalon , David Marchand , Luca Boccassi , "Christian Ehrhardt" , Timothy Redaelli , Kevin Traynor , dpdk-dev , "Laatz, Kevin" , Andrew Rybchenko , Neil Horman Thread-Topic: How to manage new APIs added after major ABI release? Thread-Index: AQHVr1DwoytXueOi7EeE1+jaBd80fqezRXCAgAAKDICAACBdgIAAEXQQ Date: Tue, 10 Dec 2019 15:40:30 +0000 Message-ID: References: <5df1a33b-b338-bde1-6834-e8b5fbe65a04@intel.com> <20191210120455.GB103@bricha3-MOBL.ger.corp.intel.com> <36590631-c424-f466-cd37-a759e3fc306c@intel.com> <20191210143643.GA111@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20191210143643.GA111@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTlkZjhmYjUtZjM3Ni00NDgzLWJmNjktZTdiODFiNjYxOGE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUFNTY0M3VlwvTTVNXC9yYW5YNm92a0owQmNnTUpVV3FReTNFc1lKQnhJRk5uYWlcL1R6Y0ZySWdKRUh1T3N1dVF4cSJ9 dlp-version: 11.2.0.6 dlp-product: dlpe-windows x-ctpclassification: CTP_NT dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=ray.kinsella@intel.com; x-originating-ip: [192.198.151.185] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9564cc0-00a3-4240-0561-08d77d8749b8 x-ms-traffictypediagnostic: BN6PR11MB1316: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(366004)(136003)(376002)(13464003)(189003)(199004)(9686003)(81166006)(7696005)(81156014)(26005)(8936002)(478600001)(5660300002)(55016002)(186003)(53546011)(4326008)(66946007)(52536014)(110136005)(33656002)(54906003)(316002)(66556008)(66476007)(966005)(66446008)(64756008)(76116006)(2906002)(6636002)(71200400001)(86362001)(8676002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR11MB1316; H:BN6PR11MB4145.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xSsA41ZOlAbYvnCExFZ25KTgqTGV7b9Gw//sppHK0rLWlS2EwS9VujJZg2NX8S2h1Q3g5CWqTrcWLdvEqp31O4XWQNcM93igzT3QHsDwnq5/aVaLeNi02hqb/qIDTBBrXKYk/pHlxl5gQxi7+JuI/y68jZu+3cdoHbSSiGK8S3g1Khy1c27b2Oy4mTd14sL2lNeknvvOKzhyWMP/p4Gm/vNO731rmmdXBDDRIFqh5ib9P+x6+HZXK6Vy4kfTNRgMfqfQC67O06XR1A9a2wTolX1K3TDbzaExKuCjQ8DgQAN2IeIScsuy49lEWw+ISl0vqkJqYSeN0kADaXatVOStP10Nz205x/BBzKnttt86S8qlcpoFX1XNO2TO2pc9fSeWNsV4DE5CpMkT7H4PAQrXJb6A/gp8wNgjC+1qNqtdvrajuZS3j0JLEcLCdjTGwzQ1laZHKFAUiF1Vb43apzSeBxFTXxeEHwymCWVuyhbOSCfn6ofo5ydNukjkie5uaOzGFpBYb6MjSrpiw17Ugnr2HS1sVHfEH+3/chxRUDQLPCU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9564cc0-00a3-4240-0561-08d77d8749b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 15:40:30.4559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xxg6tuw91wZW77sNMTnhS7N+lLfbMgMYGKgoZXsirVYb76i6fBg6u7M6LIx1dswsQY2KU+CP9VkCpNIv3Q+4aA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1316 X-OriginatorOrg: intel.com X-Mailman-Approved-At: Thu, 12 Dec 2019 10:55:34 +0100 Subject: Re: [dpdk-dev] How to manage new APIs added after major ABI release? 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" > -----Original Message----- > From: Bruce Richardson > Sent: Tuesday 10 December 2019 14:37 > To: Yigit, Ferruh > Cc: Kinsella, Ray ; Thomas Monjalon > ; David Marchand ; Luca > Boccassi ; Christian Ehrhardt > ; Timothy Redaelli > ; Kevin Traynor ; dpdk-dev > ; Laatz, Kevin ; Andrew Rybchenko > ; Neil Horman > Subject: Re: How to manage new APIs added after major ABI release? >=20 > On Tue, Dec 10, 2019 at 12:40:53PM +0000, Ferruh Yigit wrote: > > On 12/10/2019 12:04 PM, Bruce Richardson wrote: > > > On Tue, Dec 10, 2019 at 11:56:28AM +0000, Ferruh Yigit wrote: > > >> Hi, > > >> > > >> With new process, the major ABI releases will be compatible until > > >> it is deprecated (until next LTS for now), like current ABI > version > > >> is 20 in DPDK_19.11 and DPDK versions until DPDK_20.11 will be ABI > > >> compatible with this version. > > >> > > >> But if we introduce a new API after major ABI, say in 20.02 > > >> release, are we allowed to break the ABI for that API before > DPDK_20.11? > > >> > > >> If we allow it break, following problem will be observed: > > >> Assume an application using .so.20.1 library, and using the new > API > > >> introduced in 20.02, lets say foo(), but when application switches > > >> to .so.20.2 (released via DPDK_20.05), application will fail > > >> because of ABI breakage in foo(). > > >> > > >> I think it is fair that application expects forward compatibility > > >> in minor versions of a shared library. > > >> Like if application linked against .so.20.2, fair to expect > > >> .so.20.3, .so.20.4 etc will work fine. I think currently only > .so.20.0 is fully forward compatible. > > >> > > >> If we all agree on this, we may need to tweak the process a > little, > > >> but before diving into implementation details, I would like to be > sure we are in same page. > > >> > > > > > > Well, any new API's generally come in as experimental, in which > case > > > changes are allowed, and breakage can be expected. If they are not > > > experiemental, then the ABI policy applies to them in that they > > > cannot change since they are part of the .21 ABI, even if that ABI > > > is not fully complete yet. For any application only using stable, > > > non-experimental functions, forward compatibility must be > maintained IMHO. > > > > > > > Talking about not experimental APIs, experimental ones free from the > process. > > > > And when and API added in 20.02 (ABI_20.1) it is kind of still > ABI_20, > > because it should be supported for following ABI_20.x, instead of > > calling it ABI_21, and this minor tweak (and mind shift) in .map > files can be our solution. >=20 > Related at what to do with adding versions between major ABI versions, > when investigating with Kevin the ABI checking we have made an > unpleasant > discovery: >=20 > This minor version bumping from 20.0 to 20.1 has apparently already > broken our ABI according to libabigail. >=20 > The Gory Details [skip to the end for suggestions to fix] > ------------------------------------------------------------ >=20 > The reason for this is that the soversion encoded in each library - > whether built with meson or make - is the full 20.0 version, not just > the major ABI > .20 part. Then when apps link against DPDK, they actually encode the > 20.0. >=20 > So what this means is that currently - using a make build as an example > here - ldd on the latest head build gives: >=20 > LD_LIBRARY_PATH=3D$(pwd)/x86_64-native-linux-gcc/lib ldd x86_64-native- > linux-gcc/app/testpmd | head > linux-vdso.so.1 (0x00007fff6813d000) > librte_pmd_bond.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pmd_bond.so.20.1 (0x00007f36d723c000) > librte_pmd_dpaa.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pmd_dpaa.so.20.1 (0x00007f36d7229000) > librte_mempool_dpaa.so.20.1 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc/lib/librte_mempool_dpaa.so.20.1 (0x00007f36d7224000) > librte_pmd_ixgbe.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pmd_ixgbe.so.20.1 (0x00007f36d71ba000) > librte_pmd_i40e.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pmd_i40e.so.20.1 (0x00007f36d7126000) > librte_pmd_bnxt.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pmd_bnxt.so.20.1 (0x00007f36d70e5000) > librte_pmd_softnic.so.20.1 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc/lib/librte_pmd_softnic.so.20.1 (0x00007f36d70b7000) > librte_flow_classify.so.0.201 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc/lib/librte_flow_classify.so.0.201 (0x00007f36d70b1000) > librte_pipeline.so.20.1 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc/lib/librte_pipeline.so.20.1 (0x00007f36d7088000) ... >=20 > Similarly ldd on a 19.11 checkout gives: >=20 > LD_LIBRARY_PATH=3D$(pwd)/x86_64-native-linux-gcc_v19.11/lib ldd x86_64- > native-linux-gcc_v19.11/app/testpmd | head > linux-vdso.so.1 (0x00007ffc2a964000) > librte_pmd_bond.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pmd_bond.so.20.0 (0x00007fd4dc6b6000) > librte_pmd_dpaa.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pmd_dpaa.so.20.0 (0x00007fd4dc6a3000) > librte_mempool_dpaa.so.20.0 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc_v19.11/lib/librte_mempool_dpaa.so.20.0 > (0x00007fd4dc69e000) > librte_pmd_ixgbe.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pmd_ixgbe.so.20.0 (0x00007fd4dc634000) > librte_pmd_i40e.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pmd_i40e.so.20.0 (0x00007fd4dc5a0000) > librte_pmd_bnxt.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pmd_bnxt.so.20.0 (0x00007fd4dc55d000) > librte_pmd_softnic.so.20.0 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc_v19.11/lib/librte_pmd_softnic.so.20.0 > (0x00007fd4dc531000) > librte_flow_classify.so.0.200 =3D> /home/bruce/dpdk.org/x86_64- > native-linux-gcc_v19.11/lib/librte_flow_classify.so.0.200 > (0x00007fd4dc52b000) > librte_pipeline.so.20.0 =3D> /home/bruce/dpdk.org/x86_64-native- > linux-gcc_v19.11/lib/librte_pipeline.so.20.0 (0x00007fd4dc502000) >=20 > The final check - using the 19.11 compiled testpmd with the library > path set to 20.02 versionned libs: >=20 > LD_LIBRARY_PATH=3D$(pwd)/x86_64-native-linux-gcc/lib ldd x86_64-native- > linux-gcc_v19.11/app/testpmd | head > linux-vdso.so.1 (0x00007ffc711fc000) > librte_pmd_bond.so.20.0 =3D> not found > librte_pmd_dpaa.so.20.0 =3D> not found > librte_mempool_dpaa.so.20.0 =3D> not found > librte_pmd_ixgbe.so.20.0 =3D> not found > librte_pmd_i40e.so.20.0 =3D> not found > librte_pmd_bnxt.so.20.0 =3D> not found > librte_pmd_softnic.so.20.0 =3D> not found > librte_flow_classify.so.0.200 =3D> not found > librte_pipeline.so.20.0 =3D> not found >=20 > Fixing This > ----------- >=20 > To fix this, we need to ensure that the SONAME remains constant across > the releases. Therefore, I currently see two options: >=20 > 1. keep 20.0 as the version and soname across all releases in 2020, > i.e. > just revert the ABIVERSION change patch. Trouble there is how to > track > 20.02 vs 20.05 etc. etc. >=20 > 2. remove the .0, .1 from the SONAMES stored in the libraries. This has > the > advantage of keeping the existing planned schemes, but has the really > big > downside of breaking ABI compatibility with anyone who has already > compiled with 19.11. >=20 > Personally, of the two options - unless someone can come up with a > third option - I'd tend towards the second, fixing the builds to remove > the .0 in the soname, and releasing that ASAP as 19.11.1 before 19.11 > gets widespread adoption. Since this ABI stability is new, teething > problems may be expected. >=20 > Thoughts and comments? > /Bruce >=20 > BTW: For meson, the patch for option 2 is just to remove the so_version > variable and all references to it from lib/meson.build and > drivers/meson.build. Haven't looked into a "make" fix yet. >From the DPDK ABI Version Document ... A library's soname. is typically used to provide backward compatibility inf= ormation about a given library, describing the lowest common denominator AB= I supported by the library. The soname or logical name for the library, is = typically comprised of the library's name and major version e.g. librte_eal= .so.20 https://doc.dpdk.org/guides/contributing/abi_versioning.html