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 C43125699 for ; Fri, 27 May 2016 11:16:06 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 028B5C05B1EF; Fri, 27 May 2016 09:16:06 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-187.ams2.redhat.com [10.36.7.187]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4R9G43M016765; Fri, 27 May 2016 05:16:04 -0400 To: Thomas Monjalon , Neil Horman References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1484190.9fzbW2DJJe@xps13> <20160525174721.GE14322@hmsreliant.think-freely.org> <1653357.fSAMoabLvC@xps13> Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger From: Panu Matilainen Message-ID: Date: Fri, 27 May 2016 12:16:03 +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: <1653357.fSAMoabLvC@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 27 May 2016 09:16:06 +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 09:16:07 -0000 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. 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 :) Anyway, this is "refine later if needed once we gain more experience" material to me. - Panu -