Reason for eBPF maps to be BPF_MAP_TYPE_LRU_HASH

[ananthvanchip]

Hi,

I was looking at the code probe for net/http. I saw that all the maps are of type BPF_MAP_TYPE_LRU_HASH. I was thinking BPF_MAP_TYPE_HASH is a default option to have given that we are controlling what goes into the map and also deleting entries from the Map.

https://github.com/grafana/beyla/blob/5e33f07856878ccafabe882a841a3ede7f97f790/bpf/gotracer/go_nethttp.c

I also see that entries that are added to the map are clearly deleted. Still why is BPF_MAP_TYPE_LRU_HASH used? Is it safer to use it? Also are there other reason apart from being (Safe) to use them like memory efficient or performance efficient etc?

[grcevski]

Hi @ananthvanchip, it's mostly around safety of usage.

There's always limits on how many active kprobes can be run at a given and if the kernel is handling heavy memory pressure, some probes may not trigger. The limit on max kretprobes is more obvious, but there can be number of reasons a probe may not run, especially under heavy load. Since Beyla runs in daemonset mode and can run for the lifetime of the cluster, rather than a sidecar specific to an application, it's possible to permanently leak data in non LRU map over long periods of time if certain probes don't fire. With these kinds of leaks, eventually we'll break the overall functionality.

Once we started sharing maps between the uprobe based Go support and the kernel probes we moved all maps to LRU to not worry about missed probes. Having said that, it doesn't mean we can't revisit it and make certain maps go back to non-LRU, which would save some memory.