TX Checksum offloading issue with re interfaces

Michael Tuexen Michael.Tuexen at lurchi.franken.de
Tue May 13 07:01:53 UTC 2014


On 13 May 2014, at 07:23, Yonghyeon PYUN <pyunyh at 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 at gmail.com> wrote:
>> 
>>> On Fri, May 09, 2014 at 12:33:24PM +0200, Michael Tuexen wrote:
>>>> On 09 May 2014, at 03:47, Yonghyeon PYUN <pyunyh at gmail.com> wrote:
>>>> 
>>>>> 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.
>>>> 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
>>>> 
>>> 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!
> 
> Fixed in r265943.
Great!
> Thanks for testing!
Thanks for fixing the issue.

Best regards
Michael
> 



More information about the freebsd-net mailing list