ping ? On 8/3/2023 9:28 PM, Hou Tao wrote: > > On 8/3/2023 9:19 PM, Hou Tao wrote: >> Hi, >> >> I am preparing for qp-trie v4, but I need some help on how to support >> variable-sized key in bpf syscall. The implementation of qp-trie needs >> to distinguish between dynptr key from bpf program and variable-sized >> key from bpf syscall. In v3, I added a new dynptr type: >> BPF_DYNPTR_TYPE_USER for variable-sized key from bpf syscall [0], so >> both bpf program and bpf syscall will use the same type to represent the >> variable-sized key, but Andrii thought ptr+size tuple was simpler and >> would be enough for user APIs, so in v4, the type of key for bpf program >> and syscall will be different. One way to handle that is to add a new >> parameter in .map_lookup_elem()/.map_delete_elem()/.map_update_elem() to >> tell whether the key comes from bpf program or syscall or introduce new >> APIs in bpf_map_ops for variable-sized key related syscall, but I think >> it will introduce too much churn. Considering that the size of >> bpf_dynptr_kern is 8-bytes aligned, so I think maybe I could reuse the >> lowest 1-bit of key pointer to tell qp-trie whether or not it is a >> bpf_dynptr_kern or a variable-sized key pointer from syscall. For >> bpf_dynptr_kern, because it is 8B-aligned, so its lowest bit must be 0, >> and for variable-sized key from syscall, I could allocated a 4B-aligned >> pointer and setting the lowest bit as 1, so qp-trie can distinguish >> between these two types of pointer. The question is that I am not sure >> whether the idea above is a good one or not. Does it sound fragile ? Or >> is there any better way to handle that ? > Forgot to add the URL for [0]: > > [0]: > https://lore.kernel.org/bpf/CAEf4BzZyfUOfGkQP67urmG9=7pqUF-5E9LjZf-Y0sL9nbcHFww@xxxxxxxxxxxxxx/ >> Regards >> >> >> >> .
