Add crud support for BPF_MAP_TYPE_BLOOM_FILTER #778
Conversation
|
Seems fine to me, thanks! Would you be able to add a test for this, by any chance? Also, can you please squash commits into a single one? |
|
Yes will do! |
barthr
force-pushed
the
master
branch
2 times, most recently
from
705a0e2
to
6eeeb30
Compare
|
So couple of things, when I started working on the tests I noticed that there is no way to do a proper lookup using the current lookup functionality. So I've added another function which should be used when u are using a bloom filter. I made it conform the spec as per (https://docs.kernel.org/bpf/map_bloom_filter.html). I also added some small refactoring. The PR turned out a little bit bigger than expected. Let me know what you think, I've only recently (this week) started to learn rust so it's all quite new to me. |
barthr
changed the title
|
I get your view. I tried looking into staying as close as possible to existing calls and existing API's however it would make the lookup code a bit ugly and violating the principle of least suprises. So that is why I opted for the specific method for the bloom filter map. However, there might also be solutions which use a more polymorphism approach. Like a trait with a default lookup method with custom overrides for certain map types. Another approach might be to have a lookup method which can take an extra value Argument and returns an int. I think for now this is out of scope. Unfortunately, the libbpf api is a bit funky since the same methods mean different things on different types, that is the downside of making everything a map I suppose. I will look at your comments tomorrow. |
Update map_key documentation to include bloom filter Add bloom filter test Add specific lookup for bloom filter Finalize PR Improve error message
Add a CHANGELOG entry for pull request #778, which addressed some issues when working with bloom filter maps. Signed-off-by: Daniel Müller <deso@posteo.net>
This PR fixes issue: #777