Date: Tue, 10 May 2005 10:39:18 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: yongari@rndsoft.co.kr Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Re: tap interface and locally generated packets Message-ID: <4280F1C6.2030009@savvis.net> In-Reply-To: <20050510004847.GA4990@rndsoft.co.kr> References: <20050510004847.GA4990@rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun, > I can't sure but bridge(4) seems to have checksum related issues. > Here is my theory. > > Interface A : H/W checksum offloading supported, Have IP address > Interface B : no H/W checksum offloading, No IP address assigned > Gateway : 192.168.10.1 > > > | Bridge > +---------------------------+ > | | > Interface A Interface B > IP address 192.168.10.5 | > | | > | | > | Gateway | 192.168.10.0/24 > > > If one of client in 192.168.10.0/24 connects to bridged host IP(192.168.10.5) > it would get corrupted checksummed packet. Since the interface selected > in ip_ouput(), interface A, will indicate HWCSUM offloading ip_output > just pass the packet down to the ethernet layer. But in brdige it would > be rerouted to interface B. well, i sort of said the same thing in my previous email to Patrick. > As you noted I think it's not fault of tap(4). It seems that the correct > solution would do S/W checksumming for all bridged interfaces in > ip_output. However it's not easy to know the interface selected in > ip_output is one of bridged interfaces(lack of if_bridge member > in struct ifnet). So I think this is another reason FreeBSD should > import OpenBSD/NetBSD bridge driver. i think we all agree that there is a problem. the problem is: bridge(4) assumes that _all_ interfaces in a cluster have _the_same_ hardware capabilities (checksum offloading). if at least one interface in a cluster has different capabilities then you are going to have a problem. now i'm not sure this assumption if flawed. it is certainly not obvious from the bridge(4) man page and i do not recall seeing this documented anywhere. it is not that hard to use the same type of ethernet cards in one machine. especially when all modern server motherboards ships with two (or more) on-board ethernet cards. Patrick observed one corner case of the problem where one of the interfaces in the bridge happens to be tap(4). in his case other (physical) interface is loaded and turning hardware checksumming off will increase cpu load. my tap(4) patch is a hack, and it only works for ip checksumming. note that some cards can do udp/tcp checksums as well. imo, implementing similar hacks for all ethernet drivers (that do not support hardware checksumming) is wrong. like you said it has to be done at bridge level. if you think that porting OpenBSD/NetBSD bridge driver is a good idea you are welcome to submit the patches. imo, it should be possible to fix this in our current bridge(4) implementation. bridge(4) knows where packet is coming from and going to. it could check hardware capabilities of the destination interface and calculate checksums if needed. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4280F1C6.2030009>