[dpdk-dev] [PATCH v2 10/10] pci: place all uio pci device ids in a dedicated section

[Neil Horman]

On Wed, Feb 24, 2016 at 12:50:40PM +0100, Thomas Monjalon wrote:
> 2016-02-24 11:37, Bruce Richardson:
> > On Wed, Jan 20, 2016 at 10:40:00AM -0500, Neil Horman wrote:
> > > On Tue, Jan 19, 2016 at 01:35:14PM -0800, Stephen Hemminger wrote:
> > > > On Tue, 19 Jan 2016 15:56:14 -0500
> > > > Neil Horman <nhorman at tuxdriver.com> wrote:
> > > > 
> > > > > On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote:
> > > > > > On Tue, 19 Jan 2016 09:29:31 -0500
> > > > > > Neil Horman <nhorman at redhat.com> wrote:
> > > > > > 
> > > > > > > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote:
> > > > > > > > 2016-01-18 13:30, David Marchand:
> > > > > > > > > We could do something à la modinfo, but let's keep it simple for now.
> > > > > > > > > 
> > > > > > > > > With this, you can extract the devices that need to be bound to uio / vfio
> > > > > > > > > with tools like objdump :
> > > > > > > > > 
> > > > > > > > > $ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm10k.so
> > > > > > > > > 
> > > > > > > > > Contents of section rte_pci_id_uio:
> > > > > > > > >  15760 8680a415 ffffffff 8680d015 ffffffff  ................
> > > > > > > > >  15770 8680a515 ffffffff 00000000 00000000  ................
> > > > > > > > 
> > > > > > > > Yes we need a modinfo-like tool.
> > > > > > > > Currently, the UIO/VFIO binding can be done after parsing the PCI device list.
> > > > > > > > It is better to define the device ids locally to their drivers but it must
> > > > > > > > be integrated with an appropriate parsing tool at the same time.
> > > > > > > > And more importantly than any tool, the format of these ELF data must be
> > > > > > > > properly defined, documented and extensible.
> > > > > > > > 
> > > > > > > > Is there someone experimented with such format definition?
> > > > > > > > Stephen, you were asking for this change, what is your opinion?
> > > > > > > > I remember that Neil was also interested in this change:
> > > > > > > > 	http://dpdk.org/ml/archives/dev/2015-January/012115.html
> > > > > > > > Panu, Christian, this change could be related to distribution packaging.
> > > > > > > > Thanks for helping to move this change forward.
> > > > > > > 
> > > > > > > Yes, I would be interested in seeing this.  Is the ask here that someone do it?
> > > > > > > As I recall from the last thread that you reference, I thought David M was
> > > > > > > interested in writing it and soliciting for ideas.  If thats no longer the case,
> > > > > > > I can take a stab at writing it.
> > > > > > > 
> > > > > > > Neil
> > > > > > > 
> > > > > > 
> > > > > > If these are libraries is there a way to have a real entry point
> > > > > > to dump PCI id's. 
> > > > > > 
> > > > > Sure, you could write a method that could be dlsym-ed easily enough to fetch an
> > > > > array of pci ids, or just print stuff the console.  Not sure thats the best way,
> > > > > but definately an option
> > > > > Neil
> > > > 
> > > > It is just that reading data with objdump is a kludge likely to get broken.
> > > > 
> > > Not suggesting that we rely on objdump in perpituity, only that we export the
> > > data, rather than a method to access it so that it can be reached via libelf.
> > > Using a function to return the information has implicit issues at the moment
> > > (specifically if you dlopen a dpdk driver, its constructor will attempt to
> > > register it with the core libraries).  While thats not catastrophic, it means
> > > more stuff than you expect gets loaded, which might have wierd side effects.
> > > Adding a separate section that you could reach via libelf would be nice I think
> > > 
> > > Neil
> > > 
> > Hi,
> > 
> > while there is interesting discussion on tools, are there any objections to
> > taking and merging this patchset as-is to at least do the cleanup of the
> > existing pci ids list? I would assume that any tools for querying the patchlist
> > can be done as additional work once this is applied. 
> 
> Today we can parse the global PCI list to bind devices to DPDK.
> If we remove this list, we must replace it by another convenient method.
> And more importantly, the informations in the ELF files must be extendible
> and in a stable syntax.
> The problem here is that it is poorly specified.
> Please let's describe a syntax for these ELF data, first.

Agreed, I'd be fine with taking the patch if it didn't preclude admins from
being able to identify which drivers match which devices without loading the
modules first.
Neil