From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 292B26C9D for ; Wed, 18 May 2016 15:27:13 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id g17so26523195wme.0 for ; Wed, 18 May 2016 06:27:13 -0700 (PDT) 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:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=qHD4so8arznjooJRc8XmhUZYPkOaaG+UXmXd2LolJ48=; b=snMguiUw1GO/SIfqqO5qULSODXhVSOUjtQOVH8kWvsQKm1klDjdCvLCFqmA4FjFWs0 QSt/7GajhGHSEnA/9poXKRj487XRhkJl5oaq1cw8qM9xHgXo66SFrUticqO+2G4e4RSL lcVNv8kO3z3wj1Mm9USAxIwt3gv1iQDAxvYLIJvXpiO1/yBv68C0NhS+Xmvu27i9rwmd QkEietJG6ot0qhU00Bm4zSlRhOPPHhznAMz2jDkRXCy+68/UrBzSmrlKNnXdXL++LvLk PNf2b4w1Boa/m2UmfKBQ5mSo/jpB/vhcKfe9uBHlzfua+qgYuynxvry5dGyZY09m1atR Kohw== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=qHD4so8arznjooJRc8XmhUZYPkOaaG+UXmXd2LolJ48=; b=T6N3O5EWANdt/2ySWzQhKlBnfix0sUkmcWJpNk7AFbPFyoKB123y2sZgSRCMH9VGDS 8JWyw9a64KVuXvu5y6NILFinA/KU0aEMrXRHTT1k21p2eURkm/XdrcFZnHR1GVZbolZ2 45hQYPz3imzEpwSH6ScmsyDZH/g/KI9NKv1xG8XbjGwlXvB9WckIzGgdqUBcdA8/IYnB DW82qKbZF4FUYOwqYYgdxKIjYAe1XlCQ0PezKChzGrnuCTEYvrD+ZWisjIzkoecIvLVP +dN85B0SLiB4AAf8krRRUMV6UxECOjjkjZlKO1kGMImARMBvcnqI2kUwBEscGdtjJGdx qAKg== X-Gm-Message-State: AOPr4FUoJndRZmwg6Byh9JpER2/PGzGb0rQ+K1zAvqxliGrvcUnVt0hekPS/nIYDVXGCdmlo X-Received: by 10.28.22.134 with SMTP id 128mr7328739wmw.16.1463578032751; Wed, 18 May 2016 06:27:12 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id e8sm9212834wma.2.2016.05.18.06.27.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:27:11 -0700 (PDT) From: Thomas Monjalon To: Panu Matilainen Cc: Neil Horman , dev@dpdk.org, Bruce Richardson , Stephen Hemminger Date: Wed, 18 May 2016 15:26:42 +0200 Message-ID: <9587214.IFAZzzbh8a@xps13> User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <9583b572-d793-7b3f-1de9-facd0925ea56@redhat.com> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <20348777.VsQliCQX8c@xps13> <9583b572-d793-7b3f-1de9-facd0925ea56@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:27:13 -0000 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. > >> - 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. 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.