From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0094685367; Mon, 23 May 2016 11:56:21 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-59.ams2.redhat.com [10.36.6.59]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4NBuIlS028096; Mon, 23 May 2016 07:56:19 -0400 To: Neil Horman 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> Cc: dev@dpdk.org, Bruce Richardson , Thomas Monjalon , Stephen Hemminger From: Panu Matilainen Message-ID: Date: Mon, 23 May 2016 14:56:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160520140652.GA17882@hmsreliant.think-freely.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 23 May 2016 11:56:22 +0000 (UTC) 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 11:56:22 -0000 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 -