Date: Tue, 10 May 2005 17:03:39 -0700 From: Julian Elischer <julian@elischer.org> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: yongari@rndsoft.co.kr Subject: Re: [PATCH] Re: tap interface and locally generated packets Message-ID: <42814BDB.6000008@elischer.org> In-Reply-To: <4280F1C6.2030009@savvis.net> References: <20050510004847.GA4990@rndsoft.co.kr> <4280F1C6.2030009@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote: > 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 the negraph bridge could also be modified to do this.. > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42814BDB.6000008>