2019-08-14 17:45 UTC+0100 ~ Edward Cree <ecree@xxxxxxxxxxxxxx> > On 14/08/2019 10:42, Quentin Monnet wrote: >> 2019-08-13 18:51 UTC-0700 ~ Alexei Starovoitov >> <alexei.starovoitov@xxxxxxxxx> >>> The same can be achieved by 'bpftool map dump|grep key|wc -l', no? >> To some extent (with subtleties for some other map types); and we use a >> similar command line as a workaround for now. But because of the rate of >> inserts/deletes in the map, the process often reports a number higher >> than the max number of entries (we observed up to ~750k when max_entries >> is 500k), even is the map is only half-full on average during the count. >> On the worst case (though not frequent), an entry is deleted just before >> we get the next key from it, and iteration starts all over again. This >> is not reliable to determine how much space is left in the map. >> >> I cannot see a solution that would provide a more accurate count from >> user space, when the map is under pressure? > This might be a really dumb suggestion, but: you're wanting to collect a > summary statistic over an in-kernel data structure in a single syscall, > because making a series of syscalls to examine every entry is slow and > racy. Isn't that exactly a job for an in-kernel virtual machine, and > could you not supply an eBPF program which the kernel runs on each entry > in the map, thus supporting people who want to calculate something else > (mean, min and max, whatever) instead of count? > Hi Edward, I like the approach, thanks for the suggestion. But I did not mention that we were using offloaded maps: Tracing the kernel would probably work for programs running on the host, but this is not a solution we could extend to hardware offload. Best regards, Quentin
