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

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 23 Jul 2019 13:30:33 +0100
Bruce Richardson <bruce.richardson@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 <thomas@monjalon.net> wrote:
> >   
> > > 22/07/2019 19:13, Stephen Hemminger:  
> > > > Thomas Monjalon <thomas@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.