On 18/05/20 13:34, Maxim Levitsky wrote: >> In high-performance configurations, most of the time virtio devices are >> processed in another thread that polls on the virtio rings. In this >> setup, the rings are configured to not cause a vmexit at all; this has >> much smaller latency than even a lightweight (kernel-only) vmexit, >> basically corresponding to writing an L1 cache line back to L2. > > This can be used to run kernel drivers inside a very thin VM IMHO to break up > the stigma, > that kernel driver is always a bad thing to and should be by all means > replaced by a userspace driver, > something I see a lot lately, and what was the ground for rejection of my > nvme-mdev proposal.
It's a tought design decision between speeding up a kernel driver with something like eBPF or wanting to move everything to userspace. Networking has moved more towards the first because there are many more opportunities for NIC-based acceleration, while storage has moved towards the latter with things such as io_uring. That said, I don't see why in-kernel NVMeoF drivers would be acceptable for anything but Fibre Channel (and that's only because FC HBAs try hard to hide most of the SAN layers). Paolo
