[virtio-pci]: The interrupt setup code should be reworked, to remove legacy MSI support (nonstandard for virtio) and enable MSI-X where possible; this should slightly improve interrupt performance by itself, should help a lot more when virtio-net support multiple RX/TX queues.

[virtqueue/virtio core]: Restore indirect ring support — QEMU’s virtio-blk has a default 128-entry ring; virtio-blk can blow out that ring readily without indirect ring support. virtio-blk is often performance limited by this (in bandwidth).

[virtio-blk]: Indirect ring entries; see above.

[virtio-blk]: We investigated “pacing” a while back — while the isr is running on an ithread, the front end (dispatch) code can queue directly to it, rather than generating a VQ kick. It changed performance, mostly for the better when we played with it.

[virtio-blk]: Investigate why DFly doesn’t (didn’t?) run on qemu when virtio-blk dataplane is enabled. It seemed to stall somewhere in the bootloader.

[virtio-net]: Multiple TX/RX queues, one per CPU; DragonFly could make excellent use of this. One serializer per-queue. Looking at the differences between the if_em and if_emx driver would show the diffs required, roughly.

Other stuff for running on KVM:
PV-EOI — paravirt EOI should reduce the cost of ACKing a virtual interrupt, specifically the number of intercepts.

kvmclock: Not sure what the default DFly timer is on KVM these days; kvmclock may be a better option than the ACPI-safe timer, the CMOS RTC, and the i8254.

Dragonfly’s idle thread tries to use MONITOR/MWAIT for a bit before switching to HLT (and then deeper). In workloads with rapid halt/activate cycles, the early monitor/mwait helped a lot, but it is not available in KVM. Some other fast halt may be worth looking into, before dropping to a full HLT. (HLT may be fairly expensive in a VM).