Re: [PATCH v2 4/4] usertools/dpdk-devbind: print NUMA node

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 8/20/2024 11:49 AM, Robin Jarry wrote:
> Burakov, Anatoly, Aug 20, 2024 at 11:40:
>> I have heard about driverctl for a long time in context of devbind, 
>> and I quickly tried it out just now, and IMO while the *functionality* 
>> is there, the usability of devbind is IMO far more friendly:
>>
>> - it filters by device types that are of interest to us (driverctl 
>> just lists all pci devices)
>> - it prints out user-friendly names, not just PCI addresses
>> - it lists loaded drivers, but not alternatives etc. like devbind does
>> - I didn't test this, but I suspect it would allow overriding driver 
>> for an active NIC
>> - after my changes, devbind displays NUMA socket, driverctl doesn't :)
> 
> Yes, that's fair. devbind is more a dev oriented tool. driverctl is 
> really focused on reproducible and persistent driver override (it has a 
> systemd service that will force a rebind of pci devices on reboot).

Actually, I should correct myself (and yourself) somewhat.

This is not obvious from help message (I found it through reading the 
REAME) but driverctl *does* allow listing PCI devices by type, but only 
one type (e.g. list all network devices), but not multiple (e.g. list 
network and mempool devices), and as far as I can tell it does not 
support some of the device classes that we're interested in, so we will 
have to use the entire PCI device list and then filter it.

It does also print out device names (adding "verbose" option does it).

And it also *does* allow to bind/unbind drivers without persistence - 
--nosave option does that.

Still, all of the other points apply: devbind is much more useful for 
DPDK developers as it provides information relevant to us right out of 
the box.

> 
>> What we maybe can do for e.g. next release (currently I do have better 
>> things to do if I can help it), is to make devbind a wrapper around 
>> driverctl? This way, we can still keep the usability bells and 
>> whistles we have, but drop the driver overriding code and leave it to 
>> driverctl? It seems like that would be a good compromise, with the 
>> only downside being that we'll depend on driverctl being installed.
> 
> Honestly, I don't think the dependency would be a good idea. Also, 
> driverctl does not have any option to make a driver override temporary. 
> It will persist after reboot which is not what devbind does.
> 

See above, this is actually not true: driverctl can override a driver 
without persistence.

-- 
Thanks,
Anatoly