fff-network: add packet_steering option to enable RPS #157

fbl · 2021-08-05T17:56:24+02:00

fbl commented

2021-08-05 17:56:24 +02:00

Receive packet steering (RPS) is a linux feature to improve forwarding
performance by distributing the forwarding of packets across multiple
cpus. This is necessary for network devices which have less queues than
cpu cores.

OpenWrt allows to enable RPS easily by setting the global option
'packet_steering' in the network configuration. With earlier OpenWrt
versions this option was enabled by default. However, the default value
was changed with OpenWrt 21.02.

Enable this option agian to improve forwarding performance on routers
with multiple cpu cores.

Signed-off-by: Fabian Bläse fabian@blaese.de

Receive packet steering (RPS) is a linux feature to improve forwarding performance by distributing the forwarding of packets across multiple cpus. This is necessary for network devices which have less queues than cpu cores. OpenWrt allows to enable RPS easily by setting the global option 'packet_steering' in the network configuration. With earlier OpenWrt versions this option was enabled by default. However, the default value was changed with OpenWrt 21.02. Enable this option agian to improve forwarding performance on routers with multiple cpu cores. Signed-off-by: Fabian Bläse <fabian@blaese.de>

fbl added 1 commit 2021-08-05 17:56:24 +02:00

40ee080e30 fff-network: add packet_steering option to enable RPS

Receive packet steering (RPS) is a linux feature to improve forwarding
performance by distributing the forwarding of packets across multiple
cpus. This is necessary for network devices which have less queues than
cpu cores.

OpenWrt allows to enable RPS easily by setting the global option
'packet_steering' in the network configuration. With earlier OpenWrt
versions this option was enabled by default. However, the default value
was changed with OpenWrt 21.02.

Enable this option agian to improve forwarding performance on routers
with multiple cpu cores.

Signed-off-by: Fabian Bläse <fabian@blaese.de>

jkimmel commented

2021-08-06 13:23:05 +02:00

Müsste um diese Änderung gehen: https://github.com/openwrt/openwrt/pull/2553

Das wurde scheinbar gemacht, weil bei einigen Kisten RPS wohl mehr schadet als hilft. Wie sicher sind wir uns, dass das allen von uns unterstützten Geräten hilft? Ich selbst hab RPS nur mit den edgeroutern getestet und da hilfts definitiv.
Andererseits stellt das nur wieder das Verhalten von vorher her. Sollten wir einzelne Geräte finden, die besser ohne RPS funktionieren, können wir es immernoch geräteabhängig abschalten.

Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>

Müsste um diese Änderung gehen: https://github.com/openwrt/openwrt/pull/2553 Das wurde scheinbar gemacht, weil bei einigen Kisten RPS wohl mehr schadet als hilft. Wie sicher sind wir uns, dass das allen von uns unterstützten Geräten hilft? Ich selbst hab RPS nur mit den edgeroutern getestet und da hilfts definitiv. Andererseits stellt das nur wieder das Verhalten von vorher her. Sollten wir einzelne Geräte finden, die besser ohne RPS funktionieren, können wir es immernoch geräteabhängig abschalten. `Reviewed-by: Johannes Kimmel <fff@bareminimum.eu>`

fbl commented

2021-08-06 14:57:07 +02:00

Genau um diese Änderung gehts. Gleichzeitig wurde auch entfernt, dass die Interrupt-CPU von den rps_cpus augeschlossen wird. Hat aber tatsächlich kaum einen relevanten Performance-Unterschied gemacht.

Der größte Teil unserer Geräte hat afaik sowieso nur einen Kern, in so fern dürfte das sowieso fast egal sein. Und beim EdgeRouter X macht es einen relativ signifikanten Unterschied.

Genau um diese Änderung gehts. Gleichzeitig wurde auch entfernt, dass die Interrupt-CPU von den rps_cpus augeschlossen wird. Hat aber tatsächlich kaum einen relevanten Performance-Unterschied gemacht. Der größte Teil unserer Geräte hat afaik sowieso nur einen Kern, in so fern dürfte das sowieso fast egal sein. Und beim EdgeRouter X macht es einen relativ signifikanten Unterschied.

ChristianD commented

2021-08-07 10:14:03 +02:00

Macht es unter diesen Umständen vielleicht Sinn, die Wahl den User zu lassen ob er es möchte? Sprich eine Option in /etc/config/gateway einführen wo es ein User bewusst anschalten kann?

Ich selbst kann es gar nicht einschätzen aber da hier so Sätze fallen wie "Das wurde scheinbar gemacht, weil bei einigen Kisten RPS wohl mehr schadet als hilft." ist es vielleicht nicht schlau das jetzt einfach hart überall anzuschalten und in 4 Wochen merken wir oh dieser und dieser und dieser sollte es doch besser aus haben und wir rollen wieder alles zurück.

Macht es unter diesen Umständen vielleicht Sinn, die Wahl den User zu lassen ob er es möchte? Sprich eine Option in /etc/config/gateway einführen wo es ein User bewusst anschalten kann? Ich selbst kann es gar nicht einschätzen aber da hier so Sätze fallen wie "Das wurde scheinbar gemacht, weil bei einigen Kisten RPS wohl mehr schadet als hilft." ist es vielleicht nicht schlau das jetzt einfach hart überall anzuschalten und in 4 Wochen merken wir oh dieser und dieser und dieser sollte es doch besser aus haben und wir rollen wieder alles zurück.

fbl commented

2021-08-08 00:24:19 +02:00

Ich denke nicht, dass dies etwas ist, was für einen Nutzer der Firmware in irgendeiner Form interessant ist.

Das ganze dürfte eigentlich nur Geräte mit NUMA, heterogenen CPUs oder RSS-fähigem Ethernet betreffen. Sollten wir in Zukunft tatsächlich Geräte unterstützen, bei denen RPS mehr schadet, als es hilft, können wir diese Einstellung target-, subtarget- oder gerätespezifisch anwenden.

Ich denke nicht, dass dies etwas ist, was für einen Nutzer der Firmware in irgendeiner Form interessant ist. Das ganze dürfte eigentlich nur Geräte mit NUMA, heterogenen CPUs oder RSS-fähigem Ethernet betreffen. Sollten wir in Zukunft tatsächlich Geräte unterstützen, bei denen RPS mehr schadet, als es hilft, können wir diese Einstellung target-, subtarget- oder gerätespezifisch anwenden.

fbl commented

2021-09-02 18:29:17 +02:00

merged.

fbl closed this pull request

2021-09-02 18:29:17 +02:00