Re: [PATCH 0/6] Kill off the virtio_net tx mitigation timer

[Mark McLoughlin <markmc@redhat.com>]

On Sun, 2008-11-02 at 11:48 +0200, Avi Kivity wrote:
> Mark McLoughlin wrote:
> > Hey,
> >
> > The main patch in this series is 5/6 - it just kills off the
> > virtio_net tx mitigation timer and does all the tx I/O in the
> > I/O thread.
> >
> >   
> 
> What will it do to small packet, multi-flow loads (simulated by ping -f 
> -l 30 $external)?

It should improve the latency - the packets will be flushed more quickly
than the 150us timeout without blocking the guest.

I've a crappy external network setup locally atm, so the improvement for
guest->external gets lost in the noise there, but it does show up with
that workload and guest->host.

> Where does the benefit come from?

There are two things going on here, I think.

First is that the timer affects latency, removing the timeout helps
that.

Second is that currently when we fill up the ring we block the guest
vcpu and flush. Thus, while we're copying a entire ring full of packets
that guest isn't making progress. Doing the copying in the I/O thread
helps there.

Note - the only net I/O we currently do in the vcpu thread at the moment
is when the guest is saturating the link. Any other timer, all the I/O
is done in the I/O thread by virtue of the timer.

> Is the overhead of managing the timer too high, or does it fire too
> late and so we sleep?  If the latter, can we tune it dynamically?
> 
> For example, if the guest sees it is making a lot of progress without 
> the host catching up (waiting on the tx timer), it can 
> kick_I_really_mean_this_now(), to get the host to notice.

It does that already - if the ring fills up the guests forces a kick
which causes the host to flush the ring in the vcpu thread.

Cheers,
Mark.