Re: [PATCH net-next] net/core: add optional threading for backlog processing
From: Jesper Dangaard Brouer
Date: Wed Mar 29 2023 - 12:16:06 EST
On 24/03/2023 18.35, Felix Fietkau wrote:
On 24.03.23 18:20, Jakub Kicinski wrote:
On Fri, 24 Mar 2023 18:13:14 +0100 Felix Fietkau wrote:
When dealing with few flows or an imbalance on CPU utilization, static RPS
CPU assignment can be too inflexible. Add support for enabling threaded NAPI
for backlog processing in order to allow the scheduler to better balance
processing. This helps better spread the load across idle CPUs.
Can you explain the use case a little bit more?
I'm primarily testing this on routers with 2 or 4 CPUs and limited
processing power, handling routing/NAT. RPS is typically needed to
properly distribute the load across all available CPUs. When there is
only a small number of flows that are pushing a lot of traffic, a static
RPS assignment often leaves some CPUs idle, whereas others become a
bottleneck by being fully loaded. Threaded NAPI reduces this a bit, but
CPUs can become bottlenecked and fully loaded by a NAPI thread alone.
Making backlog processing threaded helps split up the processing work
even more and distribute it onto remaining idle CPUs.
It can basically be used to make RPS a bit more dynamic and
configurable, because you can assign multiple backlog threads to a set
of CPUs and selectively steer packets from specific devices / rx queues
to them and allow the scheduler to take care of the rest.
My experience with RPS was that it was too slow on the RX-CPU. Meaning
that it doesn't really scale, because the RX-CPU becomes the scaling
bottleneck. (My data is old and it might scale differently on your ARM
boards).
This is why I/we created the XDP "cpumap". It also creates a kernel
threaded model via a kthread on "map-configured" CPUs. It scales
significantly better than RPS, but it doesn't handle flows and packet
Out-of-Order (OoO) situations automatically like RPS. That is left up
to the BPF-programmer. The kernel samples/bpf xdp_redirect_cpu[0] have
code that shows strategies of load-balancing flows.
The project xdp-cpumap-tc[1] runs in production (3 ISPs using this) and
works in concert with netstack Traffic Control (TC) for scaling
bandwidth shaping at the ISPs. OoO is solved by redirecting all
customers IPs to the same TX/egress CPU. As the README[1] describes it
is recommended to reduce the number of RX-CPUs processing packets, and
have more TX-CPUs that basically runs netstack/TC. One ISP with
2x25Gbit/s is using 2 CPUs for RX and 6 CPUs for TX.
--Jesper
[0]
https://github.com/torvalds/linux/blob/master/samples/bpf/xdp_redirect_cpu.bpf.c
[1] https://github.com/xdp-project/xdp-cpumap-tc