Date: Fri, 9 May 2014 10:47:33 +0900 From: Yonghyeon PYUN <pyunyh@gmail.com> To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: TX Checksum offloading issue with re interfaces Message-ID: <20140509014733.GB3014@michelle.cdnetworks.com> In-Reply-To: <95E18108-E6DD-49EA-90B3-A9F9E5F93D20@lurchi.franken.de> References: <95E18108-E6DD-49EA-90B3-A9F9E5F93D20@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote: > Dear all, > > while testing checksum offloading of UDP packets over IP with IP options, I figured > out that my card > > 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=0 function=0 handle=\_SB_.PCI0.PE1F.LAN2 > dev.re.1.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1734 subdevice=0x1159 class=0x020000 > dev.re.1.%parent: pci13 > dev.re.1.stats: -1 > dev.re.1.int_rx_mod: 65 > > 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... > > I looked at sys/dev/re/if_re.c, but couldn't figure out how to fix it. Any idea? > 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))? The vendor uses the same PCI id for its RTL8168/8111 family chips so dmesg output is necessary to know exact controller revision.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140509014733.GB3014>