[dpdk-dev] time to kill rte_pci_dev_ids.h
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 :-)
More information about the dev