[dpdk-dev] RFC: DPDK drivers for DPDK bus types

[Bruce Richardson]

Hi all,

looking for input here into the area of bus-type drivers and interaction
with other drivers in DPDK.

By way of context, I'm looking at extending the vdev support in the
"raw/ioat" driver (file raw/ioat/idxd_vdev.c) to make it more user
friendly.  These devices are accessed by DPDK via nodes in /dev and
paths in /sys, with the vdev parameters being passed identifying the
particular devices to use. However, the presence of these devices can be
detected at runtime by a scan of /dev and /sys, and so it's easy enough
to implement a custom bus-type driver in DPDK to detect these, rather
than having the user pass in vdev parameters (which can get awkward to
use as the number of devices increases).

However, looking through a few other drivers in the "bus" directory, it
appears that scanning system paths, i.e. /sys, is fairly common, so I'm
wondering if it's possible to have some sharing of functionality here.
Unfortunately, the use of /sys in each of these drivers I've looked at
seem sufficiently different to me that I've not immediately seen a
common level of abstraction we can use. Therefore I'm looking for
suggestions here that those in the community might have.

On a related note, I'm also concerned about the need for a single device
type, e.g. one used by DPDK and shared with the kernel, to require two
separate drivers to work together to support it - a bus driver for
scanning and a type-specific driver for the actual functional
implementation. Can we not find a way to reduce the number of drivers
needing to be supported?

Following on from this, and if we can't find a good way of doing a
generic driver for scanning /sys nodes, I wonder if there is value in
providing a "generic" bus implementation in DPDK, as a catch-all for
device drivers which need their own custom probing, but that do not
neatly fall into the other types. The way this might work is to have the
scanning and probing of devices left entirely to the device driver
implementation itself. For example, rather than creating an idxd
bus driver, it would be easier and more self-contained to have the
rawdev driver itself able to perform scanning and probing - keeping the
code all in one place. All the bus driver would have to do is maintain a
list of drivers and found devices reported by the individual driver
after they have done their own probing. Other possible candidates to
think about that might be able to use their own probing from a generic
bus might be, e.g. af_xdp driver, or a TAP or memif driver.

Thoughts and inputs please?

Regards,
/Bruce