From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [PATCH 4/4] pmd_hw_support.py: Add tool to query binaries for hw support information Date: Mon, 23 May 2016 14:56:18 +0300 Message-ID: References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <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=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Bruce Richardson , Thomas Monjalon , Stephen Hemminger To: Neil Horman Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 8D8035A32 for ; Mon, 23 May 2016 13:56:22 +0200 (CEST) In-Reply-To: <20160520140652.GA17882@hmsreliant.think-freely.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 :) 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?" - Panu -