bpf:trace: pass L3 protocol to send_trace_notify#39794
Merged
julianwiedmann merged 3 commits intomainfrom May 30, 2025
Merged
Conversation
maintainer-s-little-helper
bot
added
the
dont-merge/needs-release-note-label
smagnani96
added
kind/enhancement
Contributor
Author
|
/test |
smagnani96
changed the title
Member
|
lgtm! For some of the changes in bpf_lxc and bpf_overlay I could see us eventually converging to a |
Prior to this patch, using `send_trace_notify{4,6}` cause the metrics
to be updated using __MAGIC_LINE__ and __MAGIC_FILE__ from `trace.h`
rather than from the original file invoking the helper function.
That behavior is not aligned to `send_trace_notify` helper, which
makes use of the caller's line+file. Let's fix this while also slightly
refactors such helpers.
We keep the `update_trace_metrics()` macro so that we can decide to make
use of it instead of the whole trace notification in come codepaths
(future PR).
Signed-off-by: Simone Magnani <[email protected]>
This commits adds to the encap-related helpers a new parameter `__be16 proto` that corresponds to the L3 protocol carried. This will come useful in subsequent commit, where we pass this parameter to the trace helpers. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
force-pushed
the
pr/smagnani96/trace-refactors
branch
from
550afa1 to
4c59ca5
Compare
Contributor
Author
I couldn't wait for the future knowing there was a way better solution. |
smagnani96
commented
May 30, 2025
smagnani96
commented
May 30, 2025
smagnani96
changed the title
Contributor
Author
|
/test |
This commit adds to the `send_trace_notify` helper the `__be16 proto` fields, which represents the L3 protocol carried. This will come useful in subsequent PR for `ctx_classify` where, for instance, we could save verifier complexity while parsing the packet to determine the traffic pattern (e.g., overlay, wireguard, etc.) and compute the apposite classifiers. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
force-pushed
the
pr/smagnani96/trace-refactors
branch
from
4c59ca5 to
977ea24
Compare
Contributor
Author
|
/test |
rgo3
approved these changes
May 30, 2025
Contributor
rgo3
left a comment
rgo3
left a comment
There was a problem hiding this comment.
Looks good for my codeowners!
julianwiedmann
added
the
area/monitor
maintainer-s-little-helper
bot
added
the
ready-to-merge
smagnani96
added a commit
that referenced
this pull request
Jun 4, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
smagnani96
added a commit
that referenced
this pull request
Jun 4, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 17, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 17, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 17, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 17, 2025
In #39794, we enabled passing the carried L3 protocol when calling `send_trace_notify`. Let's use this argument for `ctx_classify`. This allows to set the CLS_FLAG_IPV6 whenever we detect an IPV6 packet, and not only when having a layer 3 IPv6 packet. In addition, this is useful in subsequent commits where we extend classifiers: the new logic will save verifier complexity and packet processing time given we have already the protocol computed. For some edge case in which the variable protocol is left to zero and not being set to the current protocol (ex. from drop notification or when being called after a failing validate_ethertype), we can compute the protocol from `ctx_classify` itself. Here we also initialize the proto variable in bpf_lxc.c to avoid compilation errors due to variable not being initialized. This was not needed before as it was not being used, therefore removed during compilation. Signed-off-by: Simone Magnani <[email protected]>
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.
Let's pass the L3 protocol to out
send_trace_notifyhelper while emitting a trace notification.This is useful to avoid re-computing it in case it is needed (see #39650 where we start differentiating protocols in
ctx_classify).