Message ID | 1278924474.7719.14.camel@localhost.localdomain |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
On Monday 12 July 2010, Shirley Ma wrote: > > Return err when macvlan dropps the packet. Can you be more specific why you think this is the right idea? As far as I can tell, this will return '1' to user space for a dropped packet (NET_XMIT_DROP) or another positive return value. While this might be nice for a user application to know, neither does qemu check for this nor does it match the read(2) documentation. I fear if we want congestion control to improve, we need to do it differently. Arnd -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Arnd, I am working on macvtap zero-copy patch. I found that the packet was silently dropped and packet out of order when using zero-copy. That was a reason I submitted this patch to switch to copy mode when that happens. I think I might need more time to debug why first. Thanks Shirley -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 2b4d59b..36d52b5 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -492,9 +492,11 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, rcu_read_lock_bh(); vlan = rcu_dereference(q->vlan); - if (vlan) - macvlan_start_xmit(skb, vlan->dev); - else + if (vlan) { + err = macvlan_start_xmit(skb, vlan->dev); + if (err) + count = err; + } else kfree_skb(skb); rcu_read_unlock_bh();
Return err when macvlan dropps the packet. Signed-off-by: Shirley Ma <xma@us.ibm.com> --- drivers/net/macvtap.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html