From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
by dpdk.org (Postfix) with ESMTP id 0BDB456A1
for <dev@dpdk.org>; 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 <nhorman@tuxdriver.com>)
id 1b6G3O-0003PV-KG; Fri, 27 May 2016 07:35:52 -0400
Date: Fri, 27 May 2016 07:35:40 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Panu Matilainen <pmatilai@redhat.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, dev@dpdk.org,
Bruce Richardson <bruce.richardson@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>
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>
<a61f5b81-7828-30a1-f2f8-2057af65e53c@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a61f5b81-7828-30a1-f2f8-2057af65e53c@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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=<ifc> primary=<ifc> mode=[0-4] xmit_policy=[l2 | l23 |
> l34] socket_id=<int> mac=<mac addr> lsc_poll_period_ms=<int> up_delay=<int>
> down_delay=<int>
>
> [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 -
>
>