TX Checksum offloading issue with re interfaces

[Yonghyeon PYUN]

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.