Hi Alexei, On Fri, Nov 20, 2015, at 04:30, Alexei Starovoitov wrote: > On Thu, Nov 19, 2015 at 09:12:30PM +0100, Hannes Frederic Sowa wrote: > > On Thu, Nov 19, 2015, at 19:32, Alexei Starovoitov wrote: > > > On Thu, Nov 19, 2015 at 07:19:24PM +0100, Hannes Frederic Sowa wrote: > > > > On Thu, Nov 19, 2015, at 11:56, Daniel Borkmann wrote: > > > > > Add a handler for show_fdinfo() to be used by the anon-inodes > > > > > backend for eBPF maps, and dump the map specification there. Not > > > > > only useful for admins, but also it provides a minimal way to > > > > > compare specs from ELF vs pinned object. > > > > > > > > > > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> > > > > > > > > Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> > > > > > > > > Does it make sense to include bpf_htab->count in case of a hashmap? > > > > > > no. user space should not rely on such things. It can only be misused. > > > > Sorry, I don't get it. How can it be misused? As an admin it would > > certainly be interesting to know the pressure on the map? Do you expect > > kmsg messages from the eBPF program? > > If user space can be see both 'count' and 'max_entries', it can be very > tempting to start assuming 'full' and 'empty' state of the map which will > lead to race conditions and bad design. > bpf programs and maps are inherently multi-thread and concurrent. > If userapp wants to do the counting of elements it needs to do so on its > own > and shoot itself in the foot eventually. > For the same reason I don't want to see BPF_MAP_GET_COUNT command.
Hmmm... I don't understand your argument. This is the same with memory management in general and we still report memory statistics to user space. I really would find it helpful to have a feeling if a map is nearly full or nearly empty. We can also count collisions or the load in the buckets, but some evidence what is going on would be nice, wouldn't it? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html