From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:09:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DCC83D2 for ; Mon, 12 May 2014 11:09:22 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3C412876 for ; Mon, 12 May 2014 11:09:21 +0000 (UTC) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C0B481C10491E; Mon, 12 May 2014 13:09:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: TX Checksum offloading issue with re interfaces From: Michael Tuexen In-Reply-To: <20140512043837.GA1364@michelle.cdnetworks.com> Date: Mon, 12 May 2014 13:09:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DCF8CB0-220E-4BC4-AF71-E84CCDA88315@lurchi.franken.de> References: <95E18108-E6DD-49EA-90B3-A9F9E5F93D20@lurchi.franken.de> <20140509014733.GB3014@michelle.cdnetworks.com> <20140512043837.GA1364@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:09:22 -0000 On 12 May 2014, at 06:38, Yonghyeon PYUN wrote: > On Fri, May 09, 2014 at 12:33:24PM +0200, Michael Tuexen wrote: >> On 09 May 2014, at 03:47, Yonghyeon PYUN wrote: >>=20 >>> On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote: >>>> Dear all, >>>>=20 >>>> while testing checksum offloading of UDP packets over IP with IP = options, I figured >>>> out that my card >>>>=20 >>>> dev.re.1.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit = Ethernet >>>> dev.re.1.%driver: re >>>> dev.re.1.%location: slot=3D0 function=3D0 = handle=3D\_SB_.PCI0.PE1F.LAN2 >>>> dev.re.1.%pnpinfo: vendor=3D0x10ec device=3D0x8168 subvendor=3D0x1734= subdevice=3D0x1159 class=3D0x020000 >>>> dev.re.1.%parent: pci13 >>>> dev.re.1.stats: -1 >>>> dev.re.1.int_rx_mod: 65 >>>>=20 >>>> computes the UDP checksum, but stores it in the packet at the = place, where it would be, >>>> if there are no IP options. So it corrupts the options in the = packet... >>>>=20 >>>> I looked at sys/dev/re/if_re.c, but couldn't figure out how to fix = it. Any idea? >>>>=20 >>>=20 >>> re(4) has a very long history on its broken TX checksum offloading. >>> So re(4) has many workarounds for known issues on several variants. >>> re(4) controllers support TX IPv4/TCP/UDP checksum offloading. For >>> 8168C/8168CP, TX IPv4 checksum offloading was disabled due to >>> generation of corrupted frames. >>> Could you show me the dmesg output(only re(4)/rgephy(4))? >>=20 >>> The vendor uses the same PCI id for its RTL8168/8111 family chips >>> so dmesg output is necessary to know exact controller revision. >> Sure (re1 was used during the test): >> re0: port = 0x8000-0x80ff mem 0xf6104000-0xf6104fff,0xf6100000-0xf6103fff irq 16 at = device 0.0 on pci12 >> re0: Using 1 MSI-X message >> re0: Chip rev. 0x28800000 >> re0: MAC rev. 0x00200000 >> miibus0: on re0 >> rgephy0: PHY 1 on miibus0 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> re0: Ethernet address: 00:19:99:85:31:d9 >> re1: port = 0x9000-0x90ff mem 0xf5c20000-0xf5c20fff,0xf6200000-0xf620ffff irq 17 at = device 0.0 on pci13 >> re1: Using 1 MSI-X message >> re1: Chip rev. 0x3c800000 >> re1: MAC rev. 0x00300000 >> miibus1: on re1 >> rgephy1: PHY 1 on = miibus1 >> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> re1: Ethernet address: 00:19:99:7e:c7:46 >>=20 > It seems you have two variants. You are right, I didn't know. Both are on-board interfaces... > re0 is RTL8168DP and re1 is RTL8168CP. Do you see the issue on > both controllers? I guess you may see the issue on re1 only since > you've posted dev.re.1 output. I've attached a diff which may It wasn't intentionally, but by accident, based on the addresses I was using. However, I now tested both interfaces and re0 works without any patch, but re1 needs your patch. > address the issue on re1 interface. If you see the issue on re0, > I have to change the diff to include RTL8168D. Your patch looks good. Please go ahead and commit it. Thanks for your help! Best regards Michael >