On Mon, Aug 21, 2023 at 6:46 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > 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. And that's the problem I just mentioned. PTR_TO_MAP_KEY is special. I don't think we should hack it to also mean ARG_PTR_TO_DYNPTR depending on the first argument (map type).
