Re: [PATCHv4 5/5] pmdinfo.py: Add tool to query binaries for hw and other support information

[Neil Horman <nhorman@tuxdriver.com>]

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 -
> 
>