From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id D60075A81 for ; Sat, 31 Jan 2015 19:35:49 +0100 (CET) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YHctR-0004Yd-If; Sat, 31 Jan 2015 13:35:47 -0500 Date: Sat, 31 Jan 2015 13:35:35 -0500 From: Neil Horman To: David Marchand Message-ID: <20150131183535.GA24821@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> <20150131163227.GA23878@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 18:35:50 -0000 On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote: > On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman 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