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

Reply via email to