netdev - Much higher CPU usage when generating UDP vs. TCP traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230116112739.ritnefwxhc5nyfqi@zenon.in.qult.net>
Date:   Mon, 16 Jan 2023 12:27:39 +0100
From:   Ignacy Gawędzki 
        <ignacy.gawedzki@...en-communications.fr>
To:     netdev@...r.kernel.org
Subject: Much higher CPU usage when generating UDP vs. TCP traffic

Hi,

While running some network performance tests, I discovered that the
CPU usage when generating UDP traffic is much higher than when
generating TCP traffic.  Note that no significant difference of CPU
usage was observed when simply forwarding UDP vs. TCP traffic.

This happens on Ethernet, on Wi-Fi, even on veth links (but not on the
loopback interface), so it seems unrelated to any specific hardware
driver.  BTW this difference in CPU usage decreases quite notably when
generating UDP paquets of maximum size, resulting in 64 KiB IP paquest
getting immediately fragmented to fit a standard MTU of 1500 bytes.

On platforms with more modest CPU resources, such as SoCs, this
results in much lower maximum achievable throughput in UDP vs. TCP.
Even more so with some Wi-Fi 6 drivers that seem to eat a significant
portion of CPU on their own.

I observed this happening on older kernels as well as the head of
wireless.git.  Disabling any hardware offloading doesn't change much
if anything at all.

This was really unexpected to me, since I always assumed the
processing of UDP is much simpler than that of TCP.  So I eventually
resolved to write to this list, hoping that some knowledgeable person
could shed some light on the matter.

Many thanks in advance,

Ignacy

-- 
Ignacy Gawędzki
R&D Engineer
Green Communications