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