On Tue, 23 Jul 2019 13:30:33 +0100 Bruce Richardson <bruce.richard...@intel.com> wrote:
> On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote: > > On Mon, 22 Jul 2019 19:31:08 +0200 > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > 22/07/2019 19:13, Stephen Hemminger: > > > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > Are the constructors run on dlopen of the bus driver? > > > > > > > > Yes, constructors are run on dlopen. > > > > But application should not have to ask DPDK to dlopen the bus devices. > > > > > > > > The core principle is that dynamic build of DPDK should act the same as > > > > old > > > > statically linked DPDK. Otherwise, the user experience is even worse, > > > > and all > > > > the example documentation is wrong. > > > > > > OK, this is where I wanted to bring the discussion. > > > You are arguing against a design which is in DPDK from some early days. > > > So this is an interesting discussion to have. > > > Do we want to change the "plugin model" we have? > > > Or do we want to simply drop this model (dlopen calls) > > > and replace it with strong dynamic linking? > > > > > > > > > > What I think should happen (and isn't is): > > > > 1. The PCI bus library is linked with --whole-archive, and --no-as-needed. > > This causes constructor to be called and register the bus. > > > > This should be applied to the whole of the bus drivers, not just the PCI > bus. > > > 2. As part of the build process all the PCI drivers pmdinfo would get > > constructed into a table of vendor/device to PMD shared library name. > > > > 3. PMD's are linked as --whole-archive, and --as-needed. > > > > I'm not sure I agree with this change to always link in all the PMDs. It > prevents an app from being used with just a subset of the drivers needed. > > > 4. New code in PCI probe which looks for existing entries (static or -d) > > for devices. If device is still not found it refers to the table of PMD's > > (from #2) and calls dlopen for that device (and adds it to static table). > > > > This would allow examples and customer applications to Just Work without > > having to know the PMD that is present. It would also solve the problem > > that currently if applications is linked with -ldpdk linker script then > > all PMD's get pulled into the application address space. > > > > In all this you seem to be assuming that the drivers are not picked up at > runtime from the RTE_EAL_PMD_PATH. In real world cases where a user is > building an app, and not developing DPDK itself, the DPDK libraries should > be installed in /usr(/local)/lib64 and the drivers in > .../lib64/dpdk/dpdk-19.08. In that case, the bus drivers and the PMD > drivers are all loaded at runtime for each app, without having any > dependency on having a specific one be present, allowing a user to remove > any drivers unnecessary for the current hardware. Looking at the plugin loading, the problem is it loads every PMD not just those that are going to be used. Isn't this a problem with a distribution model on an embedded system? Not everyone has virtual memory space to burn.