From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 683B24A63
 for <dev@dpdk.org>; Tue,  3 Nov 2015 12:02:38 +0100 (CET)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga102.jf.intel.com with ESMTP; 03 Nov 2015 03:02:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208";a="810538066"
Received: from irvmail001.ir.intel.com ([163.33.26.43])
 by orsmga001.jf.intel.com with ESMTP; 03 Nov 2015 03:02:29 -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
 tA3B2SGO030521; Tue, 3 Nov 2015 11:02:28 GMT
Received: from sivlogin002.ir.intel.com (localhost [127.0.0.1])
 by sivlogin002.ir.intel.com with ESMTP id tA3B2Sue007588;
 Tue, 3 Nov 2015 11:02:28 GMT
Received: (from fyigit@localhost)
	by sivlogin002.ir.intel.com with œ id tA3B2RtF007584;
	Tue, 3 Nov 2015 11:02:27 GMT
X-Authentication-Warning: sivlogin002.ir.intel.com: fyigit set sender to
 ferruh.yigit@intel.com using -f
Date: Tue, 3 Nov 2015 11:02:27 +0000
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Panu Matilainen <pmatilai@redhat.com>
Message-ID: <20151103110227.GA5998@sivlogin002.ir.intel.com>
Mail-Followup-To: Panu Matilainen <pmatilai@redhat.com>,
 Eric Kinzie <ehkinzie@gmail.com>, dev@dpdk.org,
 Eric Kinzie <ekinzie@brocade.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <563858B0.9010404@redhat.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: dev@dpdk.org, Eric Kinzie <ekinzie@brocade.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 11:02:39 -0000

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.


> 	- Panu -
>