Message ID | 1422594454-11045-5-git-send-email-jing.d.chen@intel.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 5BF6D5A81; Fri, 30 Jan 2015 06:08:33 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 818AB5A98 for <dev@dpdk.org>; Fri, 30 Jan 2015 06:08:19 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 29 Jan 2015 21:08:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="447362161" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by FMSMGA003.fm.intel.com with ESMTP; 29 Jan 2015 20:54:25 -0800 Received: from shecgisg003.sh.intel.com (shecgisg003.sh.intel.com [10.239.29.90]) by shvmail01.sh.intel.com with ESMTP id t0U58E7H013936; Fri, 30 Jan 2015 13:08:14 +0800 Received: from shecgisg003.sh.intel.com (localhost [127.0.0.1]) by shecgisg003.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t0U58CtM011107; Fri, 30 Jan 2015 13:08:14 +0800 Received: (from jingche2@localhost) by shecgisg003.sh.intel.com (8.13.6/8.13.6/Submit) id t0U58Cpa011103; Fri, 30 Jan 2015 13:08:12 +0800 From: "Chen Jing D(Mark)" <jing.d.chen@intel.com> To: dev@dpdk.org Date: Fri, 30 Jan 2015 13:07:20 +0800 Message-Id: <1422594454-11045-5-git-send-email-jing.d.chen@intel.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1422594454-11045-1-git-send-email-jing.d.chen@intel.com> References: <1422594454-11045-1-git-send-email-jing.d.chen@intel.com> Subject: [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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Chen, Jing D
Jan. 30, 2015, 5:07 a.m. UTC
From: Jeff Shaw <jeffrey.b.shaw@intel.com> Add fm10k device ID list into rte_pci_dev_ids.h. Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com> Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com> --- lib/librte_eal/common/include/rte_pci_dev_ids.h | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) \ No newline at end of file
Comments
On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote: > From: Jeff Shaw <jeffrey.b.shaw@intel.com> > > Add fm10k device ID list into rte_pci_dev_ids.h. > > Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com> > Signed-off-by: Chen Jing D(Mark) <jing.d.chen@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. Neil
On Sat, Jan 31, 2015 at 3:19 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote: > > From: Jeff Shaw <jeffrey.b.shaw@intel.com> > > > > Add fm10k device ID list into rte_pci_dev_ids.h. > > > > Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com> > > Signed-off-by: Chen Jing D(Mark) <jing.d.chen@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 ?
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@tuxdriver.com> wrote: > > > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote: > > > From: Jeff Shaw <jeffrey.b.shaw@intel.com> > > > > > > Add fm10k device ID list into rte_pci_dev_ids.h. > > > > > > Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com> > > > Signed-off-by: Chen Jing D(Mark) <jing.d.chen@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
On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote: > > 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. > Yes, but if a pmd can do this itself alone, there is no discrepancy either. Thinking aloud ... As long as the pmd does all the magic bindings, the dpdk core does not need to know about it. And if the dpdk core really needs to know about this (I can see no use case here, just want to avoid being blocked later) a dynamic register system would be fine too. > 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 > Not sure either, I just think we may reinvent the wheel :-)
On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote: > On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > > > On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote: > > > 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. > > > > Yes, but if a pmd can do this itself alone, there is no discrepancy either. > Yes, absolutely, but it needs to be done in a way that an external binary can inspect the object independently of its being loaded, and preferably in a non-programatic context (since the uio bind/unbind utilities are separate scripts). The modinfo method involves putting info into a special data section that gets processed as part of the kernel modpost build stage. There, the additional section gets translated into a C file, and built into its own object thats attached to the final binary module. We can so the same thing here if you like We could do something simpler, too. For instance we could add a field to the struct that gets registered as part of the RTE_REGISTER_PMD macro, and export it via a new ethdev library call. That would be very straightforward, but the implication there is that you would need a programatic method to interrogate that information (a binary to call into the dpdk), which is not part of how the bind/unbind scripts work today. > Thinking aloud ... > As long as the pmd does all the magic bindings, the dpdk core does not need > to know about it. Yes, I'm not suggesting anything other than the pmd be responsible for codifying its binding information. Its how that information is exported to other utilities that potentially increases the complexity of this operation. > And if the dpdk core really needs to know about this (I can see no use case > here, just want to avoid being blocked later) a dynamic register system > would be fine too. Sure, I don't see a problem with that. If we properly macro-wrap this, we can likely add a dynamic registration mechanism without having to change the pmds later Neil > > > > > 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 > > > > Not sure either, I just think we may reinvent the wheel :-) > > > -- > David Marchand
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 > > On Fri, Jan 30, 2015 at 01:07:20PM +0800, Chen Jing D(Mark) wrote: > > From: Jeff Shaw <jeffrey.b.shaw@intel.com> > > > > Add fm10k device ID list into rte_pci_dev_ids.h. > > > > Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com> > > Signed-off-by: Chen Jing D(Mark) <jing.d.chen@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
Hello Neil, Reviving this old thread. On Sat, Jan 31, 2015 at 7:35 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote: > > On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman <nhorman@tuxdriver.com> > wrote: > > > > > On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote: > > > > 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. > > > > > > > Yes, but if a pmd can do this itself alone, there is no discrepancy > either. > > > Yes, absolutely, but it needs to be done in a way that an external binary > can > inspect the object independently of its being loaded, and preferably in a > non-programatic context (since the uio bind/unbind utilities are separate > scripts). > > The modinfo method involves putting info into a special data section that > gets > processed as part of the kernel modpost build stage. There, the additional > section gets translated into a C file, and built into its own object thats > attached to the final binary module. We can so the same thing here if you > like > > We could do something simpler, too. For instance we could add a field to > the > struct that gets registered as part of the RTE_REGISTER_PMD macro, and > export it > via a new ethdev library call. That would be very straightforward, but the > implication there is that you would need a programatic method to > interrogate > that information (a binary to call into the dpdk), which is not part of > how the > bind/unbind scripts work today. > > > Thinking aloud ... > > As long as the pmd does all the magic bindings, the dpdk core does not > need > > to know about it. > Yes, I'm not suggesting anything other than the pmd be responsible for > codifying > its binding information. Its how that information is exported to other > utilities that potentially increases the complexity of this operation. > > > And if the dpdk core really needs to know about this (I can see no use > case > > here, just want to avoid being blocked later) a dynamic register system > > would be fine too. > Sure, I don't see a problem with that. If we properly macro-wrap this, we > can > likely add a dynamic registration mechanism without having to change the > pmds > later > Did you work on this ? I have been playing with this, I will most likely propose patches soon. My preferred approach is to dedicate an elf section for this ("à la" kernel .modinfo). I tried to reuse modinfo, but the problem is that kmod implementation is checking the filename extension against .ko and .ko.gz. I find it a bit too bad to have to rewrite this kind of tool just for dpdk ... but on the other hand we would need something for bsd as well or we give a shell script that rely on readelf to retrieve theis section.
On Thu, May 07, 2015 at 01:06:02PM +0200, David Marchand wrote: > Hello Neil, > > Reviving this old thread. > > On Sat, Jan 31, 2015 at 7:35 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > > > On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote: > > > On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman <nhorman@tuxdriver.com> > > wrote: > > > > > > > On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote: > > > > > 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. > > > > > > > > > > Yes, but if a pmd can do this itself alone, there is no discrepancy > > either. > > > > > Yes, absolutely, but it needs to be done in a way that an external binary > > can > > inspect the object independently of its being loaded, and preferably in a > > non-programatic context (since the uio bind/unbind utilities are separate > > scripts). > > > > The modinfo method involves putting info into a special data section that > > gets > > processed as part of the kernel modpost build stage. There, the additional > > section gets translated into a C file, and built into its own object thats > > attached to the final binary module. We can so the same thing here if you > > like > > > > We could do something simpler, too. For instance we could add a field to > > the > > struct that gets registered as part of the RTE_REGISTER_PMD macro, and > > export it > > via a new ethdev library call. That would be very straightforward, but the > > implication there is that you would need a programatic method to > > interrogate > > that information (a binary to call into the dpdk), which is not part of > > how the > > bind/unbind scripts work today. > > > > > Thinking aloud ... > > > As long as the pmd does all the magic bindings, the dpdk core does not > > need > > > to know about it. > > Yes, I'm not suggesting anything other than the pmd be responsible for > > codifying > > its binding information. Its how that information is exported to other > > utilities that potentially increases the complexity of this operation. > > > > > And if the dpdk core really needs to know about this (I can see no use > > case > > > here, just want to avoid being blocked later) a dynamic register system > > > would be fine too. > > Sure, I don't see a problem with that. If we properly macro-wrap this, we > > can > > likely add a dynamic registration mechanism without having to change the > > pmds > > later > > > > Did you work on this ? > No, I had assumed from our previous discussion that you were. > > I have been playing with this, I will most likely propose patches soon. > > My preferred approach is to dedicate an elf section for this ("à la" kernel > .modinfo). Yes, this makes sense. > I tried to reuse modinfo, but the problem is that kmod implementation is > checking the filename extension against .ko and .ko.gz. > Well, you can alter modinfo so that it looks at .so files if you like, but thats not the only tool you can use. Truthfully you can just use objdump if you like. > I find it a bit too bad to have to rewrite this kind of tool just for dpdk > ... but on the other hand we would need something for bsd as well or we > give a shell script that rely on readelf to retrieve theis section. > See above, try objdump -j=.modinfo -S /path/to/kernel/module. objdump doesn't care about file extensions, as long as its ELF. With that you can: 1) Dump out any section contents you like 2) strip away the application top end, and just use libbfd to get at the elf contents if you like. Neil > > -- > David Marchand
On Thu, May 7, 2015 at 3:36 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > > I tried to reuse modinfo, but the problem is that kmod implementation is > > checking the filename extension against .ko and .ko.gz. > > > Well, you can alter modinfo so that it looks at .so files if you like, but > thats > not the only tool you can use. Truthfully you can just use objdump if you > like. > > > I find it a bit too bad to have to rewrite this kind of tool just for > dpdk > > ... but on the other hand we would need something for bsd as well or we > > give a shell script that rely on readelf to retrieve theis section. > > > See above, try objdump -j=.modinfo -S /path/to/kernel/module. objdump > doesn't > care about file extensions, as long as its ELF. With that you can: > > 1) Dump out any section contents you like > 2) strip away the application top end, and just use libbfd to get at the > elf > contents if you like. > Yes, I reached the same conclusion. Ok, I will see what I can do. Thanks.
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 + #ifndef PCI_VENDOR_ID_INTEL /** Vendor ID used by Intel devices */ #define PCI_VENDOR_ID_INTEL 0x8086 @@ -474,6 +482,12 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_QSFP_B) RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_QSFP_C) RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_BASE_T) +/*************** Physical FM10K devices from fm10k_type.h ***************/ + +#define FM10K_DEV_ID_PF 0x15A4 + +RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF) + /****************** Virtual IGB devices from e1000_hw.h ******************/ #define E1000_DEV_ID_82576_VF 0x10CA @@ -526,6 +540,12 @@ RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET, QUMRANET_DEV_ID_VIRTIO) RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3) +/*************** Virtual FM10K devices from fm10k_type.h ***************/ + +#define FM10K_DEV_ID_VF 0x15A5 + +RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_VF) + /* * Undef all RTE_PCI_DEV_ID_DECL_* here. */ @@ -538,3 +558,5 @@ RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3) #undef RTE_PCI_DEV_ID_DECL_I40EVF #undef RTE_PCI_DEV_ID_DECL_VIRTIO #undef RTE_PCI_DEV_ID_DECL_VMXNET3 +#undef RTE_PCI_DEV_ID_DECL_FM10K +#undef RTE_PCI_DEV_ID_DECL_FM10KVF