From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by dpdk.org (Postfix) with ESMTP id BCF318DA8 for ; Fri, 20 Nov 2015 20:46:11 +0100 (CET) Received: by ykdv3 with SMTP id v3so176854384ykd.0 for ; Fri, 20 Nov 2015 11:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Wa1XtDptItYUYYPTPSYkyTp+EBpJxWFubH9IR5f49u8=; b=ncpgOSbl6rbKu50GpW4gnzKOrSY+Qw+6YJJIEdixJti6Lnno5LNQkrwCVwr9kR9R85 Nc2+qoIyON2VTip9DLkyj555Cd/FtJlSF/SXtnY0n7E6BEEZKODgPOjA0CInVP7j+gy2 ooed8o2hrSPwpETxAZG8gQbYOaY3HdqHAzvPt3IipvgHAgS7y0MIR107KM266/f/rmSi rbp368UtwDve1XtrMwxgs01wIC/UZU84RXhSjkpRaydmOikgRZNQMUPmMHAU9qaXAJZb qeOrG5npZ8SyKG7IJEhxEIXloou833Du7bnrRYCWdBtyzS8ZqZfa4MF2EUV2DU3p7x8b qBZQ== X-Received: by 10.129.154.148 with SMTP id r142mr16072076ywg.291.1448048771261; Fri, 20 Nov 2015 11:46:11 -0800 (PST) Received: from gmail.com (pool-108-31-208-15.washdc.fios.verizon.net. [108.31.208.15]) by smtp.gmail.com with ESMTPSA id b126sm970008ywd.3.2015.11.20.11.46.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 20 Nov 2015 11:46:11 -0800 (PST) Received: by gmail.com (sSMTP sendmail emulation); Fri, 20 Nov 2015 14:46:09 -0500 Date: Fri, 20 Nov 2015 14:46:08 -0500 From: Eric Kinzie To: ferruh.yigit@intel.com, Panu Matilainen , dev@dpdk.org, Eric Kinzie Message-ID: <20151120194603.GA13894@roosta.home> 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> <20151103114857.GA16804@sivlogin002.ir.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151103114857.GA16804@sivlogin002.ir.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 20 Nov 2015 19:46:12 -0000 On Tue Nov 03 11:48:57 +0000 2015, Ferruh Yigit wrote: > 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 > > Panu, Ferruh, is there agreement on an acceptable approach to this? Eric