From owner-freebsd-current@FreeBSD.ORG Wed Jan 24 10:34:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C540C16A402 for ; Wed, 24 Jan 2007 10:34:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 77B2B13C471 for ; Wed, 24 Jan 2007 10:34:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so133365wxc for ; Wed, 24 Jan 2007 02:34:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=AgouYRV3Vf4/FYqSVionJ/SdAEw2AGQfVXi55az5PVwMS5qb5MxSjUTSQV/ROJUx9KfAKJX5AGKisNsW7jBD55mMBiYhWwMOHzsKr7mTUVj+cBaqB9MtNwk1O5sV+V5h6mX8GG29CVAohGnw9sG115/hT+L6mNJDopgvqX3Zjeo= Received: by 10.90.119.15 with SMTP id r15mr381541agc.1169634845632; Wed, 24 Jan 2007 02:34:05 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 26sm979342wra.2007.01.24.02.34.02; Wed, 24 Jan 2007 02:34:04 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l0OAZU2A039450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 19:35:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0OAZTC6039449; Wed, 24 Jan 2007 19:35:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 24 Jan 2007 19:35:29 +0900 From: Pyun YongHyeon To: Bill Paul Message-ID: <20070124103529.GC37721@cdnetworks.co.kr> References: <20070122073611.GC29223@cdnetworks.co.kr> <20070124071403.CE9E916A401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070124071403.CE9E916A401@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.ORG Subject: Re: Call for re(4) checksum offload testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 10:34:06 -0000 On Wed, Jan 24, 2007 at 07:14:03AM +0000, Bill Paul wrote: > > Hi, > > > > It seems that some revisions of re(4) hardwares(PCIe variants?) still > > have Tx checksum offload issues. One user reported the issue said > > the attached patch fixed the issue on his box. > > Since there are lots of hardwares supported by re(4) I'd like to know > > whether the attached patch has no other regressions on re(4) hardwares. > > If there are no objections I'll commit it in a week. > > > > Thanks. > > -- > > Regards, > > Pyun YongHyeon > > Unfortunately, your patch will break the rl(4) driver, which uses the > same header file and also uses RL_MIN_FRAMELEN (and which expects it to > be 60). Of course you can easily fix this by making rl(4) and re(4) use > different #defines. It may also be a regression for older 8169 cards. > There's already a workaround for a TX checksum offload problem wth > some of the PCI 8169 cards, which depends on RL_MIN_FRAMELEN being 60. > Changing RL_MIN_FRAMELEN may break the workaround for these chips. > Ah, I missed that. Thank you for pointing out. > I'm very confused as to why the chip botches the TX checksumming in > this case. Unfortunately, most of this confusion stems from the fact > that you didn't specify exactly which chip rev the user with this > problem has, or give a test case to trip the bug. > Sorry. Here is the information I've got from a user who owns problematic hardware. > laptop: Asus a6je > card: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00 > vendor=Realtek Semiconductor > device=RTL8168/8111 PCI-E Gigabit Ethernet NIC > On stock re(4) no TCP connections are available on this hardware. Just type "http://www.gmail.com" on browser is sufficient to reproduce on his hardware. If you want captured traffic I can sent it for you even though it's captured on sending host with re(4). I think you can easily spot which packets checksum were broken as many TCP resends are repeated for a sequence number. > I'm assuming this yet another problem with small IP fragments being > mangled. That being the case, it should be possible to trip the bug > with "ping -s 1473 ." (1473 is 1 byte too large to fit into > a 1500 byte frame, which will cause a 1 byte fragment to be sent.) > I thought I tested this with my sample PCIe cards though, and didn't > see a problem. I'll have to try it again tomorrow. > It seems that the hardware in question does not like extra padded bytes for TCP packets. AFAIK the hardware worked without any paddings for non-TCP packets. I couldn't test UDP case due to lack of hardwares but I guess this paticular chip has a working checksum offload implementation. I could have checked a chip revision for the padding work-around but I can't sure which revisions would break the assumtion so I followed NetBSD approach. I've searched all NetBSD archives for the re(4) checksum offload issues but I've failed to find so I thought their fix really works for most hardwares. AFAIK the originator said that "ping -s 1473" without padding work-around also worked on his system. So I guess it breaks checksum only if it sees extra padded bytes in TCP packet. > In any case, you can't check this patch in as-is. It may fix things > for this one particular NIC, but it will break things for others. > Ok, I'll wait for your results and opinions. Thank you very much for looking this issue! > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= -- Regards, Pyun YongHyeon