On Sat, 2008-07-26 at 12:48 +0300, Avi Kivity wrote: > Mark McLoughlin wrote: > > The current virtio_net tx timer is 2ns, which doesn't > > make any sense. Set it to a more reasonable 150us > > instead. > > > > Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]> > > --- > > qemu/hw/virtio-net.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c > > index 2e57e5a..31867f1 100644 > > --- a/qemu/hw/virtio-net.c > > +++ b/qemu/hw/virtio-net.c > > @@ -26,7 +26,7 @@ > > #define VIRTIO_NET_F_MAC 5 > > #define VIRTIO_NET_F_GS0 6 > > > > -#define TX_TIMER_INTERVAL (1000 / 500) > > +#define TX_TIMER_INTERVAL (150000) /* 150 us */ > > > > Ouch.
Well, not so much - and I should have explained why. Even though virtio-net is requesting a 2ns tx timer, it actually gets limited to MIN_TIMER_REARM_US which is currently 250us. However, even though the timer itself will only fire after 250us, expire_time is only set to +2ns, so we'll get the timeout callback next time qemu_run_timers() is called from the mainloop. I think this might account for a lot of the jitter in the throughput numbers - the effective tx window size is anywhere between 2ns and 250us depending on e.g. whether there is rx data available on the tap fd. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
