Dzisiaj zrobiłem podobny test co kiedyś ale na obrazie z gałęzi master (kernel 5.4.65). Parę rzeczy mnie dziwi, ale przecież to master więc...
Wszystkie testy odbyły się tylko na jednym wątku procesora! CPU0 - 100%, CPU1 - 3%
Jeżeli będzie normalnie (czyli bez dodatkowych czarów ze strony użytkownika), ruszy drugi wątek to licząc liniowo powinno zamknąć Gigabita bez Flow_offloading

Wifi jak to wifi,  przy 3 równoległych połączeniach w moich okolicznościach przyrody puknął 333 Mbps na kliencie z kartą Broadcom BCM94352HMB dla radia 5GHz (AC)

EDIT: Analizując plik:

widać, że używany jest tylko jeden wątek (CPU0) a przecież powinien używać DWÓCH wątków w miarę równomiernie. I tak ma wpisane w:

# cat /proc/irq/17/smp_affinity
3

czytając /proc/irq/*smp_affinity można zauważyć, że prawie wszystkie "usługi" mają wpisaną możliwość rozkładania obsługi przerwań na 2 wątki oprócz irq 19 oraz 21 czyli wifi które są przypięte tylko do CPU1.

W celach eksperymentalnych wrzuciłem wifi - 19 i 21 do CPU0 a cały "ethernet" tylko do CPU1:

# cat /proc/irq/17/smp_affinity
2
cat /proc/irq/19/smp_affinity
1
cat /proc/irq/21/smp_affinity
1

i od razu widać, że przypisanie na sztywno tylko jednego CPU działa:

# cat /proc/interrupts 
           CPU0       CPU1       
...
 17:          9     129428  MIPS GIC  10  1e100000.ethernet
...

I co się stało? Wzrosło zużycie na obu rdzeniach: CPU0 - 100%, CPU1 - 72%
a korzyści prawie żadnej, bo co prawda wzrosła prędkość do 750 Mbps, ale to jest wzrost tylko o 10,5% w stosunku do stanu sprzed eksperymentu (~680 Mbps, CPU0 - 100%, CPU1 - 3%)

EDIT2: A tak w ogóle to przejście na kernel 5.4 potrzebne jest chyba tylko dla lepszego WiFi, bo na ostatnim obrazie z eko.one  wyciąga 935 Mbps ze 100 równoległymi połączeniami i zużycie tylko 1 wątku proca na poziomie 8% w htop.
Dla pewności puściłem równolegle z testem natu - openssl speed ...