[dpdk-dev] time to kill rte_pci_dev_ids.h

David Marchand david.marchand at 6wind.com
Fri Jan 8 14:20:50 CET 2016


On Wed, Jan 6, 2016 at 2:40 AM, Thomas Monjalon <thomas.monjalon at 6wind.com>

> 2016-01-05 11:37, Stephen Hemminger:
> > Has anyone looked at getting rid of rte_pci_dev_ids.h?
> > The current method with #ifdef's and putting all devices in one file
> > really doesn't scale well. Something more like other OS's where
> > the data is only in each device driver would be better.
> I agree.
> The PCI ids should be embedded in drivers.
> If I remember well, it's already the case for some of them.
> I would love to see a tool able to list the supported devices
> by reading a binary libraries.

I have done the first part of the job, moving all pci dev ids to the pmds,
just rebased it.
I can post this.

In the last patch of the series, I put all those ids in a dedicated
section, that can be dumped with objdump.
Having a tool for this (like what I proposed some time ago) would be great
but I did not find time to write it.

The thing is, what do we want to achieve with such a tool ?

My usecase at the moment is for "automatic" device binding to kernel
drivers before starting dpdk or when hotplugging.
But for this, I think that introducing a hook system in the pci probe
functions is better.
I am thinking of a hook system that would execute an external tool (shell
scripts, C, ...) with all needed informations: pci device, pmd that wants
it, driver flags etc...
Return value would tell eal what to do next.
This would make it possible to implement the blacklist / whitelist out of
eal itself, implement auto bind and maybe more.

If I go this way, I don't think that we need to expose the pci dev ids :-)

David Marchand

More information about the dev mailing list