-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpf: significantly improve capacity of TCP CT tables #10518
Conversation
test-me-please |
Hitting #10517 as well now in CI:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good find! One comment.
Do we consider this as a bug? Asking, as we might need to set |
No-one reported an issue at this point, but we potentially could backport. |
be1fe4d
to
1ee55ed
Compare
test-me-please |
test-me-please |
provision failure again |
test-me-please |
1ee55ed
to
8d4653d
Compare
test-me-please |
Build expired. Triggering again... |
test-me-please Failed on #10442: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18147/ |
test-me-please net-next vm provisioning fail: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18158/ |
test-me-please Looks like #9330: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18171/ |
test-me-please Hit #9330 again, it seems: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18182/ |
test-me-please |
ct_create{4,6}() inserts related entries into the TCP CT tables given the map is usually in the form of ct_create4(get_ct_map4(&tuple)) or ct_create6(get_ct_map6(&tuple)). Similarly, the lookup parts are in form of ct_lookup4(get_ct_map4(&tuple)) or ct_lookup6(get_ct_map6(&tuple)). However, the tuples' nexthdr usually points to the one in the packet. This means, we can /never/ find a related entry since it sits in the TCP CT tables, but their lookup is always in the ANY table instead. Fix the insertions by adding to the CT_MAP_ANY{4,6} tables and by that implicityly double the capacity of TCP CT tables. Go even beyond that by not creating related entries for CT_SERVICE entries. It does not make sense to create CT_SERVICE entries with related flag since we don't translate ICMP there anyway. Save overhead and don't add them to the maps (same for NodePort/NAT related ones). Fixes: 750b3f9 ("bpf: Split connection tracking for TCP and non-TCP") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
8d4653d
to
eddafe1
Compare
test-me-please net-next vm provisioning fail: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18221/ |
test-me-please |
1 similar comment
test-me-please |
Hit #10231 |
test-me-please |
ct_create{4,6}() inserts related entries into the TCP CT tables given
the map is usually in the form of ct_create4(get_ct_map4(&tuple)) or
ct_create6(get_ct_map6(&tuple)). Similarly, the lookup parts are in
form of ct_lookup4(get_ct_map4(&tuple)) or ct_lookup6(get_ct_map6(&tuple)).
However, the tuples' nexthdr usually points to the one in the packet.
This means, we can /never/ find a related entry since it sits in the TCP
CT tables, but their lookup is always in the ANY table instead.
Fix the insertions by adding to the CT_MAP_ANY{4,6} tables and by that
implicityly double the capacity of TCP CT tables.
Go even beyond that by not creating related entries for CT_SERVICE entries.
It does not make sense to create CT_SERVICE entries with related flag
since we don't translate ICMP there anyway. Save overhead and don't add
them to the maps (same for NodePort/NAT related ones).
Fixes: 750b3f9 ("bpf: Split connection tracking for TCP and non-TCP")
Signed-off-by: Daniel Borkmann daniel@iogearbox.net
This change is