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

[Aurojit Panda]

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.

> Thanks


Thanks

Panda