On Tue, Aug 22, 2023 at 6:12 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > Hi, > > On 8/22/2023 11:25 AM, Alexei Starovoitov wrote: > > 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). > > Sorry for misunderstanding your reply. But before switch to the kfunc > way, could you please point me to some code or function which shows the > specialty of PTR_MAP_KEY ? > > Search in kernel/bpf/verifier.c how PTR_TO_MAP_KEY is handled. The logic assumes that there is associated struct bpf_map * pointer from which we know fixed-sized key length. But getting back to the topic at hand. I vaguely remember discussion we had, but it would be good if you could summarize it again here to avoid talking past each other. What is the bpf_map_ops changes you were thinking to do? How bpf_attr will look like? How BPF-side API for lookup/delete/update will look like? And then let's go from there? Thanks!
