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
