Closed jotak closed 7 months ago
Attention: Patch coverage is 0%
with 4 lines
in your changes are missing coverage. Please review.
Project coverage is 36.05%. Comparing base (
d4d25a4
) to head (2816933
).
Files | Patch % | Lines |
---|---|---|
pkg/ebpf/tracer.go | 0.00% | 4 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
My theory for this change is that during a LookupAndDelete iteration, kernel space continues to receive packets for the flows already deleted, add them to the map, forcing user space to read the same flow again, hence increasing the iteration, hence giving more time for kernel to again add flows and make the process repeated indefinitely. So, better skip the flow ids that are already processed.
However I cannot say that the theory was confirmed from tests. The processing time for LookupAndDelete is still very high with this patch. Mem & cpu profiles are changing quite a lot but hard to say if it's positive or negative: cf https://docs.google.com/spreadsheets/d/1qakBaK1dk_rERO30k1cSR4W-Nn0SXW4A3lqQ1sZC4rE/edit#gid=1192055209 : I see much improved memory footprint, but also much less flows processed (I don't know why) and CPU much better in low traffic but quite higher in high traffic...
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from jotak. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.