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: xdp: use CT tuple hash for tunnel encap's source port #26177
Conversation
455d76e
to
bf6906a
Compare
/test |
bf6906a
to
8f13b1b
Compare
/test |
hash_from_tuple_v*() isn't perfect (as it ignores the .daddr), but much better than what we currently have. The one path where we might notice the reduced entropy is in a config with EgressGW and native-routing, when processing EgressGW reply traffic with non-service protocol (ICMP or other exotic types). As here we currently don't extract any L4 ports either. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
8f13b1b
to
5c967b3
Compare
Dropped the manual update of the CT tuple after RevDNAT. |
/test |
(marking as blocker so it doesn't fall through the cracks) |
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.
LGTM.
Does this need further discussion before we merge? cc @jibi |
(follow-on to #24422)
hash_from_tuple_v*()
isn't perfect (as it ignores the .daddr), but much better than what we currently have.The one path where we might notice the reduced entropy is in a config with EgressGW and native-routing, when processing EgressGW reply traffic with non-service protocol (ICMP or other exotic types). As here we currently don't extract any L4 ports either.