From owner-freebsd-current@FreeBSD.ORG Wed Jan 24 07:14:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id CE9E916A401; Wed, 24 Jan 2007 07:14:03 +0000 (UTC) In-Reply-To: <20070122073611.GC29223@cdnetworks.co.kr> from Pyun YongHyeon at "Jan 22, 2007 04:36:11 pm" To: pyunyh@gmail.com Date: Wed, 24 Jan 2007 07:14:03 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070124071403.CE9E916A401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) 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 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 07:14:03 -0000 > 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. 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. 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. 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. -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 =============================================================================