Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9

[Birger Koblitz]

Hi Andrew,

thanks a lot for the explanation of the USB-IRQ handling, that was very 
valuable for my understanding!
On 30/04/2026 4:19 pm, Andrew Lunn wrote:
> > Also, I only see the issue on slow 5GBit USB-C connections, sometimes with
> > the RTL8157, basically every time with the RTL8159, and so far never on a
> > 20GBit USB-C connection, so the mitigation is probably some kind of
> > interrupt coalescing.
>
> Do you notice any latency changes with this setting in place? Or CPU load.
>
> ping can be a good measure for latency.
I do not see any differences in latency. I am using 2 desktop machines 
for testing:
Machine 1: 6-core, 20GBit USB-C, RTL8159, Completely idle desktop
Machine 2: 8-core, AQC107 on PCIe5x, Desktop with dev-tools and Browser

All measurements for CPU-load and timing are done on Machine 1, which 
runs the iperf3-client and ping against Machine 2. There is a direct 
10GBit CAT6 link without any switch in between the RTL8159 and AQC107.

Ping times, WITH mitigation CODE (saying it disables mitigation):
--- 192.168.3.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 101342ms
rtt min/avg/max/mdev = 0.161/0.411/1.267/0.231 ms

Ping times, WITHOUT mitigation-CODE (saying it disabled mitigation):
--- 192.168.3.1 ping statistics ---
150 packets transmitted, 150 received, 0% packet loss, time 152451ms
rtt min/avg/max/mdev = 0.165/0.388/1.048/0.236 ms

Results are identical within statistical errors.

However, there is a big difference in CPU-load when running iperf3, 
especially with multiple threads:

WITH the CODE saying it disables IRQ mitigation:
$ iperf3 -c 192.168.3.1
[  5] 0.00-10.00  sec  10.3 GBytes  8.83 Gbits/sec
CPU: iperf3 22.5% ksoftirqd 16.6%

$ iperf3 -c 192.168.3.1 -P4
[SUM]   0.00-10.00  sec  9.36 GBytes  8.04 Gbits/sec
perf3: 19.3% ksoftirqd 96.7%


WITHOUT the CODE saying it disabled IRQ mitigation:
[  5]   0.00-10.00  sec  10.3 GBytes  8.87 Gbits/sec
CPU: perf3 19.7% ksoftirqd 12.5%

$ iperf3 -c 192.168.3.1 -P4
[SUM]   0.00-10.00  sec  10.3 GBytes  8.81 Gbits/sec
CPU: iperf3 22.0% ksoftirqd 46.5%

> If this is interrupt coalescing, it normally means don't interrupt as
> soon as one packet has been received. Delay the interrupt, so there
> are likely to be more packets in the receive queue. The cost of the
> interrupt handling is then spread over a number of packets.
>
> If this register setting is disabling coalescing, you should see the
> latency go down, but the CPU load go up.
I see the latency staying the same, but the CPU load goes up 
considerably when these register settings are done.

> If you are getting interrupts after the device has been disabled, i
> guess it is because the timer for a delayed interrupt is not cancelled
> by the firmware. If so you might be able to work around this firmware
> bug. Disable the receiver, sleep for 10ms but keep processing
> interrupts, and then continue with the tear down.
My undestanding from the first email by Michal is that the behavior with 
the ESHUTOWN is actually harmless and has been seen in the driver 
already for the RTL8153.

So, my suggestion is I drop this part of the patch-series and remove the 
IRQ-mitigation code that says it disables the IRQ mitigation as 
performance is higher without that code. The issue with ESHUTDOWN in the 
URB handler is a mostly unrelated issue that is probably harmless and 
can be solved separately.

Birger