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 401C8378E for ; Mon, 23 May 2016 15:55:23 +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 1b4qKE-0008Io-Cz; Mon, 23 May 2016 09:55:20 -0400 Date: Mon, 23 May 2016 09:55:12 -0400 From: Neil Horman To: Panu Matilainen Cc: dev@dpdk.org, Bruce Richardson , Thomas Monjalon , Stephen Hemminger Message-ID: <20160523135512.GA29868@hmsreliant.think-freely.org> References: <1463431287-4551-5-git-send-email-nhorman@tuxdriver.com> <3ee4159d-fd29-1a20-1417-4c0a40c18779@redhat.com> <20160518120300.GA29900@hmsreliant.think-freely.org> <20160518134817.GB29900@hmsreliant.think-freely.org> <4e9a5124-8ea0-7f23-9268-fde1b5d4af02@redhat.com> <20160519132632.GE4128@hmsreliant.think-freely.org> <79981f3b-8fee-4594-8467-619dcf790215@redhat.com> <20160520140652.GA17882@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -2.9 (--) 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: Mon, 23 May 2016 13:55:23 -0000 On Mon, May 23, 2016 at 02:56:18PM +0300, Panu Matilainen wrote: > On 05/20/2016 05:06 PM, Neil Horman wrote: > [...] > > Look, I think we're simply not going to agree on this issue at all. What about > > this in the way of compromise. I simply am not comfortable with automatically > > trying to guess what hardware support will exist in an application based on the > > transient contents of a plugin directory, because of all the reasons we've > > already gone over, but I do understand the desire to get information about what > > _might_ be automatically loaded for an application. what if we added a 'plugin > > mode' to pmdinfo. In this mode you would dpecify a dpdk installation directory > > and an appropriate mode option. When specified pmdinfo would scan librte_eal in > > the specified directory, looking for an exported json string that informs us of > > the configured plugin directory. If found, we iterate through all the libraries > > there displaying hw support. That allows you to query the plugin directory for > > available hardware support, while not implying that the application is > > guaranteed to get it (because you didn't specifically state on the command line > > that you wanted to know about the applications hardware support). > > That brings it all to one tiny step away from what I've been asking: have > the plugin mode automatically locate librte_eal from an executable. So I'm > not quite sure where the compromise is supposed to be here :) The compromise is that I'm not willing to quietly assume that a given application linked to the dpdk library in /usr/lib64/dpdk-, will get hardware support for the cxgb4, mlx5 and ixgbe pmds, because those DSO's are in the exported RTE_EAL_PMD_PATH. With this method, you at least have to tell the pmdinfo application that I wish to scan that path for pmds and report on hardware support for whatever is found there. Thats a different operation from getting a report on what hardware an application supports. i.e. its the difference between asking the questions: "What hardware does the application /usr/bin/foo support" and "What hardware support is available via the plugin DSO's pointed to by the dpdk version in /usr/lib64/dpdk-2.2" I feel its important for users to understand that autoloading doesn't not guarantee support for the hardware that is autoloaded to any application. My compromise is to provide what your asking for, but doing so in a way that attempts to make that differentiation clear. > > I do appreciate wanting to differentiate between "physically" linked-in and > runtime-loaded hardware support, they obviously *are* different from a > technical POV. But its also a difference an average user might not even know > about or understand, let alone care about, they just want to know "will it > work?" > Which average user are we talking about here? Keep in mind the DPDK is anything but mainstream. Its a toolkit to implement high speed network communications for niche or custom purpose applications. The users of tools like this are going to be people who understand the nuance of how applications are built and want to tune them to work at their most efficient point, not some person just trying to get firefox to connect to digg. I think its reasonable to assume that people who are running the tool have sufficient knoweldge to understand that DSO's and static binaries may embody hardware support differently, and that things which are loaded at run time may not be reported at scan time (by way of corressponding example, though its not perfect, people seem to understand that iscsid supports lots of different HBA's, but the specific hardware support for those HBA's isn't codified in /usr/sbin/iscsid, but rather in the modules under /lib/modules/ - Panu - > >