> So per that messaging, the UDP-Lite code really hasn't been used in years and doing away with it can net some measurable (+3~10% packets per second) for other UDP workloads.
Often times removing deprecated code is purely for developer purity. You just don’t want it lying around.
But 3-10% pps improvement is quite an achievement for removing some branches.
> By removing a bunch of conditionals for UDP-Lite from the fast path, udp_rr with 20,000 flows sees a 10% increase in pps (13.3 Mpps -> 14.7 Mpps) on an AMD EPYC 7B12 (Zen 2) 64-Core Processor platform.
Considering the number linux udp sockets in the wild this is huge. It’s a shame C/compilers can’t optimize this away though without entirely removing the code, this is exactly why zig’s comptime exists.
It's interesting how they found the unused code. Are there enough real world participants who would allow tracing in order to understand what other codeblocks are unused in the real world and put in deprecation notices? I kind of wonder what percentage of the code is nominally functional but never actually used even in the wild.
> It's interesting how they found the unused code.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
I must admit just from reading the description, it doesn't sound that the correct inference is that it's never been used.
"In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem." to me reads that if the total memory usage never exceeded that threshold then the bug wouldn't trigger. So, wouldn't this bug only affect people who changed that threshold down below the current usage? Because otherwise, usage wouldn't go above the threshold anyway?
And just because the kernel is logging a deprecation notice, there's no guarantee that anyone would ever see that, depending how often it was logged.
But that said, I'd never even heard of this feature, and wouldn't be at all surprised if many routers hadn't just silently dropped these packets anyway because they didn't recognise the protocol version.
Ultimately Linux development is driven by people who participate on LKML. If you are not willing to at least follow deprecations and show up for discussions then you are at the mercy of those who do
Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable. I'm sure the kernel's deprecation policy is more detailed than "show up on LKML or else".
> Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable.
Breakages to userspace happen somewhat regularly from what I get, but its more of a case of "If the tree falls in the forest and nobody complains it didn't happen". Though its more that one should at least make sure in some form or fashion that it won't at least affect anyone.
I don't have a program that uses it, so it's not my place to watch mailing lists for it getting deprecated. Basic searching of Github however (what I'd have expected them to do before removing it) reveals 20k files that contain IPPROTO_UDPLITE, and many projects that use it directly. Probably the most renowned is FFmpeg (!!!).
> So per that messaging, the UDP-Lite code really hasn't been used in years and doing away with it can net some measurable (+3~10% packets per second) for other UDP workloads.
Often times removing deprecated code is purely for developer purity. You just don’t want it lying around.
But 3-10% pps improvement is quite an achievement for removing some branches.
> By removing a bunch of conditionals for UDP-Lite from the fast path, udp_rr with 20,000 flows sees a 10% increase in pps (13.3 Mpps -> 14.7 Mpps) on an AMD EPYC 7B12 (Zen 2) 64-Core Processor platform.
Considering the number linux udp sockets in the wild this is huge. It’s a shame C/compilers can’t optimize this away though without entirely removing the code, this is exactly why zig’s comptime exists.
It's interesting how they found the unused code. Are there enough real world participants who would allow tracing in order to understand what other codeblocks are unused in the real world and put in deprecation notices? I kind of wonder what percentage of the code is nominally functional but never actually used even in the wild.
> It's interesting how they found the unused code.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
I must admit just from reading the description, it doesn't sound that the correct inference is that it's never been used.
"In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem." to me reads that if the total memory usage never exceeded that threshold then the bug wouldn't trigger. So, wouldn't this bug only affect people who changed that threshold down below the current usage? Because otherwise, usage wouldn't go above the threshold anyway?
And just because the kernel is logging a deprecation notice, there's no guarantee that anyone would ever see that, depending how often it was logged.
But that said, I'd never even heard of this feature, and wouldn't be at all surprised if many routers hadn't just silently dropped these packets anyway because they didn't recognise the protocol version.
Ultimately Linux development is driven by people who participate on LKML. If you are not willing to at least follow deprecations and show up for discussions then you are at the mercy of those who do
Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable. I'm sure the kernel's deprecation policy is more detailed than "show up on LKML or else".
> Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable.
Breakages to userspace happen somewhat regularly from what I get, but its more of a case of "If the tree falls in the forest and nobody complains it didn't happen". Though its more that one should at least make sure in some form or fashion that it won't at least affect anyone.
The variable length checksum is much less useful when the data stream is encrypted, which it usually is today.
Source: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-n...
So much for never breaking userspace.
It is not breaking userspace if there are no programs in userspace that care.
If you have a program that cares please report it.
The evidence is that no one has had a program that cares since 2016. A decade of holding on to dead code seems enough.
I don't have a program that uses it, so it's not my place to watch mailing lists for it getting deprecated. Basic searching of Github however (what I'd have expected them to do before removing it) reveals 20k files that contain IPPROTO_UDPLITE, and many projects that use it directly. Probably the most renowned is FFmpeg (!!!).
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/udp...
https://github.com/search?q=IPPROTO_UDPLITE&type=code
https://github.com/tormol/udplite
https://github.com/nplab/packetdrill
https://github.com/python/cpython/blob/4e96282ee42ab51cf325b...
https://github.com/search?q=repo%3Aviveris%2Frohc%20udplite&...