[dpdk-dev,v2,10/10] pci: place all uio pci device ids in a dedicated section
Commit Message
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 ................
Signed-off-by: David Marchand <david.marchand@6wind.com>
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++--
drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 4 ++--
drivers/net/enic/enic_ethdev.c | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
drivers/net/nfp/nfp_net.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
lib/librte_eal/common/include/rte_pci.h | 2 ++
14 files changed, 18 insertions(+), 16 deletions(-)
Comments
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.
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
On Tue, 19 Jan 2016 09:29:31 -0500
Neil Horman <nhorman@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.
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@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
On Tue, 19 Jan 2016 15:56:14 -0500
Neil Horman <nhorman@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@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.
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@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@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
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@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@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.
Regards,
/Bruce
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@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@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.
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@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@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
@@ -67,7 +67,7 @@ static struct rte_cryptodev_ops crypto_qat_ops = {
* The set of PCI devices this driver supports
*/
-static struct rte_pci_id pci_id_qat_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_qat_map[] = {
{
.vendor_id = 0x8086,
.device_id = 0x0443,
@@ -17,7 +17,7 @@
* The set of PCI devices this driver supports
*/
#define PCI_VENDOR_ID_BROADCOM 0x14E4
-static struct rte_pci_id pci_id_bnx2x_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_bnx2x_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
@@ -33,7 +33,7 @@ static struct rte_pci_id pci_id_bnx2x_map[] = {
{ .vendor_id = 0, }
};
-static struct rte_pci_id pci_id_bnx2xvf_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_bnx2xvf_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
@@ -68,7 +68,7 @@
* Macros needed to support the PCI Device ID Table ...
*/
#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
- static struct rte_pci_id cxgb4_pci_tbl[] = {
+ static struct rte_pci_id RTE_PCI_ID_UIO_SECTION cxgb4_pci_tbl[] = {
#define CH_PCI_DEVICE_ID_FUNCTION 0x4
#define PCI_VENDOR_ID_CHELSIO 0x1425
@@ -136,7 +136,7 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
/*
* The set of PCI devices this driver supports
*/
-static const struct rte_pci_id pci_id_em_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_em_map[] = {
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "em_pci_dev_ids.h"
@@ -273,7 +273,7 @@ static enum e1000_fc_mode igb_fc_setting = e1000_fc_full;
/*
* The set of PCI devices this driver supports
*/
-static const struct rte_pci_id pci_id_igb_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_igb_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "igb_pci_dev_ids.h"
@@ -284,7 +284,7 @@ static const struct rte_pci_id pci_id_igb_map[] = {
/*
* The set of PCI devices this driver supports (for 82576&I350 VF)
*/
-static const struct rte_pci_id pci_id_igbvf_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_igbvf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGBVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "igb_pci_dev_ids.h"
@@ -58,7 +58,7 @@
* The set of PCI devices this driver supports
*/
#define PCI_VENDOR_ID_CISCO 0x1137
-static const struct rte_pci_id pci_id_enic_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_enic_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF) },
{.vendor_id = 0, /* sentinel */},
@@ -2740,7 +2740,7 @@ eth_fm10k_dev_uninit(struct rte_eth_dev *dev)
* The set of PCI devices this driver supports. This driver will enable both PF
* and SRIOV-VF devices.
*/
-static const struct rte_pci_id pci_id_fm10k_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_fm10k_map[] = {
{ RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_PF) },
{ RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_SDI_FM10420_QDA2) },
{ RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_VF) },
@@ -415,7 +415,7 @@ static int i40e_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,
uint16_t queue_id);
-static const struct rte_pci_id pci_id_i40e_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_i40e_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_A) },
@@ -1116,7 +1116,7 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct rte_eth_link *link)
return 0;
}
-static const struct rte_pci_id pci_id_i40evf_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_i40evf_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
@@ -378,7 +378,7 @@ static int ixgbe_timesync_write_time(struct rte_eth_dev *dev,
/*
* The set of PCI devices this driver supports
*/
-static const struct rte_pci_id pci_id_ixgbe_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_ixgbe_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "ixgbe_pci_dev_ids.h"
@@ -390,7 +390,7 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
/*
* The set of PCI devices this driver supports (for 82599 VF)
*/
-static const struct rte_pci_id pci_id_ixgbevf_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_ixgbevf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "ixgbe_pci_dev_ids.h"
@@ -2444,7 +2444,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
return 0;
}
-static struct rte_pci_id pci_id_nfp_net_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_nfp_net_map[] = {
{
.vendor_id = PCI_VENDOR_ID_NETRONOME,
.device_id = PCI_DEVICE_ID_NFP6000_PF_NIC,
@@ -105,7 +105,7 @@ static int virtio_dev_queue_stats_mapping_set(
/*
* The set of PCI devices this driver supports
*/
-static const struct rte_pci_id pci_id_virtio_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_virtio_map[] = {
{ RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
{ .vendor_id = 0, /* sentinel */ },
};
@@ -100,7 +100,7 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
*/
#define PCI_VENDOR_ID_VMWARE 0x15AD
#define VMWARE_DEV_ID_VMXNET3 0x07B0
-static const struct rte_pci_id pci_id_vmxnet3_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_vmxnet3_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3) },
{ .vendor_id = 0, /* sentinel */ },
};
@@ -131,6 +131,8 @@ struct rte_pci_id {
uint16_t subsystem_device_id; /**< Subsystem device ID or PCI_ANY_ID. */
};
+#define RTE_PCI_ID_UIO_SECTION __attribute__((section("rte_pci_id_uio")))
+
/**
* A structure describing the location of a PCI device.
*/