TSO fix in br_dev_queue_push_xmit

Hi,

I see you all agree to apply :)

Stephen, repost of this patch to proper places below.

Thank you Henrik for clarification of bridge standard. However, silent drop of locally generated packets on 99% idle carrier grade machine looks like a hardware problem.

David, don't you think that having software packet drop counters is a bad idea? I thought, software drop counters are there to help identify hardware problems or lack of resources. In this case, tcp stack produced output that just gone. TSO is there over years and no one even noticed given TSO/bridge conflict mainly because there is no stats. (IMHO) Let's blame standards, right?

---
 net/bridge/br_forward.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

@@ -31,7 +31,8 @@ static inline int should_deliver(const s
 
 int br_dev_queue_push_xmit(struct sk_buff *skb)
 {
-       if (skb->len > skb->dev->mtu)
+       /* drop mtu oversized packets except tso */
+       if (skb->len > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
                kfree_skb(skb);
        else {
 #ifdef CONFIG_BRIDGE_NETFILTER

Patch is fine.

Putting in a counter would be good, but there is no good structure to put it in. The bridge device (br0) counters make sense for locally generated packets, the network devices (ethX) forwarding packets are under control of the other device driver.

There is a whole bridge MIB defined in the standard, but adding it would be a lot of work, and not sure if anyone would care.

From: Vlad Drukker <[email protected]>
Date: Wed, 21 Sep 2005 15:53:06 +0300

Applied, but please learn how to send patches properly next time. Your email client mangled all the tab characters into spaces, so I had to add the patch by hand.

I'm sure you can convince Evolution to not do that, or simply use attachments.

Thanks.