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 12B8D5A63 for ; Wed, 18 May 2016 15:55:09 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1b31wD-0003rV-35; Wed, 18 May 2016 09:55:06 -0400 Date: Wed, 18 May 2016 09:54:55 -0400 From: Neil Horman To: Thomas Monjalon Cc: Panu Matilainen , dev@dpdk.org, Bruce Richardson , Stephen Hemminger Message-ID: <20160518135455.GC29900@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <20348777.VsQliCQX8c@xps13> <9583b572-d793-7b3f-1de9-facd0925ea56@redhat.com> <9587214.IFAZzzbh8a@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9587214.IFAZzzbh8a@xps13> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH 4/4] pmd_hw_support.py: Add tool to query binaries for hw support information 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, 18 May 2016 13:55:09 -0000 On Wed, May 18, 2016 at 03:26:42PM +0200, Thomas Monjalon wrote: > 2016-05-18 16:09, Panu Matilainen: > > On 05/18/2016 03:38 PM, Thomas Monjalon wrote: > > > 2016-05-18 14:48, Panu Matilainen: > > >> Calling up on the list of requirements from > > >> http://dpdk.org/ml/archives/dev/2016-May/038324.html, I see a pile of > > >> technical requirements but perhaps we should stop for a moment to think > > >> about the use-cases first? > > >> > > >> To name some from the top of my head: > > >> - user wants to know whether the hardware on the system is supported > > > > > > supported by what? > > > * by a statically linked app > > > * by a DPDK he has downloaded and built > > > * by a DPDK provided as shared library by its Linux vendor > > > > All three? > > Not at the same time ;) > > > > In the first 2 cases he knows where the files are. > > > In the Linux distribution case, there can be a default directory set > > > by the Linux vendor for the script looking at the infos. Only the Linux > > > vendor knows where the PMDs files are. > > > > For case 3), EAL and the DPDK build system know where the PMDs are via > > CONFIG_RTE_EAL_PMD_PATH (if set of course, otherwise there's not much hope) > > In case 3 (DPDK packaged in distribution), I would rely on the packager (you) > who knows where the libraries are installed. > You can even have a script calling system tools (lspci or other from your > distribution) to get hardware infos and then check if it matches the PCI ids > listed by the DPDK tool. > I think the only sane solution here is to scan for the file in /lib:/usr/lib:$LD_LIBRAR_PATH. Thats the only way that we can come close to mimicing what the application will do when linking. Truthfully, the RTE_EAL_PMD_PATH variable should be dropped and set to that anyway to ensure that the system admin can point to the right libraries when installing an application. > > >> - user wants to know which package(s) need to be installed to support > > >> the system hardware > > > > > > You mean "which DPDK packages"? > > > > Yes. This is of course only relevant if PMDs are split across several > > different packages (splitting might not make much sense yet, but as the > > number grows that might well change) > > > > > Are some informations showed when doing "packager search dpdk"? > > > or "packager show dpdk-driverX"? > > > Do you want to show the PCI ids in the description of the packages? > > > > Something along those lines - such things are being done by distros for > > eg firmware, printer drivers, kernel drivers by modalias etc. > > So the packager would call the DPDK tool listing PCI ids of compiled libs. > > > >> - user wants to list all supported hardware before going shopping > > > > > > Why doing shopping? For a DPDK usage or for a specific application? > > > > To buy hardware which is supported by DPDK, in a general case. > > > > > The application should mentions the supported hardware. > > > For more general DPDK information, there is this this page: > > > http://dpdk.org/doc/nics > > > But it may be not enough accurate for some PCI id exceptions. > > > For more details, he must use a listing tool. > > > > Yes. The point is, what kind of tool/solution can be made to behave > > identically between shared and static configs, in a user-friendly way. I > > just listed a few obvious (to me at least) use-cases, and was asking for > > others that I didn't think of. > > For a user-friendly output, we should not export only PCI ids but also > the commercial names. > Thats not something that the DSO's should export explicitly. If you want commercial names, the hw_info tool should incorporate the use of the pci.ids file from the pci hardware database project (thats how lspci works). That seems like a nice bell and whistle to add later though. Lets get the initial functionality working first before we start adding features like that > About the static/shared case, we can have a script which look at testpmd > plus the shared libs. In a dev space, it is easy to find the files. > In a packaged system, the script can get some configuration variables from > the distribution. > >