PinType: change from int to uint32 #1179
Merged
Conversation
This file contains 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
For supporting custom pinning behaviours in Cilium, we're looking to extend the MapSpec.Pinning flag and treat it as a bitfield internally. libbpf and ebpf-go currently only support LIBBPF_PIN_BY_NAME and ebpf.PinByName respectively, which has a value of 1, so it's still up in the air whether or not this could officially evolve into a bitfield in the future, since doing so can be done while maintaining backwards compatibility. In Cilium's case, we reserve the lower 4 bits for the upstream enum values and mask out the remaining bits before calling NewCollection. The upper bits are used for specifying flags to request specific behaviours, e.g. to ignore a pinned map during loading, and explicitly overwriting its pin at a later stage, when the entrypoint program(s) were successfully attached. Useful for working with prog arrays that need to remain pinned. We want to keep using the existing ebpf.PinType type for this, but defining masks using a signed type needs to be done with care, so ideally PinType would be unsigned. A few more data points on why this change is warranted: - bpf_elf_map always had 'unsigned int' fields only, including 'pinning' - libbpf reads the BTF map def 'pinning' field into a __u32 - Realistically, `enum libbpf_pin_type` will not acquire any negative values Signed-off-by: Timo Beckers <[email protected]>
ti-mo
force-pushed
the
tb/pinning-unsigned
branch
from
761ca89 to
d929345
Compare
lmb
approved these changes
Oct 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
For supporting custom pinning behaviours in Cilium, we're looking to extend the MapSpec.Pinning flag and treat it as a bitfield internally. libbpf and ebpf-go currently only support LIBBPF_PIN_BY_NAME and ebpf.PinByName respectively, which has a value of 1, so it's still up in the air whether or not this could officially evolve into a bitfield in the future, since doing so can be done while maintaining backwards compatibility.
In Cilium's case, we reserve the lower 4 bits for the upstream enum values and mask out the remaining bits before calling NewCollection. The upper bits are used for specifying flags to request specific behaviours, e.g. to ignore a pinned map during loading, and explicitly overwriting its pin at a later stage, when the entrypoint program(s) were successfully attached. Useful for working with prog arrays that need to remain pinned.
We want to keep using the existing ebpf.PinType type for this, but defining masks using a signed type needs to be done with care, so ideally PinType would be unsigned.
A few more data points on why this change is warranted:
enum libbpf_pin_typewill not acquire any negative values