-
Notifications
You must be signed in to change notification settings - Fork 14
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
TCX ebpf hook support #102
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #102 +/- ##
==========================================
- Coverage 27.61% 27.60% -0.02%
==========================================
Files 81 87 +6
Lines 6999 7499 +500
==========================================
+ Hits 1933 2070 +137
- Misses 4877 5228 +351
- Partials 189 201 +12
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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 good except for the couple of comments. I think we should consider adding a priority option even if we don't support it right away. I like the idea of using labels to define an order, but I just don't see how it would work for tcx programs included in a BpfApplication CRD.
7fd6718
to
3a850b2
Compare
4290d9a
to
d0889d6
Compare
@msherif1234, this pull request is now in conflict and requires a rebase. |
89fc221
to
9e361a8
Compare
This PR introduces support for TCX based on the current implementation in the astoycos Aya TCX branch. While minor API changes are anticipated before Aya TCX merges, these are expected to be cosmetic and should not significantly affect bpfman. The PR implements a priority-based API, similar to the existing TC API, with a key difference: TCX does not support "proceed_on" configuration as it's not available in the kernel API. Flow continuation is determined by the return value of the current program. It's important to note that neither the Aya nor the kernel APIs directly support priority. They utilize a relative positioning system, requiring new TCX programs to be placed relative to existing ones. To maintain usability across multiple independent applications, we’ve preserved a TC-like priority API in bpfman, which internally maps to Aya’s relative-ordering API. This PR also adds an integration test and example programs for TCX, which have been successfully tested with Mohammed’s TCX bpfman-operator PR (bpfman/bpfman-operator#102). Additionally, due to TCX's requirement for kernel version 6.6 or higher, GitHub Actions have been updated to use ubuntu-24.04. Signed-off-by: Andre Fredette <[email protected]>
This PR introduces support for TCX based on the current implementation in the astoycos Aya TCX branch. While minor API changes are anticipated before Aya TCX merges, these are expected to be cosmetic and should not significantly affect bpfman. The PR implements a priority-based API, similar to the existing TC API, with a key difference: TCX does not support "proceed_on" configuration as it's not available in the kernel API. Flow continuation is determined by the return value of the current program. It's important to note that neither the Aya nor the kernel APIs directly support priority. They utilize a relative positioning system, requiring new TCX programs to be placed relative to existing ones. To maintain usability across multiple independent applications, we’ve preserved a TC-like priority API in bpfman, which internally maps to Aya’s relative-ordering API. This PR also adds an integration test and example programs for TCX, which have been successfully tested with Mohammed’s TCX bpfman-operator PR (bpfman/bpfman-operator#102). Additionally, due to TCX's requirement for kernel version 6.6 or higher, GitHub Actions have been updated to use ubuntu-24.04. Signed-off-by: Andre Fredette <[email protected]>
This PR introduces support for TCX based on the current implementation in the astoycos Aya TCX branch. While minor API changes are anticipated before Aya TCX merges, these are expected to be cosmetic and should not significantly affect bpfman. The PR implements a priority-based API, similar to the existing TC API, with a key difference: TCX does not support "proceed_on" configuration as it's not available in the kernel API. Flow continuation is determined by the return value of the current program. It's important to note that neither the Aya nor the kernel APIs directly support priority. They utilize a relative positioning system, requiring new TCX programs to be placed relative to existing ones. To maintain usability across multiple independent applications, we’ve preserved a TC-like priority API in bpfman, which internally maps to Aya’s relative-ordering API. This PR also adds an integration test and example programs for TCX, which have been successfully tested with Mohammed’s TCX bpfman-operator PR (bpfman/bpfman-operator#102). Additionally, due to TCX's requirement for kernel version 6.6 or higher, GitHub Actions have been updated to use ubuntu-24.04. Signed-off-by: Andre Fredette <[email protected]>
This PR introduces support for TCX based on the current implementation in the astoycos Aya TCX branch. While minor API changes are anticipated before Aya TCX merges, these are expected to be cosmetic and should not significantly affect bpfman. The PR implements a priority-based API, similar to the existing TC API, with a key difference: TCX does not support "proceed_on" configuration as it's not available in the kernel API. Flow continuation is determined by the return value of the current program. It's important to note that neither the Aya nor the kernel APIs directly support priority. They utilize a relative positioning system, requiring new TCX programs to be placed relative to existing ones. To maintain usability across multiple independent applications, we’ve preserved a TC-like priority API in bpfman, which internally maps to Aya’s relative-ordering API. This PR also adds an integration test and example programs for TCX, which have been successfully tested with Mohammed’s TCX bpfman-operator PR (bpfman/bpfman-operator#102). Additionally, due to TCX's requirement for kernel version 6.6 or higher, GitHub Actions have been updated to use ubuntu-24.04. Signed-off-by: Andre Fredette <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
intg test seems to broken because of bpfman/bpfman#1324 |
It definitely was, but I think I backed out the changes that were
causing the issue. I could be wrong, but I suspect that it's now failing
because bpfman/bpfman#1222 added tcx to the app
counter example.
…On Tue, Oct 22, 2024 at 6:27 AM Mohamed S. Mahmoud ***@***.***> wrote:
intg test seems to broken because of bpfman/bpfman#1324
<bpfman/bpfman#1324>
—
Reply to this email directly, view it on GitHub
<#102 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHY7XZB5NCWF57JVHRW2S3Z4YSCNAVCNFSM6AAAAABMOFAXMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRYHEYDEMZXHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Signed-off-by: Mohamed Mahmoud <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
Signed-off-by: Mohamed Mahmoud <[email protected]>
test/integration/tcx_test.go
Outdated
|
||
pods, err := env.Cluster().Client().CoreV1().Pods(tcxGoCounterUserspaceNs).List(ctx, metav1.ListOptions{LabelSelector: "name=go-tcx-counter"}) | ||
require.NoError(t, err) | ||
gotcCounterPod := pods.Items[0] |
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.
Should gotcCounterPod be gotcxCounterPod?
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.
sure
test/integration/tcx_test.go
Outdated
require.NoError(t, err) | ||
t.Logf("counter pod log %s", output.String()) | ||
|
||
return doTcCheck(t, output) |
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.
doTcxCheck?
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.
It seems like we need a doTcxCheck() function. This is probably working because the tc test is also running and there are logs from that test.
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.
I reused the Tc check since both look for the same string might be better to have one for tcx will do
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.
Doesn't the TCX program have "TCX" in the log instead of "TC"?
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.
Actually, I just looked, and it doesn't. I think it should, though. That's probably another reason I changed the TC, TCX, and XDP logs in the app counter example.
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.
We can do that in a separate pr, though.
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.
Or not. They're all in separate pods, so I guess it's clear. Sorry for the stream of consciousness as I remember how all this stuff works :-).
// +kubebuilder:printcolumn:name="Status",type=string,JSONPath=`.status.conditions[0].reason` | ||
// +kubebuilder:printcolumn:name="Direction",type=string,JSONPath=`.spec.direction`,priority=1 | ||
// +kubebuilder:printcolumn:name="InterfaceSelector",type=string,JSONPath=`.spec.interfaceselector`,priority=1 | ||
// +kubebuilder:printcolumn:name="Position",type=string,JSONPath=`.spec.position`,priority=1 |
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.
Include the following as in Tc:
// +kubebuilder:printcolumn:name="Priority",type=string,JSONPath=.spec.priority
,priority=1
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.
ok I had b4 we added pri to tcx will include
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.
Mostly a few nits. I think the only real issue is the doTcxCheck() comment. Otherwise, this is looking good.
Signed-off-by: Mohamed Mahmoud <[email protected]>
|
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
chore(deps): update konflux references
fixes #92
depends on: bpfman/bpfman#1222