Date: Wed, 24 Jan 2007 19:35:29 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Call for re(4) checksum offload testers. Message-ID: <20070124103529.GC37721@cdnetworks.co.kr> In-Reply-To: <20070124071403.CE9E916A401@hub.freebsd.org> References: <20070122073611.GC29223@cdnetworks.co.kr> <20070124071403.CE9E916A401@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <somehost>." (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 > ============================================================================= > <adamw> you're just BEGGING to face the moose > ============================================================================= -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070124103529.GC37721>