On Wed, Sep 15, 2010 at 05:04:12PM +0200, Michael S. Tsirkin wrote:

On Wed, Sep 15, 2010 at 07:52:34AM -0700, Shirley Ma wrote:

quoted

On Wed, 2010-09-15 at 12:10 +0200, Michael S. Tsirkin wrote:

quoted

Another issue is that macvtap can be bound to almost
anything, including e.g. a tap device or a bridge,
which might hang on to skb fragments for unlimited time.
Zero copy TX won't easily work there.
I can imagine either somehow triggering a data copy after the
fact (hard), or detecting such devices and avoiding
zero copy (unfortunate for guest to guest, and drivers
will need tuning).

So far macvtap zero copy patch is limited to lower devices supports high
memory DMA, it doesn't apply to a tap device or a bridge.

Okay. What about macvtap in bridge mode?

In fact, I rechecked: both bridge and loopback have NETIF_F_HIGHDMA set.
So maybe we should check NETIF_F_NETNS_LOCAL ...

macvtap in bridged mode is interesting as well.

quoted

quoted

quoted

 Don't you think once I address vhost_add_used_and_signal update
issue, it is a simple and complete patch for macvtap TX zero copy?

Thanks
Shirley

I like the fact that the patch is simple. Unfortunately
I suspect it'll stop being simple by the time it's complete :) 

I can make a try. :)

Thanks
Shirley