From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id B66A72BB9 for ; Wed, 24 Feb 2016 12:52:14 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id c200so265555466wme.0 for ; Wed, 24 Feb 2016 03:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=QK0RZjn6AUOnMF8pK7j+03n7znzHAMMW99GlDIbgKKs=; b=1FdVWyHHOlFK5cY9wCixzbb3pRuGeBHfuj7CgBQxxNVF5oeCbFMsif7+KCPzp75u3s Szvj0aMvKD9vRIX2VFl+NsHqej/UB4RIEmmwh8bpxCiI38tOlqxyQz+XhPLAG/wJOm61 bPsNBNICr+8DlBis7FL61HmuORHhUNcwczdrirw+c8v8xl1YzesKg4XyHi8gD2K1uTx5 PSruMDalM+twfCf3mtxzy7u+vNsFD/OwV0Hx77CyNkhG44qpgY69/zr1jbjccDkSNEUB HkaJUjz3qPvlCOsazylm3d6qIVJ9rtFMMX2Tbc/c4vcBZ5pGLzfUcOrFN/oKKhmU0F/9 Y2nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=QK0RZjn6AUOnMF8pK7j+03n7znzHAMMW99GlDIbgKKs=; b=lnCJqD4JroQLRfdg+nVdqs3QVLJBQK7etcj0a9w203yn/cVycV9Em0QqZWz9RJqQ88 Ktoor0PhKunTQfxW9ClQSrPHeYHsHC8qeJq7HHaC3agHAPhWkE7SNKANmVMWesj01IiP mvnQfP5FQeqwQe/5gS+CFLKpMzqWG48b0e38ShSUkLqmKlQzJXUN9rI6aM9+vvyhHENJ UEk70fklRde0ODZMs9VwJNIzPHQQeKGEFi0+zZWp8vi1gDBCejNnZylm9xUoX3tKy/YW j2r20r6K6V2xKtBIeL+Jrraeyh5pcdllLsPq31D1T2QrFy0zMGRuMVWMj5VKU9MCROq7 WWCw== X-Gm-Message-State: AG10YOSM4EmNqi5fVGfFzWLazH9CkK4pMnAnZqikAx+ufUDUukQrlzcPJC/lsAZXHhRaOFz2 X-Received: by 10.194.62.102 with SMTP id x6mr39334844wjr.18.1456314734579; Wed, 24 Feb 2016 03:52:14 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id h132sm3107118wmf.9.2016.02.24.03.52.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 03:52:13 -0800 (PST) From: Thomas Monjalon To: dev@dpdk.org Date: Wed, 24 Feb 2016 12:50:40 +0100 Message-ID: <24283387.cvDMb4MfJx@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160224113719.GA10520@bricha3-MOBL3> References: <1452430254-30390-1-git-send-email-david.marchand@6wind.com> <20160120154000.GA13410@hmsreliant.think-freely.org> <20160224113719.GA10520@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: 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:52:14 -0000 2016-02-24 11:37, Bruce Richardson: > 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: > > >=20 > > > > On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wro= te: > > > > > On Tue, 19 Jan 2016 09:29:31 -0500 > > > > > Neil Horman wrote: > > > > >=20 > > > > > > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon w= rote: > > > > > > > 2016-01-18 13:30, David Marchand: > > > > > > > > We could do something =E0 la modinfo, but let's keep it= simple for now. > > > > > > > >=20 > > > > > > > > With this, you can extract the devices that need to be = bound to uio / vfio > > > > > > > > with tools like objdump : > > > > > > > >=20 > > > > > > > > $ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm1= 0k.so > > > > > > > >=20 > > > > > > > > Contents of section rte_pci_id_uio: > > > > > > > > 15760 8680a415 ffffffff 8680d015 ffffffff ...........= ..... > > > > > > > > 15770 8680a515 ffffffff 00000000 00000000 ...........= ..... > > > > > > >=20 > > > > > > > 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 dr= ivers but it must > > > > > > > be integrated with an appropriate parsing tool at the sam= e time. > > > > > > > And more importantly than any tool, the format of these E= LF data must be > > > > > > > properly defined, documented and extensible. > > > > > > >=20 > > > > > > > Is there someone experimented with such format definition= ? > > > > > > > Stephen, you were asking for this change, what is your op= inion? > > > > > > > I remember that Neil was also interested in this change: > > > > > > > =09http://dpdk.org/ml/archives/dev/2015-January/012115.ht= ml > > > > > > > Panu, Christian, this change could be related to distribu= tion packaging. > > > > > > > Thanks for helping to move this change forward. > > > > > >=20 > > > > > > 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 thou= ght David M was > > > > > > interested in writing it and soliciting for ideas. If that= s no longer the case, > > > > > > I can take a stab at writing it. > > > > > >=20 > > > > > > Neil > > > > > >=20 > > > > >=20 > > > > > If these are libraries is there a way to have a real entry po= int > > > > > to dump PCI id's.=20 > > > > >=20 > > > > Sure, you could write a method that could be dlsym-ed easily en= ough to fetch an > > > > array of pci ids, or just print stuff the console. Not sure th= ats the best way, > > > > but definately an option > > > > Neil > > >=20 > > > It is just that reading data with objdump is a kludge likely to g= et broken. > > >=20 > > 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 v= ia libelf. > > Using a function to return the information has implicit issues at t= he moment > > (specifically if you dlopen a dpdk driver, its constructor will att= empt 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 > >=20 > > Neil > >=20 > Hi, >=20 > while there is interesting discussion on tools, are there any objecti= ons 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.=20 Today we can parse the global PCI list to bind devices to DPDK. If we remove this list, we must replace it by another convenient method= . And more importantly, the informations in the ELF files must be extendi= ble and in a stable syntax. The problem here is that it is poorly specified. Please let's describe a syntax for these ELF data, first.