Re: TODO list for qemu+KVM networking performance v2

[Rusty Russell <rusty@rustcorp.com.au>]

On Wed, 10 Jun 2009 03:56:31 pm Dor Laor wrote:
> Rusty Russell wrote:
> > The current theoretical hole is that the host suppresses notifications
> > using the VIRTIO_AVAIL_F_NO_NOTIFY flag, but we can get a number of
> > notifications in before it gets to that suppression.  You can use a
> > counter to improve this: you only notify when they're equal, and inc when
> > you notify.  That way you suppress further notifications even if the
> > other side takes ages to wake up. In practice, this shouldn't be played
> > with until we have full aio (or equiv in kernel) for other side: host
> > xmit tends to be too fast at the moment and we get a notification per
> > packet anyway.
>
> Xen ring has the exact optimization for ages. imho we should have it
> too, regardless of aio.
> It reduces #vmexits/spurious wakeups and it is very simple to implement.

But look at number of wakeups received vs notifications sent: I just don't see 
any benefit there at the moment.  As I said, improving the host code might 
change that significantly.

And implementing it the other way is v. v. hard given the nature of interrupts 
(shared and coalesced).

Thanks,
Rusty.