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 0BDB456A1 for ; Fri, 27 May 2016 13:35:56 +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 1b6G3O-0003PV-KG; Fri, 27 May 2016 07:35:52 -0400 Date: Fri, 27 May 2016 07:35:40 -0400 From: Neil Horman To: Panu Matilainen Cc: Thomas Monjalon , dev@dpdk.org, Bruce Richardson , Stephen Hemminger Message-ID: <20160527113540.GA13448@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1484190.9fzbW2DJJe@xps13> <20160525174721.GE14322@hmsreliant.think-freely.org> <1653357.fSAMoabLvC@xps13> 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] [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 11:35:56 -0000 On Fri, May 27, 2016 at 12:16:03PM +0300, Panu Matilainen wrote: > On 05/25/2016 09:58 PM, Thomas Monjalon wrote: > > 2016-05-25 13:47, Neil Horman: > > > On Wed, May 25, 2016 at 07:22:39PM +0200, Thomas Monjalon wrote: > > > > 2016-05-24 15:41, Neil Horman: > > > > > Note that, in the case of dynamically linked applications, pmdinfo.py will scan > > > > > for implicitly linked PMDs by searching the specified binaries .dynamic section > > > > > for DT_NEEDED entries that contain the substring librte_pmd. > > > > > > > > I don't know any DPDK app dynamically linked with a PMD (with DT_NEEDED). > > > I know lots of them, they're all in the dpdk. everything under app that uses a > > > virutal device links at link time to librte_pmd_bonding and librte_pmd_pipe (and > > > a few others), because they have additional apis that they need to resolve at > > > load time. > > > > Oh yes! you are right. > > Also everything linking against the linker script (in its current form) such > as OVS will pull in absolutely everything, including the pmds: > > [pmatilai@sopuli ~]$ ldd /usr/sbin/ovs-vswitchd | awk '/librte_pmd/ {print > $1}' > librte_pmd_bnx2x.so.1 > librte_pmd_virtio.so.1 > librte_pmd_cxgbe.so.1 > librte_pmd_ring.so.2 > librte_pmd_af_packet.so.1 > librte_pmd_vhost.so.1 > librte_pmd_ixgbe.so.1 > librte_pmd_vmxnet3_uio.so.1 > librte_pmd_fm10k.so.1 > librte_pmd_i40e.so.1 > librte_pmd_null.so.1 > librte_pmd_pcap.so.1 > librte_pmd_null_crypto.so.1 > librte_pmd_ena.so.1 > librte_pmd_e1000.so.1 > librte_pmd_qede.so.1 > librte_pmd_bond.so.1 > librte_pmd_enic.so.1 > [pmatilai@sopuli ~]$ > > > > > > > However it is a good idea to handle this case. > > 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. > 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 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. > 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. Neil > > - Panu - > >