Herbert Xu wrote:
Avi Kivity <avi@xxxxxxxxxx> wrote:
virtio is already non-kvm-specific (lguest uses it) and non-pci-specific
(s390 uses it).
I think Greg's work shows that putting the backend in the kernel
can dramatically reduce the cost of a single guest->host transaction.
I'm sure the same thing would work for virtio too.
Virtio suffers because we've had no notification of when a packet is
actually submitted. With the notification, the only difference should
be in the cost of a kernel->user switch, which is nowhere nearly as
dramatic.
If you have a good exit mitigation scheme you can cut exits by a factor
of 100; so the userspace exit costs are cut by the same factor. If you
have good copyless networking APIs you can cut the cost of copies to
zero (well, to the cost of get_user_pages_fast(), but a kernel solution
needs that too).
Given the choice of having to mitigate or not having the problem
in the first place, guess what I would prefer :)
There is no choice. Exiting from the guest to the kernel to userspace
is prohibitively expensive, you can't do that on every packet.
--
error compiling committee.c: too many arguments to function
--
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
