On Wed, 2011-02-02 at 17:47 +0200, Michael S. Tsirkin wrote: > On Wed, Feb 02, 2011 at 07:39:45AM -0800, Shirley Ma wrote: > > On Wed, 2011-02-02 at 12:48 +0200, Michael S. Tsirkin wrote: > > > Yes, I think doing this in the host is much simpler, > > > just send an interrupt after there's a decent amount > > > of space in the queue. > > > > > > Having said that the simple heuristic that I coded > > > might be a bit too simple. > > > > >From the debugging out what I have seen so far (a single small > message > > TCP_STEAM test), I think the right approach is to patch both guest > and > > vhost. > > One problem is slowing down the guest helps here. > So there's a chance that just by adding complexity > in guest driver we get a small improvement :( > > We can't rely on a patched guest anyway, so > I think it is best to test guest and host changes separately. > > And I do agree something needs to be done in guest too, > for example when vqs share an interrupt, we > might invoke a callback when we see vq is not empty > even though it's not requested. Probably should > check interrupts enabled here? Yes, I modified xmit callback something like below: static void skb_xmit_done(struct virtqueue *svq) { struct virtnet_info *vi = svq->vdev->priv; /* Suppress further interrupts. */ virtqueue_disable_cb(svq); /* We were probably waiting for more output buffers. */ if (netif_queue_stopped(vi->dev)) { free_old_xmit_skbs(vi); if (virtqueue_free_size(svq) <= svq->vring.num / 2) { virtqueue_enable_cb(svq); return; } } netif_wake_queue(vi->dev); } > > The problem I have found is a regression for single small > > message TCP_STEAM test. Old kernel works well for TCP_STREAM, only > new > > kernel has problem. > > Likely new kernel is faster :) > > For Steven's problem, it's multiple stream TCP_RR issues, the old > guest > > doesn't perform well, so does new guest kernel. We tested reducing > vhost > > signaling patch before, it didn't help the performance at all. > > > > Thanks > > Shirley > > Yes, it seems unrelated to tx interrupts. The issue is more likely related to latency. Do you have anything in mind on how to reduce vhost latency? Thanks Shirley -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html