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

Panu Matilainen pmatilai at redhat.com
Fri May 27 11:16:03 CEST 2016


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



More information about the dev mailing list