From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark McLoughlin <markmc@redhat.com>
Subject: Re: [PATCH 2/9] kvm: qemu: Fix virtio_net tx timer
Date: Sat, 26 Jul 2008 13:08:56 +0100
Message-ID: <1217074136.3943.5.camel@muff>
References: <1216899979-32532-1-git-send-email-markmc@redhat.com>
	 <1216899979-32532-2-git-send-email-markmc@redhat.com>
	 <1216899979-32532-3-git-send-email-markmc@redhat.com>
	 <488AF2EC.5050301@qumranet.com>
Reply-To: Mark McLoughlin <markmc@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>,
	Rusty Russell <rusty@rustcorp.com.au>
To: Avi Kivity <avi@qumranet.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([66.187.233.31]:44648 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750870AbYGZMJP (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 26 Jul 2008 08:09:15 -0400
In-Reply-To: <488AF2EC.5050301@qumranet.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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 <markmc@redhat.com>
> > ---
> >  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.