[dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine

[Ferruh Yigit]

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 at 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