On Thursday 19 May 2005 04:48 pm, David S. Miller wrote:
> From: Stephen Hemminger <shemminger@xxxxxxxx>
> 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
|