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 25F402C3F for ; Fri, 27 May 2016 14:46:35 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 23C5B7D0C7; Fri, 27 May 2016 12:46:34 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-187.ams2.redhat.com [10.36.7.187]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4RCkV8N010223; Fri, 27 May 2016 08:46:32 -0400 To: Neil Horman References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1484190.9fzbW2DJJe@xps13> <20160525174721.GE14322@hmsreliant.think-freely.org> <1653357.fSAMoabLvC@xps13> <20160527113540.GA13448@hmsreliant.think-freely.org> Cc: Thomas Monjalon , dev@dpdk.org, Bruce Richardson , Stephen Hemminger From: Panu Matilainen Message-ID: <528ceda3-b670-60b8-a1df-c65f0c6a19b1@redhat.com> Date: Fri, 27 May 2016 15:46:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160527113540.GA13448@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.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 27 May 2016 12:46:34 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCHv4 5/5] pmdinfo.py: Add tool to query binaries for hw and other 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: Fri, 27 May 2016 12:46:35 -0000 On 05/27/2016 02:35 PM, Neil Horman wrote: > On Fri, May 27, 2016 at 12:16:03PM +0300, Panu Matilainen wrote: > >> Yup. But there's also a bit of a gotcha involved with the virtual devices >> with added api. This is how eg testpmd looks when built in shared library >> config: >> >> [pmatilai@sopuli ~]$ pmdinfo /usr/bin/testpmd >> Scanning /usr/lib64/librte_pmd_bond.so.1 for pmd information >> PMD NAME: bonding >> PMD TYPE: PMD_VDEV >> PMD PARAMETERS: slave= primary= mode=[0-4] xmit_policy=[l2 | l23 | >> l34] socket_id= mac= lsc_poll_period_ms= up_delay= >> down_delay= >> >> [pmatilai@sopuli ~]$ >> >> Having support for bonding driver but nothing else will seem pretty damn >> confusing unless you happen to be a dpdk developer knowing this fact about >> some pmds also providing API and being linked directly etc. >> > Possibly, but I think its important to remember that we aren't really dealing > with end users buying this software at best buy. The target user is more likely > a sysadmin, that I would like to think has the wherewithal to understand that > hardware support might be either (a) built-in, getting loaded at runtime by > virtue of the program itself, or a library that it is explicitly linked to, or > (b) configured-in, getting resolved an loaded at run time by virtue of a > configuration file or other site specific element. They should be able to > figure out that the latter won't be discoverable by pmdinfo without help. Sure, but ability to figure something out doesn't necessarily mean they should have to, much less want to, do so. Somebody setting up DPDK is interested in moving network packets, and the details of how a particular piece of software was built and linked together couldn't be much more further from away from that task. I do remember the days when you had to manually load device drivers by kernel module names during Linux installation and while I certainly could do it, I dont really miss that part a single bit :) I also realize I'm probably way ahead of things with my these usability ramblings when you're only trying to get the feature in, and that's clearly been causing some unintended friction here. Sorry about that, I'm really just excited about the possibilities this feature opens. >> Might make sense to have extra cli switch to control which kind of pmds are >> shown, and maybe default to skipping vdevs since they dont provide any >> actual hardware support anyway. Showing nothing at all in the above case >> would likely be a little less confusing. Maybe :) >> > So, Thomas and I just finished arguing about the VDEV/PDEV issue. Since he > asserted that the ennumeration for device types was being removed I removed any > notion of differentiation from the tool. Unless there are plans to keep that > differentiation, I don't think adding a filter for device types is really > advisable Ah yes, sorry. I did see the discussion but the actual message apparently failed to register :) > > What might be useful is a filter on vendor/device id's. That is to say only > show pmd information that matches the specified vendor/device tuple, so that a > user can search to see if the application supports the hardware they have. Yeah, makes sense. >> Anyway, this is "refine later if needed once we gain more experience" >> material to me. > Agreed, this isn't an addition that needs to happen now, walk before we run. Nod. - Panu - > Neil > >> >> - Panu - >> >>