From owner-freebsd-net@FreeBSD.ORG Wed May 11 00:03:43 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 961D516A4CE for ; Wed, 11 May 2005 00:03:43 +0000 (GMT) Received: from mail.iinet.net.au (mail-04.iinet.net.au [203.59.3.36]) by mx1.FreeBSD.org (Postfix) with SMTP id 241B443D5F for ; Wed, 11 May 2005 00:03:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: (qmail 27604 invoked from network); 11 May 2005 00:03:41 -0000 Received: from unknown (HELO ?10.1.1.2?) (203.59.240.134) by mail.iinet.net.au with SMTP; 11 May 2005 00:03:41 -0000 Message-ID: <42814BDB.6000008@elischer.org> Date: Tue, 10 May 2005 17:03:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maksim Yevmenkin References: <20050510004847.GA4990@rndsoft.co.kr> <4280F1C6.2030009@savvis.net> In-Reply-To: <4280F1C6.2030009@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: yongari@rndsoft.co.kr Subject: Re: [PATCH] Re: tap interface and locally generated packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 00:03:43 -0000 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"