Hi Neil, > -----Original Message----- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Saturday, January 31, 2015 10:20 PM > To: Chen, Jing D > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id > > 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. > > 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.
I partially agree with you. Maybe a better solution is to use the mechanism that applied in kernel to register PCI driver. Driver maintains a device list that it can manage and provide a hook function to detect if new device can be managed by the driver. Then, DPDK core library needn't worry about the long device list (Maybe script that unbind/bind device needs such info, it's another story). But I'd like to keep current implementation unchanged since final decision is not made yet. If new mechanism is introduced, I would like to update to adapt to the new changes. > Neil Best Regards, Mark
