Avi Kivity wrote: > There is no choice. Exiting from the guest to the kernel to userspace > is prohibitively expensive, you can't do that on every packet. I didn't look at virtio-net very closely yet. I wonder why the notification is that a big issue though. It is easy to keep the number of notifications low without increasing latency: Check shared ring status when stuffing a request. If there are requests not (yet) consumed by the other end there is no need to send a notification. That scheme can even span multiple rings (nics with rx and tx for example). Host backend can put a limit on the number of requests it takes out of the queue at once. i.e. block backend can take out some requests, throw them at the block layer, check whenever any request in flight is done, if so send back replies, start over again. guest can put more requests into the queue meanwhile without having to notify the host. I've seen the number of notifications going down to zero when running disk benchmarks in the guest ;) Of course that works best with one or more I/O threads, so the vcpu doesn't has to stop running anyway to get the I/O work done ... cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
