On 12/02/2015 08:36 PM, Michael S. Tsirkin wrote:

On Wed, Dec 02, 2015 at 01:04:03PM +0800, Jason Wang wrote:

quoted

On 12/01/2015 10:43 PM, Michael S. Tsirkin wrote:

quoted

On Tue, Dec 01, 2015 at 01:17:49PM +0800, Jason Wang wrote:

quoted

On 11/30/2015 06:44 PM, Michael S. Tsirkin wrote:

quoted

On Wed, Nov 25, 2015 at 03:11:29PM +0800, Jason Wang wrote:

quoted

quoted

This patch tries to poll for new added tx buffer or socket receive
queue for a while at the end of tx/rx processing. The maximum time
spent on polling were specified through a new kind of vring ioctl.

Signed-off-by: Jason Wang <jasowang@redhat.com>

One further enhancement would be to actually poll
the underlying device. This should be reasonably
straight-forward with macvtap (especially in the
passthrough mode).

Yes, it is. I have some patches to do this by replacing
skb_queue_empty() with sk_busy_loop() but for tap.

We probably don't want to do this unconditionally, though.

quoted

Tests does not show
any improvement but some regression.

Did you add code to call sk_mark_napi_id on tap then?
sk_busy_loop won't do anything useful without.

Yes I did. Probably something wrong elsewhere.

Is this for guest-to-guest?

Nope. Like you said below, since it requires NAPI so it was external
host to guest.

 the patch to do napi
for tap is still not upstream due to minor performance
regression.  Want me to repost it?

Sure, I've played this a little bit in the past too.

quoted

quoted

quoted

 Maybe it's better to test macvtap.

Same thing ...

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html