On Fri, 2008-07-25 at 10:30 +1000, Rusty Russell wrote:
> On Friday 25 July 2008 09:22:53 Dor Laor wrote:
> > Mark McLoughlin wrote:
> > > vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
> > > qemu_del_timer(n->tx_timer);
> > > n->tx_timer_active = 0;
> >
> > As stated by newer messages, we should handle the first tx notification
> > if the timer wasn't active to shorten latency.
> > Cheers, Dor
>
> Here's what lguest does at the moment. Basically, we cut the timeout a tiny
> bit each time, until we get *fewer* packets than last time. Then we bump it
> up again.
>
> Rough, but seems to work (it should be a per-device var of course, not a
> static).
>
> @@ -921,6 +922,7 @@ static void handle_net_output(int fd, st
> unsigned int head, out, in, num = 0;
> int len;
> struct iovec iov[vq->vring.num];
> + static int last_timeout_num;
>
> if (!timeout)
> net_xmit_notify++;
> @@ -941,6 +943,14 @@ static void handle_net_output(int fd, st
> /* Block further kicks and set up a timer if we saw anything. */
> if (!timeout && num)
> block_vq(vq);
> +
> + if (timeout) {
> + if (num < last_timeout_num)
> + timeout_usec += 10;
> + else if (timeout_usec > 1)
> + timeout_usec--;
> + last_timeout_num = num;
> + }
Yeah, I gave this a try in kvm and in the host->guest case the timeout
just grew and grew. In the guest->host case, it did stabilise at around
50us with high throughput.
Basically, I think in the host->guest case the number of buffers was
very variable so the timeout would get bumped by 10, reduced by a small
amount, bumped by 10, reduced by a small amount, ...
But, I agree the general principal seems about right; just needs some
tweaking.
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
