bpf: Never allocate ct_buffers on the stack - #45589
Merged
Merged
Conversation
The ct_buffer object is used in a BPF map to pass lots of information
across tail calls after the ct lookup is done. As a result, it's a huge
object of 96 bytes (measured on the stack). We should never allocate it
on the stack or we'll quickly run out of space.
There's also no need to allocate it on the stack because it's already in
a BPF array map. So we can simply lookup the single-entry from the map
and populate that instead of doing a map update from a stack object.
This change reduces the stack sizes of tail_handle_ipv{4,6}_from_netdev
from 296 and 352 bytes to 232 and 256 bytes respectively.
Fixes: 1085ae2 ("bpf: Split handle_ipv6 in bpf_host.c after ct_lookup6")
Fixes: 3f356b0 ("bpf: Split handle_ipv4 in bpf_host.c after ct_lookup4")
Signed-off-by: Paul Chaignon <[email protected]>
pchaigno
added
area/datapath
Member
Author
|
/test |
pchaigno
marked this pull request as ready for review
April 24, 2026 08:41
pchaigno
enabled auto-merge
April 24, 2026 08:42
jrife
approved these changes
Apr 24, 2026
jrife
left a comment
jrife
left a comment
Contributor
There was a problem hiding this comment.
Nice improvement, thanks. I was a little concerned about something maybe not getting zeroed when it should be but it looks like for all paths where cilium_tail_call_buffer* is read it has a preceding lookup for that packet.
Something similar should be possible in bpf_lxc, no?
maintainer-s-little-helper
Bot
added
the
ready-to-merge
Member
Author
Oh, I thought bpf_lxc didn't have this issue. Ok, I'll send a followup PR for that. |
This was referenced Jul 31, 2026
9 tasks
julianwiedmann
added
the
backport-pending/1.19
github-actions
Bot
added
backport-done/1.19
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
ct_bufferobject is used in a BPF map to pass lots of information across tail calls after the conntrack lookup is done. As a result, it's a huge object of 96 bytes (measured on the stack). We should never allocate it on the stack or we'll quickly run out of space.There's also no need to allocate it on the stack because it's already in a BPF array map. So we can simply lookup the single-entry from the map and populate that instead of doing a map update from a stack object.
Results for stack sizes
Side effect on complexity
Thankfully, the impact on complexity is rather positive. It even gives us a good reduction for our largest BPF program, going from 717582 instructions to 633288.
Fixes: #23831.