Linux Ethernet Bridging - Apr 2007 - [Bridge] Re: [PATCH] TSO fix in br_dev_queue_push_xmit

From: Vlad Drukker <vlad@storewiz.com>
Date: Wed, 21 Sep 2005 15:53:06 +0300
> I see you all agree to apply :)
> 
> Stephen, repost of this patch to proper places below.
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.

On Wed, 21 Sep 2005 15:53:06 +0300
Vlad Drukker <vlad@storewiz.com> wrote:
> 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? 
> 
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.

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? 


Signed-off-by : Vlad Drukker <vlad@storewiz.com>
---
 net/bridge/br_forward.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -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