On Thu, 2011-05-26 at 11:49 +0300, Michael S. Tsirkin wrote:

On Wed, May 25, 2011 at 03:49:40PM -0700, Shirley Ma wrote:

quoted

On Fri, 2011-05-20 at 02:41 +0300, Michael S. Tsirkin wrote:

quoted

So the requirements are
- data must be released in a timely fashion (e.g. unlike

virtio-net

quoted

quoted

  tun or bridge)

The current patch doesn't enable tun zero-copy. tun will copy data

It's

quoted

not an issue now.
We can disallow macvtap attach to bridge when
zero-copy is enabled.

Attach macvtap to a tun device though. Or e.g. veth device ...
So there should be so generic way to disable zerocopy.
It can either be a whitelist or a blacklist.

quoted

quoted

- SG support
- HIGHDMA support (on arches where this makes sense)

This can be checked by device flags.

OK, but pls note that SG can get turned off dynamically.

quoted

quoted

- no filtering based on data (data is mapped in guest)

quoted

- on fast path no calls to skb_copy, skb_clone, pskb_copy,
  pskb_expand_head as these are slow

Any calls to skb_copy, skb_clone, pskb_copy, pskb_expand_head will

do a

quoted

copy. The performance should be the same as none zero-copy case

before.

I'm guessing a copy is cheaper than get_user_pages+copy+put_page.
But maybe not by much. Care checking that?

That's I have done already. Patch is going out for review.

quoted

I have done/tested the patch V6, will send it out for review

tomorrow.

quoted

I am looking at where there are some cases, skb remains the same for
filtering.

To reliably filter on data I think we'll need to copy it first,
otherwise
guest can change it. Most filters only look at the header though.

quoted

quoted

First 2 requirements are a must, all other requirements
are just dependencies to make sure zero copy will be faster
than non zero copy.
Using a new feature bit is probably the simplest approach to
this. macvtap on top of most physical NICs most likely works
correctly so it seems a bit more work than it needs to be,
but it's also the safest one I think ... 

For "macvtap/vhost zero-copy" we can use SG & HIGHDMA to enable it,

it

quoted

looks safe to me once patching skb_copy, skb_clone, pskb_copy,
pskb_expand_head.

To extend zero-copy in other usages, we can have a new feature bit
later.

Is that reasonable?

Thanks
Shirley

Is the problem is extra work needed to extend feature bits?

There is no problem to use it, Mahesh is working on this patch. I just
want to remove macvtap/vhost zero-copy patch dependency.

Thanks
Shirley