[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1300321214.3255.40.camel@localhost.localdomain>
Date: Wed, 16 Mar 2011 17:20:14 -0700
From: Shirley Ma <mashirle@...ibm.com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
Tom Lendacky <tahm@...ux.vnet.ibm.com>,
Krishna Kumar2 <krkumar2@...ibm.com>,
David Miller <davem@...emloft.net>, kvm@...r.kernel.org,
netdev@...r.kernel.org, steved@...ibm.com
Subject: Re: TX from KVM guest virtio_net to vhost issues
On Fri, 2011-03-11 at 16:49 +1030, Rusty Russell wrote:
> But if one side outruns the other, it does a lot of unnecessary work
> notifying/interrupting it over and over again before the host/guest
> gets
> a chance to shut notifications/interrupts off. Hence the last_used
> publishing patch (Xen does this right, I screwed it up).
>
> Long weekend here, and I'm otherwise committed. But if noone has
> cleaned up that patch by early next week, I'll try to do so and see if
> we can make a real difference.
This patch doesn't seem to help guest TX queue overrun. I couldn't find
any other reason why the TX queue overrun, even I increased guest send
queue ring size to 1K, it didn't help at all. I sent out a dropping
packet approach for guest to avoid this for you to review. Small message
size performance has been dramatically increased with a few packet
drops. Most of the workload doesn't invoke the TX queue overrun, so I
don't see any regressions.
With this patch, vhost side doesn't need to signal guest on TX path,
however for previous guest, we still need vhost to signal guest.
Please let me know if you have any other ideas to debug what causes
guest TX overrun.
Thanks
Shirley
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists