Messages in this thread | | | Subject | Re: [PATCH 0/2] Expose KVM API to Linux Kernel | From | Paolo Bonzini <> | Date | Mon, 18 May 2020 13:51:07 +0200 |
| |
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
| |