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 82E86A04F0; Tue, 10 Dec 2019 16:04:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 547851B994; Tue, 10 Dec 2019 16:04:36 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0AF8A1F5 for ; Tue, 10 Dec 2019 16:04:34 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2019 07:04:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,300,1571727600"; d="scan'208";a="244873604" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.96]) ([10.237.221.96]) by fmsmga002.fm.intel.com with ESMTP; 10 Dec 2019 07:04:31 -0800 To: Bruce Richardson Cc: "Kinsella, Ray" , Thomas Monjalon , David Marchand , Luca Boccassi , Christian Ehrhardt , Timothy Redaelli , Kevin Traynor , dpdk-dev , "Laatz, Kevin" , Andrew Rybchenko , Neil Horman 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> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: Date: Tue, 10 Dec 2019 15:04:30 +0000 MIME-Version: 1.0 In-Reply-To: <20191210143643.GA111@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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" On 12/10/2019 2:36 PM, Bruce Richardson wrote: > 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. > > 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: > > This minor version bumping from 20.0 to 20.1 has apparently already broken > our ABI according to libabigail. > > The Gory Details [skip to the end for suggestions to fix] > ------------------------------------------------------------ > > 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. > > So what this means is that currently - using a make build as an example > here - ldd on the latest head build gives: > > LD_LIBRARY_PATH=$(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 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_bond.so.20.1 (0x00007f36d723c000) > librte_pmd_dpaa.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_dpaa.so.20.1 (0x00007f36d7229000) > librte_mempool_dpaa.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_mempool_dpaa.so.20.1 (0x00007f36d7224000) > librte_pmd_ixgbe.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_ixgbe.so.20.1 (0x00007f36d71ba000) > librte_pmd_i40e.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_i40e.so.20.1 (0x00007f36d7126000) > librte_pmd_bnxt.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_bnxt.so.20.1 (0x00007f36d70e5000) > librte_pmd_softnic.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pmd_softnic.so.20.1 (0x00007f36d70b7000) > librte_flow_classify.so.0.201 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_flow_classify.so.0.201 (0x00007f36d70b1000) > librte_pipeline.so.20.1 => /home/bruce/dpdk.org/x86_64-native-linux-gcc/lib/librte_pipeline.so.20.1 (0x00007f36d7088000) > ... > > Similarly ldd on a 19.11 checkout gives: > > LD_LIBRARY_PATH=$(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 => /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 => /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 => /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 => /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 => /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 => /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 => /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 => /home/bruce/dpdk.org/x86_64-native-linux-gcc_v19.11/lib/librte_flow_classify.so.0.200 (0x00007fd4dc52b000) > librte_pipeline.so.20.0 => /home/bruce/dpdk.org/x86_64-native-linux-gcc_v19.11/lib/librte_pipeline.so.20.0 (0x00007fd4dc502000) > > The final check - using the 19.11 compiled testpmd with the library path > set to 20.02 versionned libs: > > LD_LIBRARY_PATH=$(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 => not found > librte_pmd_dpaa.so.20.0 => not found > librte_mempool_dpaa.so.20.0 => not found > librte_pmd_ixgbe.so.20.0 => not found > librte_pmd_i40e.so.20.0 => not found > librte_pmd_bnxt.so.20.0 => not found > librte_pmd_softnic.so.20.0 => not found > librte_flow_classify.so.0.200 => not found > librte_pipeline.so.20.0 => not found > > Fixing This > ----------- > > To fix this, we need to ensure that the SONAME remains constant across the > releases. Therefore, I currently see two options: > > 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. > > 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. > > 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. > > Thoughts and comments? Arghh :( I agree that 2) is proper fix and if we want to fix properly we should do a 19.11.1 ASAP. Can having soname as "20.0" but having file name as .so.20.1 work? If it does we can "workaround" it by keeping SONAME as "20.0" (instead of 20) during the life time of the ABI_20 and fix it properly in ABI_21.