From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by dpdk.org (Postfix) with ESMTP id 2AE375A7C for ; Sat, 31 Jan 2015 17:07:29 +0100 (CET) Received: by mail-ob0-f169.google.com with SMTP id va8so28530722obc.0 for ; Sat, 31 Jan 2015 08:07:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WIiz2wSsCrOF4YKEIviwG4RRp2crJyOqfEEBQewVBvY=; b=RWXTiLlKp8aD7xRAU5YO+guAK2c7/2pW2TRnn0TaWwj6OCtWJyOgd2oHkJOYRDylqs XJyE79SZJuw5++weQa9XD7eScEABDehlRT2pZ4V7iyNd/ew+LvGxiGPFtsrHwnK1Webs sdoN/cPyddgWrcUJRMOpVhVBynmN6/+bsyg39AlQrdXNEygOIP2vyy6lhUMhox9KjN9f lKhz7Mokdm2hXdxFkdE/rWEOqq4J/OBh4s7kgsmHKCPf1dLNFwKSwkbhM0MuwRlOl1RX 2Uqg70z8EVuI1BkcqDsX2/1dG40PcJndhjIeqTLds/ZMZhYflDldbptRBXMNVghpH0gl oYsg== X-Gm-Message-State: ALoCoQk7RiJjETMHwfdcMMkLOVjOGMW+LXJHolJk5mKMM+gDB8ZQZS1OWHq8y7xhDNlKjZOy0sy4 MIME-Version: 1.0 X-Received: by 10.202.7.142 with SMTP id 136mr6559342oih.51.1422720448298; Sat, 31 Jan 2015 08:07:28 -0800 (PST) Received: by 10.76.95.198 with HTTP; Sat, 31 Jan 2015 08:07:28 -0800 (PST) In-Reply-To: <20150131141935.GB22012@localhost.localdomain> 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> Date: Sat, 31 Jan 2015 17:07:28 +0100 Message-ID: From: David Marchand To: Neil Horman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Sat, 31 Jan 2015 16:07:29 -0000 On Sat, Jan 31, 2015 at 3:19 PM, Neil Horman wrote: > 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 > 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 ? -- David Marchand