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

[Panu Matilainen]

On 05/27/2016 02:35 PM, Neil Horman wrote:
> On Fri, May 27, 2016 at 12:16:03PM +0300, Panu Matilainen wrote:
>
>> 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.
>>
> 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.

Sure, but ability to figure something out doesn't necessarily mean they 
should have to, much less want to, do so. Somebody setting up DPDK is 
interested in moving network packets, and the details of how a 
particular piece of software was built and linked together couldn't be 
much more further from away from that task.

I do remember the days when you had to manually load device drivers by 
kernel module names during Linux installation and while I certainly 
could do it, I dont really miss that part a single bit :)

I also realize I'm probably way ahead of things with my these usability 
ramblings when you're only trying to get the feature in, and that's 
clearly been causing some unintended friction here. Sorry about that, 
I'm really just excited about the possibilities this feature opens.

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

Ah yes, sorry. I did see the discussion but the actual message 
apparently failed to register :)

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

Yeah, makes sense.

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

Nod.

	- Panu -

> Neil
>
>>
>> 	- Panu -
>>
>>