From owner-freebsd-net@FreeBSD.ORG Tue May 10 17:39:37 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 D7B2916A4CE for ; Tue, 10 May 2005 17:39:37 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8129D43D88 for ; Tue, 10 May 2005 17:39:37 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id E0F883BEA3; Tue, 10 May 2005 12:39:36 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19975-01-61; Tue, 10 May 2005 12:39:36 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id AA6423BE29; Tue, 10 May 2005 12:39:36 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 12:39:27 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 12:39:22 -0500 Message-ID: <4280F1C6.2030009@savvis.net> Date: Tue, 10 May 2005 10:39:18 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yongari@rndsoft.co.kr References: <20050510004847.GA4990@rndsoft.co.kr> In-Reply-To: <20050510004847.GA4990@rndsoft.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2005 17:39:23.0010 (UTC) FILETIME=[33EDDE20:01C55587] X-Virus-Scanned: amavisd-new at savvis.net cc: freebsd-net@freebsd.org 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: Tue, 10 May 2005 17:39:38 -0000 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