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