Support XDP Nodeport & Tunnel config#21364
Merged
ti-mo merged 5 commits intocilium:masterfrom Oct 5, 2022
Merged
Conversation
b982d32 to
8485461
Compare
Member
Author
|
/test |
8485461 to
3cbf9d4
Compare
Member
Author
|
/test |
Member
Author
|
/test-1.25-net-next |
jibi
approved these changes
Sep 29, 2022
54cae6f to
7f2aad7
Compare
Member
Author
|
Needed a rebase to resolve a small conflict in |
Member
Author
|
/test |
7f2aad7 to
e4138d2
Compare
Member
Author
|
/test Job 'Cilium-PR-K8s-1.25-kernel-net-next' failed: Click to show.Test NameFailure OutputIf it is a flake and a GitHub issue doesn't already exist to track it, comment |
Generalize the SNAT_DONE helpers, so that they can also be used from XDP context. No change in behaviour for now, the actual XDP implementation comes in a subsequent patch. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
The comment in XDP's ctx_snat_done_set() is no longer accurate. While a packet doesn't pass through any Egress hook in XDP, it might be punted up to TC-Ingress and later pass through such a hook as SKB. So keep track of whether XDP has done the SNAT processing, and transfer the flag to a punted skb. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
When running in a cluster config with tunneling, the nodeport code forwards traffic to a backend on another node by first calling __encap_with_nodeid() and then redirecting the packet to the tunnel interface. To enable this for XDP Acceleration, we need to support that __encap_with_nodeid() can also return CTX_ACT_OK. In this case the packet gets punted up to TC-Ingress of the physical interface, where the usual tunnel processing happens. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
…ling The Nodeport code now supports egressing into a tunnel interface when in XDP context (although at lower performance, due to the punt to TC-Ingress). As the TUNNEL_MODE macro is only set up by init.sh, shuffle building the XDP program around. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
Keep it consistent with the other tail_nodeport_nat_*() functions. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
e4138d2 to
c39254a
Compare
Member
Author
|
/test |
Member
Author
|
/test-1.25-net-next |
nbusseneau
approved these changes
Oct 4, 2022
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
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.
[follow-on to the recent EgressGW + XDP work]
In order to support XDP Nodeport acceleration in a tunnel config, the XDP Nodeport code needs to encap packets before forwarding them to a backend on a different node. As we currently can't
bpf_redirect()tocilium_vxlan/cilium_genevefrom within XDP, the datapath supports punting such packets from XDP to TC-Ingress (and then handling the redirect from there).This patchset converts the existing TUNNEL_MODE sections in
lib/nodeport.hto support such punting from XDP to TC-Ingress. Performance won't be as good as pure-XDP.