![]() ![]() ![]() |
|
Interesting - and you're on PPPoE delivered service right? -
I'm curious to what this output looks like on your APU2..... -
root@OpenWrt:~# cat /proc/interrupts | grep rx
37: 0 0 654609083 968920 PCI-MSI 524289-edge eth0-rx-0
43: 255 311929213 0 0 PCI-MSI 1048577-edge eth1-rx-0
44: 328737080 383 0 0 PCI-MSI 1048578-edge eth1-rx-1
49: 0 7 2029570 0 PCI-MSI 1572865-edge eth2-rx-0
50: 2029570 0 7 0 PCI-MSI 1572866-edge eth2-rx-1
Note - my PPPoE interface is eth0, and I've since limited the hardware queues on eth0 to 1. Prior to this change (which had zero affect on performance), I'd see something like -
37: 0 0 654609083 968920 PCI-MSI 524289-edge eth0-rx-0
*38: 0 0 0 0 PCI-MSI 524289-edge eth0-rx-1
..note *38 is fudged as an example, but basically zero traffic would hit the second hardware queue.
Ideally you want each receive queue bound to a different CPU to make use of a multi-core CPU....
I believe the RSS hashing algorithm was always placing PPPoE traffic in the same hardware queue - irq bound to the same CPU. Which means that PPPoE based traffic can not make use of multi-core CPUs.... would be good to see the output from your APU2 to confirm if you're getting 850Mb down in a similar scenerio....
This might interest you - https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/#hardware-interrupt-requests
|
![]() ![]() ![]() |