From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Mason Subject: Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming Date: Thu, 19 May 2005 18:23:31 -0500 Message-ID: <200505191823.31777.jdmason@us.ibm.com> References: <20050518235329.GA17946@us.ibm.com> <20050519133333.07a992e6@dxpl.pdx.osdl.net> <20050519.144800.71090042.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: shemminger@osdl.org, netdev@oss.sgi.com Return-path: To: "David S. Miller" In-Reply-To: <20050519.144800.71090042.davem@davemloft.net> Content-Disposition: inline Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org On Thursday 19 May 2005 04:48 pm, David S. Miller wrote: > From: Stephen Hemminger > Date: Thu, 19 May 2005 13:33:33 -0700 > > > The bridge doesn't need locking, or checksumming and can allow highdma > > buffers; all of which are handled by net/core/dev.c if needed. > > As discuesed elsewhere, this handling by net/core/dev.c makes > TCP sending much more expensive when it is actually used. > > Furthermore, I just found another hole in the idea to propagate > sub-device features into the bridge device. > > If one device has NETIF_F_HW_CSUM and the others have NETIF_F_IP_CSUM, > both bits will be set in the bridge device and things will entirely > break. The two checksumming on output schemes are different, and all > of the stack assumes that only one of these two bits are set. > > I have such a setup in two of my sparc64 systems (sunhme does > NETIF_F_HW_CSUM, and tg3 does NETIF_F_IP_CSUM). Also, my PowerMAC G5 > has this problem too, the onboard sungem chip does NETIF_F_HW_CSUM and > the tg3 I have in a PCI slot does NETIF_F_IP_CSUM. So given that > half the machines I have powered on right here could trigger the > problem, it's far from theoretical :-) > > There are multiple spots that want to do this kind of stuff > now (bridging, vlan, bonding) which indicates that some sort > of common infrastructure should be written to implement this > kind of stuff. Since NETIF_F_HW_CSUM encompasses NETIF_F_IP_CSUM, perhaps it would be better to use the latter until such time as a new infrastructure can be implimented. Thanks, Jon