Re: r8169 Driver - Poor Network Performance Since Kernel 4.19

[Heiner Kallweit <hkallweit1@gmail.com>]

Hi David,

On 14.02.2019 03:45, David Chang wrote:
> Hi Heiner,
> 
> On Feb 05, 2019 at 19:50:30 +0100, Heiner Kallweit wrote:
>> Hi David,
>>
>> meanwhile there's the following bug report matching what reported.
>> It's even the same chip version (RTL8168h).
>> https://bugzilla.redhat.com/show_bug.cgi?id=1671958
>>
>> Symptom there is also a significant number of rx_missed packets.
>> Could you try what I mentioned there last:
>> Try building a kernel with the call to rtl_hw_aspm_clkreq_enable(tp, true) at the
>> end of rtl_hw_start_8168h_1() being disabled.
> 
> After disabled the aspm function that you mentioned, we finally got the
> positive testing result. And the rx_missed error was gone. If without
> the patch, the receive side get back to bad performance.
> 
Good to know, thanks. I also checked with Realtek, they confirmed that their Windows
driver uses some heuristics to disable ASPM under high load. So it seems like there
is some hw issue. Open so far is whether this affects certain chip versions only.
Let's see whether they can provide more information.
Disabling ASPM in general would hurt notebook users because based on some past
measurements we know ASPM can significantly save energy.

> kernel: r8169: loading out-of-tree module taints kernel.
> kernel: r8169: module verification failed: signature and/or required key missing - tainting kernel
> kernel: libphy: r8169: probed
> kernel: r8169 0000:01:00.0 eth0: RTL8168h/8111h, ec:8e:b5:5a:2c:f5, XID 54100880, IRQ 128
> kernel: r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> kernel: r8169 0000:01:00.0 enp1s0: renamed from eth0
> kernel: Generic PHY r8169-100:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
> kernel: r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control off
> 
> NIC statistics:
>      tx_packets: 1653804
>      rx_packets: 1555966
>      tx_errors: 0
>      rx_errors: 0
>      rx_missed: 0
>      align_errors: 0
>      tx_single_collisions: 0
>      tx_multi_collisions: 0
>      unicast: 1555884
>      broadcast: 78
>      multicast: 4
>      tx_aborted: 0
>      tx_underrun: 0
> 
> iperf receive:
> -----------------------------------------------------------
> Server listening on 5201
> -----------------------------------------------------------
> Accepted connection from 10.x.x.x, port 55516
> [  5] local 10.x.x.x port 5201 connected to 10.x.x.x port 58172
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec   108 MBytes   906 Mbits/sec
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec
> [  5]   2.00-3.00   sec   112 MBytes   940 Mbits/sec
> [  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec
> [  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec
> [  5]   5.00-6.00   sec   112 MBytes   942 Mbits/sec
> [  5]   6.00-7.00   sec   112 MBytes   939 Mbits/sec
> [  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec
> [  5]   8.00-9.00   sec   112 MBytes   938 Mbits/sec
> [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec
> [  5]  10.00-11.00  sec   112 MBytes   941 Mbits/sec
> [...]
> [  5]  50.00-51.00  sec   112 MBytes   941 Mbits/sec
> [  5]  51.00-52.00  sec   112 MBytes   941 Mbits/sec
> [  5]  52.00-53.00  sec   112 MBytes   942 Mbits/sec
> [  5]  53.00-54.00  sec   112 MBytes   941 Mbits/sec
> [  5]  54.00-55.00  sec   111 MBytes   934 Mbits/sec
> [  5]  55.00-56.00  sec   112 MBytes   942 Mbits/sec
> [  5]  56.00-57.00  sec   112 MBytes   937 Mbits/sec
> [  5]  57.00-58.00  sec   112 MBytes   941 Mbits/sec
> [  5]  58.00-59.00  sec   111 MBytes   932 Mbits/sec
> [  5]  59.00-60.00  sec   112 MBytes   942 Mbits/sec
> [  5]  60.00-60.04  sec  4.06 MBytes   939 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-60.04  sec  6.57 GBytes   940 Mbits/sec                  receiver
> 
> regards,
> David
> 
Heiner