From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 7E6B38E86 for ; Tue, 3 Nov 2015 12:49:00 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2015 03:48:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208";a="593138899" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2015 03:48:58 -0800 Received: from sivlogin002.ir.intel.com (sivlogin002.ir.intel.com [10.237.217.37]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id tA3BmvQV016815; Tue, 3 Nov 2015 11:48:57 GMT Received: from sivlogin002.ir.intel.com (localhost [127.0.0.1]) by sivlogin002.ir.intel.com with ESMTP id tA3BmvLl017738; Tue, 3 Nov 2015 11:48:57 GMT Received: (from fyigit@localhost) by sivlogin002.ir.intel.com with œ id tA3BmvB6017734; Tue, 3 Nov 2015 11:48:57 GMT X-Authentication-Warning: sivlogin002.ir.intel.com: fyigit set sender to ferruh.yigit@intel.com using -f Date: Tue, 3 Nov 2015 11:48:57 +0000 From: Ferruh Yigit To: Panu Matilainen Message-ID: <20151103114857.GA16804@sivlogin002.ir.intel.com> Mail-Followup-To: Panu Matilainen , Eric Kinzie , dev@dpdk.org, Eric Kinzie References: <1445268976-27491-1-git-send-email-ehkinzie@gmail.com> <1445268976-27491-4-git-send-email-ehkinzie@gmail.com> <1706989.WgznurFLZ8@xps13> <563739B3.1040809@redhat.com> <20151102164206.GA14543@roosta.home> <563858B0.9010404@redhat.com> <20151103110227.GA5998@sivlogin002.ir.intel.com> <56389B21.1080800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56389B21.1080800@redhat.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: dev@dpdk.org, Eric Kinzie Subject: Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 11:49:01 -0000 On Tue, Nov 03, 2015 at 01:31:45PM +0200, Panu Matilainen wrote: > On 11/03/2015 01:02 PM, Ferruh Yigit wrote: >> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote: >>> On 11/02/2015 06:42 PM, Eric Kinzie wrote: >>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote: >>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote: >>>>>> 2015-10-19 08:36, Eric Kinzie: >>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER >>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get >>>>>>> functions. >>>>>> [...] >>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0); >>>>>> [...] >>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2); >>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \ >>>>>>> + bond_mode_8023ad_setup_v22); >>>>>> >>>>>> I'm sorry it doesn't work well when trying to build a combined lib: >>>>>> >>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2 >>>>>> >>>>>> The symbols are OK in the .o file: >>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2 >>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0 >>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20 >>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22 >>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup >>>>>> >>>>>> I don't understand the problem and I am considering disabling versioning in >>>>>> combined library. >>>>>> >>>>>> Any idea? >>>>>> >>>>> >>>>> The .map additions look incorrect to me: >>>>> >>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map >>>>>> index 22bd920..7f78717 100644 >>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map >>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map >>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 { >>>>>> rte_eth_bond_slaves_get; >>>>>> rte_eth_bond_xmit_policy_get; >>>>>> rte_eth_bond_xmit_policy_set; >>>>>> + rte_eth_bond_8023ad_ext_collect; >>>>>> + rte_eth_bond_8023ad_ext_distrib; >>>>>> + rte_eth_bond_8023ad_ext_slowtx; >>>>> >>>>> These symbols didn't exist in DPDK 2.0 but are only being added >>>>> here. So why are they being added to the 2.0 section? >>>> >>>> Yes, I think these should probably be moved. >>>> >>>> >>>>>> >>>>>> local: *; >>>>>> }; >>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 { >>>>>> rte_eth_bond_free; >>>>>> >>>>>> } DPDK_2.0; >>>>>> + >>>>>> +DPDK_2.2 { >>>>>> + local >>>>>> + >>>>>> + bond_mode_8023ad_conf_get; >>>>>> + bond_mode_8023ad_setup; >>>>>> +} DPDK_2.1; >>>>> >>>>> These are marked local, as in, "not exported" which doesn't seem >>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what >>>>> the symbol export map should look like here: >>>> >>>> >>>> These were not exported to begin with. But after versioning these >>>> functions, they are exported unless explicitly declared to be local here. >>>> >>> >>> And this does not ring any warning bells? :) >>> >>> Sorry, I was not looking at the patch as a whole. You're declaring these >>> symbols as exported with the versioning macros, eg >>> >>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2); >>> >>> ...and then explicitly telling it to not export them by declaring local, and >>> then we wonder why it has trouble finding the symbols. >>> The versioning macros wont invent the librte_ prefix for you, you need to >>> rename the functions accordingly. >>> >>> But all this versioning gymnastics is moot anyway because you declare the >>> ABI incompatible: >>> >>> -LIBABIVER := 1 >>> +LIBABIVER := 2 >>> >>> This changes the library soname, so no binary compiled against the previous >>> version can possibly use it anymore. As in, by definition there can be no >>> callers of the _v20 variants after this ABI version bump. >>> >> An observation: even soname is different, just renaming .so file itself works. >> >> And this can be useful for the case: >> libx.so.1 provides functions A, B, C >> app1 compiled against libx.so.1, using only function B >> >> libx.so.1 updated only thefunction A and become libx.so.2 >> app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2) >> >> But for this usage, user needs to know which function updated and is it safe or not to use this library, >> I wonder if there is an automatic way of resolving this dependency. > > Erm, no. The whole point of changing soname and the physical filename is to > tell others it is incompatible with earlier versions. Yes you can rename the > file and get lucky (or not), just like you can play Russian roulette. > Neither are particularly healthy ideas. > > Symbol version exists in part to allow libraries to evolve while maintaining > compatibility, but it requires careful planning and programming. When public > structs change, the structs would have to be versioned too, and from there > on it starts getting more and more complicated. > If we strictly want to prevent using old library, whenever LIBABIVER increased, we should update .map as following, right? FROM: (dpdk2.1) ================ DPDK_2.0 { A; B; C; }; DPDK_2.1 { D; E; }; LIBABIVER=1 ================ TO: (dpdk2.2) ================ DPDK_2.2 { A; B; C; D; E; }; LIBABIVER=2 ================ So this won't work for anybody without luck factor, I think currently we are not doing this. thanks, ferruh