Hi,
On Tue, Dec 02, 2014 at 03:02:17AM +0100, Lennart Poettering wrote:
> On Mon, 17.11.14 12:31, Rui Miguel Silva (rmf...@gmail.com) wrote:
>
> Heya,
>
> > > > - technical debt, if in the future the filter mechanism is change
> > > > by
> > > > other than bloom.
> > > > so bloom maybe just be replaced with only generic filter could make more
> > > > sense?
> > >
> > > What do you mean by "only generic filter"?
> > >
> > Maybe I did not explain myself well, what I mean is:
> > Imagine that ahead we find that instead of bloom filtering mechanism, for
> > example, cuckoo filters are more eficient. The api have the filter
> > structs called struct kdbus_bloom_filter, my suggestion was to just change
> > that to struct kdbus_filter (and no attach to filter specific
> > implementation). Since they are very generic (generation and a data field)
> > and for the kdbus it is just a check between a mask and a filter.
>
> I had a closer look at cuckoo filters now. The lookup logic is quite
> different from bloom filters and involves iterating through "entries"
> of a bucket. Now, I am not convinced that Cuckoo filters are really
> something we want to do in kdbus, but should we determine one day that
> they in fact are, then the kernel side matching of filter against mask
> needs to look very different anyway, with different data
> structures. And in that case we really should define new items for
> that, that should not overload the existing kdbus_bloom_filter
> structures but be seperate, new structs.
>
> Hope this makes sense,
Yes, it make, thanks.
Cheers,
Rui
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
