-
Notifications
You must be signed in to change notification settings - Fork 161
Extend packet at the sock msg level #1740
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1740 +/- ##
==========================================
- Coverage 66.99% 66.98% -0.02%
==========================================
Files 214 214
Lines 22241 22244 +3
==========================================
- Hits 14901 14900 -1
- Misses 6605 6607 +2
- Partials 735 737 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4b91a8f to
a9d8c29
Compare
mariomac
left a comment
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.
amazing! I'd suggest backporting it to 2.0 branch
grcevski
left a comment
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.
Looks amazing, I do have one concern about removing the sock from the map, but I might be misunderstanding the intent.
917c19d to
9b7ec92
Compare
|
Merging as I've discussed this offline and incorporated the latest feedback. |
Instead of relying on TC to write the
Traceparent:header, leveragebeyla_packet_extenderat thesk_msglevel to not only extend the request buffer, but also write theTraceparent:string at that level.This ensures that the request buffer is manipulated only once, by a single ebpf program, and prevents corrupt requests that can be caused if one of the programs involved fails to attach.
The TC programs are now only responsible for writing the IP options, and only if the
Traceparent:header hasn't been written by thesk_msgprogram. This is done because the IP injection mechanism derives the span id from the tcp seq and ack values, which are not yet available at thesk_msglevel.The TC programs will also continue to track any new sockets that haven't been picked up by the
sockopsprogram.