Re: [dpdk-dev] [dpdk-users] DPDK 16.04 link changes cause PMD drivers to not be loaded

[Panu Matilainen <pmatilai@redhat.com>]

On 04/21/2016 06:24 PM, Aurojit Panda wrote:
>
>
> Thomas Monjalon wrote:
>> 2016-04-21 08:01, Aurojit Panda:
>>> Panu Matilainen wrote:
>> [...]
>>>> Again, PMDs are *plugins* that are *meant* to be loaded at runtime.
>>>> That allows for all sorts of flexibility especially
>>>> for packaging and shipping, at some extra cost in setup complexity.
>>> I am all for a plugin architecture, I was merely suggesting that you
>>> embed some path infromation at the beginning. Also please note:
>>> (a) This behavior changed recently.
>>
>> What changed recently?
>>
> Change 948fd64befc3726 moved DPDK from building a shared library to
> using LD linker scripts.
>
>>> (b) This change is entirely undocumented, which is why I was reporting
>>> it in the first place.
>>> (c) It is actually quite unintutive, because previously ensuring
>>> LD_LIBRARY_PATH was correct was all that was required
>>> to get any DPDK application to interact with ports.
>>
>> ?
>> Are you talking about combined library?
> Yes, if you build a shared combined library, PMD drivers are not
> automatically loaded anymore. This implies that programs do not
> enumerate the set of ports on the machine. (Unless CONFIG_EAL_PMD_PATH
> is correctly set to the absolute directory where the built DPDK will live).
>>
>>>> For your own purposes, you can of course tweak the linking settings
>>>> as much as you like. Look for "plugins" in mk/rte.app.mk and change
>>>> the shared lib condition on the line above to "y" and there you have
>>>> it.
>>>> But that's not the way plugins are meant to be used.
>>> That is not a reasonable solution given that it makes it very hard to
>>> track future changes to DPDK without merges.
>>> My alternatives neither break people's abilities to use plugins,
>>> nor do they impact behavior.
>>
>> Please do not hesitate to send some patch to show your solution.
>
> My initial e-mail was sent because I don't entirely understand LD linker
> scripts (the PMD libraries are listed within the built libdpdk.so file),
> so the only patch I can suggest is undoing 948fd64befc3726 in which case
> the behavior as I describe.

Reverting would be counter-productive, the change was introduced for a 
reason. Many of them in fact.

Any application wanting to force linkage to plugins always needed to 
link them inside --whole-archive section with static or individual 
shared libraries, now that is true for the combined shared library as well.

Within DPDK itself it would be easy enough to add an option to force 
link-in of the plugins (see the comment about mk/rte.app.mk change), but 
not sure we want to have yet another build option. And anything else 
still would need to use --whole-archive if they want that behavior.

So yes it's a behavior change for that particular corner which nobody 
thought of or brought up during review, and so ended up being 
undocumented too.

Like said there are always ways to improve things, once the use-case is 
understood, actual examples of how you are deploying DPDK would perhaps 
help. One possibility could be attempting to load known plugins from 
LD_LIBRARY_PATH, but that requires inserting that information somewhere 
in the binaries where it currently is not needed.

	- Panu -