W dniu 18 maja 2011 01:44 użytkownik Shirley Ma [off-list ref] napisał:

On Wed, 2011-05-18 at 00:58 +0200, Michał Mirosław wrote:

quoted

W dniu 18 maja 2011 00:28 użytkownik Shirley Ma [off-list ref]
napisał:

quoted

On Tue, 2011-05-17 at 23:48 +0200, Michał Mirosław wrote:

quoted

2011/5/17 Shirley Ma [off-list ref]:

quoted

Looks like to use a new flag requires more time/work. I am

thinking

quoted

quoted

quoted

whether we can just use HIGHDMA flag to enable zero-copy in

macvtap

quoted

quoted

to

quoted

avoid the new flag for now since mavctap uses real NICs as lower

device?

Is there any other restriction besides requiring driver to not

recycle

quoted

quoted

the skb? Are there any drivers that recycle TX skbs?

Not more other restrictions, skb clone is OK. pskb_expand_head()

looks

quoted

OK to me from code review.

quoted

Currently there is no drivers recycle TX skbs.

So why do you require the target device to have some flags at all?

We could use macvtap to check lower device HIGHDMA to enable zero-copy,
but I am not sure whether it is sufficient. If it's sufficient then we
don't need to use a new flag here. To be safe, it's better to use a new
flag to enable each device who can pass zero-copy test.

quoted

Do I understand correctly, that this zero-copy feature is about
packets received from VMs?

Yes, packets sent from VMs, and received in local host for TX zero-copy
here.

What is the zero-copy test? On some arches the HIGHDMA is not needed
at all so might be not enabled on anything. It looks like the correct
test would be per-packet check of !illegal_highdma() or maybe
NETIF_F_SG as returned from harmonize_features(). For virtual devices
or other software forwarding this might lead to skb_linearize() in
some cases, but is it that bad?

Best Regards,
Michał Mirosław