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 BF6AD2BB5 for ; Wed, 24 Feb 2016 12:37:23 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 24 Feb 2016 03:37:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,493,1449561600"; d="scan'208";a="922846014" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.64]) by fmsmga002.fm.intel.com with SMTP; 24 Feb 2016 03:37:20 -0800 Received: by (sSMTP sendmail emulation); Wed, 24 Feb 2016 11:37:19 +0025 Date: Wed, 24 Feb 2016 11:37:19 +0000 From: Bruce Richardson To: Neil Horman Message-ID: <20160224113719.GA10520@bricha3-MOBL3> References: <1452430254-30390-1-git-send-email-david.marchand@6wind.com> <1453120248-28274-1-git-send-email-david.marchand@6wind.com> <1453120248-28274-11-git-send-email-david.marchand@6wind.com> <3759018.lgeOm8Q2D2@xps13> <20160119142930.GA25388@hmsreliant.think-freely.org> <20160119081019.607a9b48@xeon-e3> <20160119205614.GA24277@hmsreliant.think-freely.org> <20160119133514.03cf193f@xeon-e3> <20160120154000.GA13410@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160120154000.GA13410@hmsreliant.think-freely.org> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org, Neil Horman Subject: Re: [dpdk-dev] [PATCH v2 10/10] pci: place all uio pci device ids in a dedicated section 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: Wed, 24 Feb 2016 11:37:24 -0000 On Wed, Jan 20, 2016 at 10:40:00AM -0500, Neil Horman wrote: > On Tue, Jan 19, 2016 at 01:35:14PM -0800, Stephen Hemminger wrote: > > On Tue, 19 Jan 2016 15:56:14 -0500 > > Neil Horman wrote: > > > > > On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote: > > > > On Tue, 19 Jan 2016 09:29:31 -0500 > > > > Neil Horman wrote: > > > > > > > > > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote: > > > > > > 2016-01-18 13:30, David Marchand: > > > > > > > We could do something à la modinfo, but let's keep it simple for now. > > > > > > > > > > > > > > With this, you can extract the devices that need to be bound to uio / vfio > > > > > > > with tools like objdump : > > > > > > > > > > > > > > $ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm10k.so > > > > > > > > > > > > > > Contents of section rte_pci_id_uio: > > > > > > > 15760 8680a415 ffffffff 8680d015 ffffffff ................ > > > > > > > 15770 8680a515 ffffffff 00000000 00000000 ................ > > > > > > > > > > > > Yes we need a modinfo-like tool. > > > > > > Currently, the UIO/VFIO binding can be done after parsing the PCI device list. > > > > > > It is better to define the device ids locally to their drivers but it must > > > > > > be integrated with an appropriate parsing tool at the same time. > > > > > > And more importantly than any tool, the format of these ELF data must be > > > > > > properly defined, documented and extensible. > > > > > > > > > > > > Is there someone experimented with such format definition? > > > > > > Stephen, you were asking for this change, what is your opinion? > > > > > > I remember that Neil was also interested in this change: > > > > > > http://dpdk.org/ml/archives/dev/2015-January/012115.html > > > > > > Panu, Christian, this change could be related to distribution packaging. > > > > > > Thanks for helping to move this change forward. > > > > > > > > > > Yes, I would be interested in seeing this. Is the ask here that someone do it? > > > > > As I recall from the last thread that you reference, I thought David M was > > > > > interested in writing it and soliciting for ideas. If thats no longer the case, > > > > > I can take a stab at writing it. > > > > > > > > > > Neil > > > > > > > > > > > > > If these are libraries is there a way to have a real entry point > > > > to dump PCI id's. > > > > > > > Sure, you could write a method that could be dlsym-ed easily enough to fetch an > > > array of pci ids, or just print stuff the console. Not sure thats the best way, > > > but definately an option > > > Neil > > > > It is just that reading data with objdump is a kludge likely to get broken. > > > Not suggesting that we rely on objdump in perpituity, only that we export the > data, rather than a method to access it so that it can be reached via libelf. > Using a function to return the information has implicit issues at the moment > (specifically if you dlopen a dpdk driver, its constructor will attempt to > register it with the core libraries). While thats not catastrophic, it means > more stuff than you expect gets loaded, which might have wierd side effects. > Adding a separate section that you could reach via libelf would be nice I think > > Neil > Hi, while there is interesting discussion on tools, are there any objections to taking and merging this patchset as-is to at least do the cleanup of the existing pci ids list? I would assume that any tools for querying the patchlist can be done as additional work once this is applied. Regards, /Bruce