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 B62073237 for ; Tue, 24 May 2016 16:55:30 +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:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b5Djx-0007ZZ-Gx; Tue, 24 May 2016 10:55:28 -0400 Date: Tue, 24 May 2016 10:55:19 -0400 From: Neil Horman To: Panu Matilainen Cc: dev@dpdk.org, Bruce Richardson , Thomas Monjalon , Stephen Hemminger Message-ID: <20160524145519.GB6721@hmsreliant.think-freely.org> References: <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> <20160523135512.GA29868@hmsreliant.think-freely.org> <2fc007f6-2fdf-6ee2-0074-51e5be357884@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fc007f6-2fdf-6ee2-0074-51e5be357884@redhat.com> 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: Tue, 24 May 2016 14:55:31 -0000 On Tue, May 24, 2016 at 09:15:41AM +0300, Panu Matilainen wrote: > On 05/23/2016 04:55 PM, Neil Horman wrote: > > 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. > > Why not? I dont get it. > For all the reasons I've stated in the I don't even know how many emails we've sent back and forth in this thread. Because, once again, just because a pmd exists in the auto load path at the time you do the scan, doesn't mean it will be there at the time you run the application. By creating this PMD mode, the users has to recognize implicitly that there is something different about autoloaded pmds, namely that they are not expressly bound to the application itself. By specifing a special option they can still figure out what hardware support exists in the autoload path at that time, but they have to realize that these pmds are 'different' > > 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" > > Well, for the application to be able to load any PMDs, it will have to be > linked to some version of librte_eal, which will have to be somewhere in the > library search path (or use rpath). > Yes. but see my above complaint. Implicitly tying the application to the PMD autoload path is trivial, I'm not making that argument, what I'm arguing is that, the autoload path is transient, and so telling users that application X supports all the hardware supported by all the PMD's in the autoload path is erroneous, because whats there the moment you scan, isn't guaranteed to be there the moment the application runs. Thats the compromise I've been trying to offer you. By creating a separate 'plugin' mode we offer the user the chance to ask each question above independently, and thereby allow them to draw the conclusion that tying hardware support in the autoload path is an extra step that they need to manage (by linking to the right dpdk version, or by setting LD_LIBRARY_PATH correctly, etc). > > > 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 would think requiring a specific option to enable the plugin scan should > be quite enough to make that point clear. > Yes, that was why I wrote the option. Soo.....Are we in agreement here? > > > > > > 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/ > a lousy comparison, as the notion of static linkage of the kernel doesn't really > > compare to static application linkage, but still, people can figure out whats > > going on there pretty readily, and I think they can here too. > > > > As to your other comment, yes, the end users just want to know "will it work". > > But from a philisophical standpont, I don't agree with your assertion that > > we can answer this question by doing what you're asking me to do. The answer to > > "Will my application support the hardware on this system with the plugins found > > in RTE_EAL_PMD_PATH?" is "I don't know". Thats because you don't know what the > > contents of that directory will be when the application is run later. > > Come on. RTE_EAL_PMD_PATH is expected to point to a system directory owned > by root or such, stuff just doesn't randomly come and go. Everything is > subject to root changing system configuration between now and some later > time. > Sure it can, rpm's/deb/etc are added and removed regularly. The method of change doesn't matter, its the result that counts. > > The only things we can tell at the time we run pmdinfo are: > > > > 1) What the hardware support of a static binary is for its linked in libraries > > > > 2) What the hardware support of a dynamic binary is via its DT_NEEDED entries > > > > 3) What the hardware support of a specific PMD DSO is > > > > I am fundamentally opposed to trying to guess what hardware support will be > > loaded dynamically via dlopen methods when an application is run at a later > > time, and firmly believe that it is more consistent to simply not report that > > information in both the static and dynamic case, and educate the user about how > > to determine hardware support for dynamically loaded PMD's (perhaps a man page > > would be worthwhile here) > > Well, with the plugin mode and pmd path export in your v3 patches (thanks > for that!) all the necessary pieces are there so fishing out the information > is a rather trivial one-liner of a script now: > > --- > #!/bin/sh > > /usr/share/dpdk/tools/pmdinfo.py -p $(ldd $1 |awk '/librte_eal/{print $3}') > --- > > I fail to understand how having a separate script to handle this is better > than having pmdinfo do it directly when run in the plugin mode, but as you > wish. > You don't even need a script, you just need to have the rudimentary understanding that DPDK is architected in such a way that hardware support may be embodied in multiple binaries, and so depending on your load method (link time vs. run time), you may need to check a different location. Its really not that hard. You have to understand that thats the case anyway if you use -d on the command line. > - Panu - > >