MapIterator doesn't terminate for heavily modified map about ebpf HOT 2 CLOSED

Given the current kernel interface, I'm not sure that there's any particularly tidy API we can build for arbitrary use-cases :/ If the BPF side constantly deletes elements, then dump of such maps from the userland side will behave very poorly indeed.. but that's just a limitation of that particular use case.

In Cilium, we just use MaxElems then have the ability to pass out some dump statistics at the end which includes various things, but in particular whether the dump ended up "incomplete", as measured by "we dumped MaxElems but didn't reach the end of the map". So, as a user, you have to know that the dump may not be complete, and handle this.

I think in the end, we will have to define the map iteration interface in such a way that we communicate to library users the kinds of behaviour you can expect, depending on what kind of other interactions are occurring concurrently on the map [either from userspace via this library, or from BPF progs running in the kernel]. These include:

• Is it possible to dump the "same" element twice for a given iteration (for some definition of "same")
• How strong of a guarantee do I get about whether I have a complete view of the map once the dump is done?
• What kind of ordering can you expect from the map?
• Likely some other considerations I didn't think of in the moment..

With regards to your example in the summary, this forces users to consider the size of the map. One could imagine instead an API where you create a dump object first, which has optional "max iterations" (default: MaxElems), then if someone really cares, they can limit the number of dumps. Then the actual iteration doesn't need to have this detail. This could be made optional via builder pattern, something like entries := NewDumper(...).WithMaxIterations(42). (Focus on the WithMaxIterations() bit; I didn't think closely about what the dump object creation looks like).

from ebpf.

So, as a user, you have to know that the dump may not be complete, and handle this.

There seem to be two possible actions: punt to the user by logging / bumping some metric or retry. If the solution is retry, the max iteration limit can always be MaxElems.

What am I missing? What does Cilium do? Do you ever iterate more often than MaxElems?

I think in the end, we will have to define the map iteration interface in such a way that we communicate to library users the kinds of behaviour you can expect

This boils down to what the kernel implements for each given map type, no? As far as I understand, the iteration count is only a problem for hash maps, array-like maps are fine.

For example, your list of questions for Array:

• No element dumped twice
• Always get a complete view
• Keys are ordered

And for Hash:

• No guarantee
• No guarantee
• Keys are not ordered

And who knows what LRU maps guarantee.

With regards to your example in the summary, this forces users to consider the size of the map.

Yes and you're right that it's not very nice. Reading your comment makes me think that (a) limiting each iterator to MaxElems and (b) documenting that hash maps can't be reliably iterated is the best we can do.

from ebpf.