11/03/2021 16:19, 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).
I agree. vdev bus should be used for creating device from the void. If the device has its roots in the system (HW or SW), there should be a bus for that. > 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. Not sure it's worth looking for such sharing between bus. > 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? The bus driver is managing the device life. The device driver implements a functional class. I don't see what to save. Maybe you are biased because the rawdev class is fake. > 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. So you mean there is a single user of the bus, so the implementation could be moved into the device driver, relying on a fake bus? > 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. These devices don't exist naturally in the system, so I think they should be vdev.
