[dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id

[Neil Horman]

On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote:
> On Sat, Jan 31, 2015 at 3:19 PM, Neil Horman <nhorman at tuxdriver.com> wrote:
> 
> > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote:
> > > From: Jeff Shaw <jeffrey.b.shaw at intel.com>
> > >
> > > Add fm10k device ID list into rte_pci_dev_ids.h.
> > >
> > > Signed-off-by: Jeff Shaw <jeffrey.b.shaw at intel.com>
> > > Signed-off-by: Chen Jing D(Mark) <jing.d.chen at intel.com>
> > > ---
> > >  lib/librte_eal/common/include/rte_pci_dev_ids.h |   22
> > ++++++++++++++++++++++
> > >  1 files changed, 22 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > index c922de9..f54800e 100644
> > > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > @@ -132,6 +132,14 @@
> > >  #define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
> > >  #endif
> > >
> > > +#ifndef RTE_PCI_DEV_ID_DECL_FM10K
> > > +#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
> > > +#endif
> > > +
> > > +#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
> > > +#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
> > > +#endif
> > > +
> > I know this isn't the job of this patch series, but I don't really
> > understand
> > why we bother with this pattern for filling out pci id tables.  A PMD
> > supports
> > specific hardware, we might as well use the generic RTE_PCI_DEVICE macro
> > in the
> > driver rather than creating a FM10K specific wrapper, only to have to do
> > some
> > ifdef trickery in the rte_cpi_dev_ids file and some include magic to fill
> > it
> > out.
> >
> 
> +1
> 
> 
> > I'd suggest that you just use RTE_PCI_DEVICE macro here, and make your own
> > table
> > (keep the specific device id values in the common file.  Then we can clean
> > out
> > the macro maggic in a later update.
> >
> 
> If we are going that way, my only concern is that this makes it hard to
> "discover" the pci devices that need to be bound to igb_uio/vfio/whatever
> kernel driver, and so we must rely either on a global list (like this
> rte_pci_dev_ids.h) or on scripts with hardcoded pci device ids in them ...
> 
> In the end, we miss something to have dpdk work automatically like it used
> to be, before the pci devices ids were stripped out of igb_uio.
> 
> I can see two solutions :
> - all pmds export the pci device ids they support (this sounds like
> modalias :-)) or they register into the eal that exports this information
> for use by application, but to me the application should not bother with
> this ...
> - the pmd handles this automatically (like binding/unbinding on a kernel
> driver), with a _runtime_ option to enable this behavior (default being "no
> automatic bind")
> 
> Comments ? Ideas ?
> 
I like the modalias idea, as it transports a table for uio/vfio to identify with
the binary that needs it, preventing a possible discrepancy in what the core
dpdk library identifies as supported devices and what the pmd DSO's actually do
support.

To implement it we would either provide our own linker script or have to do some
other make trickery.  The linker script is a bit more labor intensive, but might
provide some future benefit (if you see a need for non-standard sections that
you would like to suck into a given DSO in the future).  Make trickery would be
more straightforward, but requires that we add some additional make targets to
build out the dynamic table to be readable by outside utilities.  Maybe we could
use objcopy to add in a separate section after the dso link.  Not sure yet
Neil

> -- 
> David Marchand