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: migrate hand-written bpf syscalls to ebpf-go APIs #25355
Conversation
62af59c
to
a43ea7a
Compare
/test |
1 similar comment
/test |
519a9ea
to
2591156
Compare
/test |
return false, fmt.Errorf("unable to delete element %s from map %s: %w", key, m.name, err) | ||
} | ||
|
||
return true, nil | ||
} | ||
|
||
// SilentDelete deletes the map entry corresponding to the given key. |
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.
Drive by: this description doesn't tell me at all what makes the function so silent.
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.
Yeah, this needs to go. As you can see, the Map API is full of this sort of snowflake and unhelpful/incomplete doc. To answer your question: it skips incrementing the map's delete metric.
IMO this highlights a common problem with the design of the data model in the upper layer(s). The data (e.g. ct record) and the underlying data store (e.g. the ct map) are conflated. The bpf layer shouldn't lie about the amount of deletes it issues to the kernel, as it could mask a potential perf problem.
Net [16]byte | ||
|
||
// v4 LPM maps have 8-byte key sizes even though the 20-byte cidrKey is used | ||
// for map ops. This hack relies on passing unsafe.Pointers to the cidrKey so |
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.
Oh boy
Replace bpf.DeleteElement() by calls into ebpf.Map.Delete(). Move metrics handling into bpf.Map.delete(). Signed-off-by: Timo Beckers <timo@isovalent.com>
In order to move away from map operations implemented in pkg/bpf/bpf_linux.go, migrate Map.DumpWithCallback and friends onto ebpf-go based primitives. No changes are made to the algorithm used in DumpReliably..(). Signed-off-by: Timo Beckers <timo@isovalent.com>
Signed-off-by: Timo Beckers <timo@isovalent.com>
Signed-off-by: Timo Beckers <timo@isovalent.com>
…port This was moved in from the verifier tests and given a test suite of its own. Test cases based on what the agent does on startup. Signed-off-by: Timo Beckers <timo@isovalent.com>
This will be used in a follow-up commit to be executed during socketlb setup. It implements only the cgroup link/prog_attach part of TestDummyProg so it can be run once instead of on each prog/attach type probe combination. Includes a privileged test that is expected to succeed in all CI environments. Signed-off-by: Timo Beckers <timo@isovalent.com>
Builds on the APIs added in prior commits. Probing for cgroup attach support is now only done once at the start of the socketlb setup, and prog/attach type probes are now executed separately, underlyingly using APIs from ebpf-go. Signed-off-by: Timo Beckers <timo@isovalent.com>
/test |
/test-1.26-net-next |
This is based on #22693 and contains all of its commits. That one is close to being merged, so this can be rebased later.
See individual commits. Again a bit of churn, but relatively straightforward.
Fixes: #22513
Fixes: #23558