Hi, On 8/22/2023 8:58 AM, Alexei Starovoitov wrote: > On Mon, Aug 21, 2023 at 5:55 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >> Hi, >> >> On 8/22/2023 7:49 AM, Alexei Starovoitov wrote: >>> On Sat, Aug 19, 2023 at 3:39 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >>>> Hi, >>>> >>>> On 8/18/2023 7:00 AM, Alexei Starovoitov wrote: >>>>> On Wed, Aug 16, 2023 at 11:35 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: >>>>> SNIP >>>>> If the existing bpf_map_lookup_elem() helper doesn't fit qp-tree we can >>>>> use new kfuncs from bpf prog and LPM-like map accessors from syscall. >>>> It is a feasible solution, but it will make qp-trie be different with >>>> other map types. I will try to extend the APIs in bpf_map_ops first to >>>> see how much churns it may introduce. >>> you mean you want to try to dynamically adapt bpf_map_lookup_elem() >>> to consider 'void *key' as a pointer to dynptr for bpf prog and >>> lpm-like tuple for syscall? >>> I'm afraid the verifier changes will be messy, since PTR_TO_MAP_KEY is >>> quite special. >> No. I didn't plan to do that. I am trying to add three new APIs in >> bpf_map_ops to handle lookup/update/delete operation from bpf syscall >> (e.g, map_lookup_elem_syscall). So bpf program and bpf syscall can use >> different API to operate on qp-trie. > How does bpf prog side api look like? > I thought we wanted to use dynptr as a key? Yes. bpf prog will use dynptr as the map key. The bpf program will use the same map helpers as hash map to operate on qp-trie and the verifier will be updated to allow using dynptr as map key for qp-trie.
