R: [PATCH] Enabling Threaded NAPI by Default

[Jason A. Donenfeld]

On Wed, May 28, 2025 at 05:26:34PM +0000, Mirco  Barone wrote:
> This happens because NAPI polling is hosted by default in softirq
> context, but the WireGuard driver only raises this softirq after the rx
> peer queue has been drained, which doesn't happen during high traffic.
> In this case, the softirq already active on a core is reused instead of
> raising a new one.
> 
> As a result, once two or more tunnel softirqs have been scheduled on
> the same core, they remain pinned there until the surge ends.
> 
> In our experiments, this almost always leads to all tunnel NAPIs being
> handled on a single core shortly after a surge begins, limiting
> scalability to less than 3× the performance of a single tunnel, despite
> plenty of unused CPU cores being available.

So *that's* what's been going on! Holy Moses, nice discovery.

> On our 32-core gateways, enabling threaded NAPI yields a ~4× performance
> improvement with 16 tunnels, increasing throughput from ~13 Gbps to
> ~48 Gbps. Meanwhile, CPU usage on the receiver (which is the bottleneck)
> jumps from 20% to 100%.

Shut up and take my money! Patch applied.

> ---
>  drivers/net/wireguard/device.c | 1 +
>  1 file changed, 1 insertion(+)

Actually, no, wait, sorry, this needs your Signed-off-by line, per the
kernel contribution guidelines, for me to be able to push it. Can you
just reply to your initial patch email, quote all of the text, and
append the string:

    Signed-off-by: Mirco Barone <mirco.barone at polito.it>

And then I'll push this up.

Sorry for the hassle; kernel development has its particularities.

Jason