On Mon, Oct 24, 2016 at 10:42:44PM -0700, William Tu wrote: > Hi Alexei, > Thanks for your reply. > > On Mon, Oct 24, 2016 at 7:01 PM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Mon, Oct 24, 2016 at 2:22 PM, William Tu via iovisor-dev > > <iovisor-dev@lists.iovisor.org> wrote: > >> Hi, > >> > >> Is there an easy way to clear all entries in a BPF hash map? > >> > >> My use case: > >> When my BPF userspace program and kernel BPF is running, I want to > >> dynamically adding a new BPF hash map. IIUC, there is no way to do > >> that. So at beginning when loading the BPF, I pre-allocate a pool of > >> hash maps and always lookup all of them. At certain point, my > >> userspace BPF program wants to invalidate a particular map by clearing > >> all its entries. I pinned all maps as PIN_GLOBAL_NS so I think > >> userspace calling close() then open() won't clear all entries. Is > >> there a better way to do it? If there is a BPF_FUNC_map_delete_all, > >> then it will be great. Thanks! > > > > there is no delete_all, since it would be easily confused as 'atomic' > > delete. > > There cannot be an atomic delete, so user space have to walk the map > > with get_next and delete all elements. > > Such loop in user space is slightly slower than similar loop > > in kernel would have been, but it demonstrates the point that delete_all is > > not atomic either way. Also if speed of delete all matters it means the > > interaction between user and kernel space are not going to scale anyway > > as size of maps grows, number of events in kernel is increasing and so on. > > > > what do you mean by 'add a new hash map' ? > > I want my userspace program to create a new bpf map on-demand, then > the currently loaded BPF kernel program can access this map. I think > it's not possible to do that, right? Now I always provision all the > maps I needed before loading BPF to kernel. > > > The was a discussion to add 'map inside the map' concept, > > so that 1st map_lookup returns a pointer to another map which > > can be used in 2nd map operation. > > Will it solve your use case? > > In that case, my newly created map can be inserted into an entry in > 1st map. And the loaded kernel BPF can lookup 1st map, returns the > newly created map. It could solve my case. > But isn't this 'map inside the map' very difficult for verifier to > verify the map access? Thanks.
It's not easy, but doable with restrictions. When 'map in a map' is created the outer map need to have attributes to tell the verifier what key/value sizes will be in the inner maps. All inner maps can have different max_entries and probably even different map types, but key/value size have to be known to the verifier at program load time. Run-time bounds check is a performance killer. That's the reason bpf doesn't allow 'on-demand' map creation and 'map in a map' is a way out. Potentially we can do it similar to prog_array, perf_event_array with extra helper and index, but imo 'map in a map' where both inner and outer map_lookup_elem() calls are existing helpers is cleaner and more flexible. _______________________________________________ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
