Sure, linux/virtio_ring.h:
/* The Host uses this in used->flags to advise the Guest: don't kick me when
* you add a buffer. It's unreliable, so it's simply an optimization. Guest
* will still kick if it's out of buffers. */
#define VRING_USED_F_NO_NOTIFY 1
/* The Guest uses this in avail->flags to advise the Host: don't interrupt me
* when you consume a buffer. It's unreliable, so it's simply an
* optimization. */
#define VRING_AVAIL_F_NO_INTERRUPT 1
No, you misunderstand; this is not a performance issue. On xmit, the driver
cleans up any old used packets before trying to send anyway. So it doesn't
care when xmit packets are used, and suppresses the 'used' interrupt on the
xmit virtqueue. Only if the xmit ring is full does it enable the xmit-used
notification. This is optimal.
The issue is that we *do* actually care when xmit packets are used: we're
supposed to free them in a timely manner and if the packet flow stops, we
don't. By always sending a used interrupt when *all* packets are used, we
would cover this case quite nicely without impacting the normal case of
packet flow.
Right, this would be a threshold that the host would set, approx. "when you've
put this many packets in the xmit ring, tell me" (the opposite direction of
the discussion above). Currently we will kick the host on the first packet,
and qemu will suppress the notifications based on some timer and we'll notify
it anyway if the ring fills (which is suboptimal). With this technique the
host could double the threshold up to some maximum percentage of the ring.
While I like the Xen scheme, we can do the same thing from within the guest
with the existing scheme using an internal threshold. We are always allowed
to send "spurious" notifications to the host, so it can't break anything.
Added to TODO.
Thanks,
Rusty.
--
