Date: Tue, 13 May 2014 09:01:48 +0200 From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: pyunyh@gmail.com Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: TX Checksum offloading issue with re interfaces Message-ID: <256D7D52-A58A-43D0-A77F-A46D523B2D5A@lurchi.franken.de> In-Reply-To: <20140513052319.GB1419@michelle.cdnetworks.com> References: <95E18108-E6DD-49EA-90B3-A9F9E5F93D20@lurchi.franken.de> <20140509014733.GB3014@michelle.cdnetworks.com> <AB8FC94E-E93E-4CBB-94C6-4E54DFA1DF2D@lurchi.franken.de> <20140512043837.GA1364@michelle.cdnetworks.com> <4DCF8CB0-220E-4BC4-AF71-E84CCDA88315@lurchi.franken.de> <20140513052319.GB1419@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 May 2014, at 07:23, Yonghyeon PYUN <pyunyh@gmail.com> wrote: > On Mon, May 12, 2014 at 01:09:18PM +0200, Michael Tuexen wrote: >> On 12 May 2014, at 06:38, Yonghyeon PYUN <pyunyh@gmail.com> wrote: >>=20 >>> On Fri, May 09, 2014 at 12:33:24PM +0200, Michael Tuexen wrote: >>>> On 09 May 2014, at 03:47, Yonghyeon PYUN <pyunyh@gmail.com> 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: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> = 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: <MII bus> on re0 >>>> rgephy0: <RTL8251 1000BASE-T media interface> 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: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> = 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: <MII bus> on re1 >>>> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> 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! >=20 > Fixed in r265943. Great! > Thanks for testing! Thanks for fixing the issue. Best regards Michael >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?256D7D52-A58A-43D0-A77F-A46D523B2D5A>