From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 317F22A61 for ; Mon, 2 Feb 2015 08:56:13 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 01 Feb 2015 23:56:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,505,1418112000"; d="scan'208";a="660188793" Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91]) by fmsmga001.fm.intel.com with ESMTP; 01 Feb 2015 23:56:10 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Feb 2015 15:54:30 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.124]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.253]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 15:54:29 +0800 From: "Chen, Jing D" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id Thread-Index: AQHQPErHBZuIjo5ilUK+qPY3YonOO5zZwy6AgAM8rkA= Date: Mon, 2 Feb 2015 07:54:28 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D0166319B@shsmsx102.ccr.corp.intel.com> References: <1422594454-11045-1-git-send-email-jing.d.chen@intel.com> <1422594454-11045-5-git-send-email-jing.d.chen@intel.com> <20150131141935.GB22012@localhost.localdomain> In-Reply-To: <20150131141935.GB22012@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:56:13 -0000 Hi Neil, > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Saturday, January 31, 2015 10:20 PM > To: Chen, Jing D > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id >=20 > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote: > > From: Jeff Shaw > > > > Add fm10k device ID list into rte_pci_dev_ids.h. > > > > Signed-off-by: Jeff Shaw > > Signed-off-by: Chen Jing D(Mark) > > --- > > 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 unders= tand > why we bother with this pattern for filling out pci id tables. A PMD sup= ports > 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. >=20 > 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 clea= n 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 ca= n 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=20 such info, it's another story).=20 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 cha= nges. > Neil Best Regards, Mark