[dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build

[Bruce Richardson]

On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote:
> On Mon, 22 Jul 2019 19:31:08 +0200
> Thomas Monjalon <thomas at monjalon.net> wrote:
> 
> > 22/07/2019 19:13, Stephen Hemminger:
> > > Thomas Monjalon <thomas at 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.

Did you try installing DPDK using "ninja install" or "make install" before
running any apps using it?

/Bruce