[SSSD] [PATCH 0/3]: New utility functions/headers

Simo Sorce simo at redhat.com
Mon Jan 9 19:13:08 UTC 2012


On Mon, 2012-01-09 at 13:49 -0500, Stephen Gallagher wrote:
> > > > > On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote:
> > > > > > >From [PATCH 0/0] A shared memory cache to perform better:
> > > > > > 
> 
> I have one other question about this patch. Would you mind identifying
> why you chose to go with the murmurhash3 algorithm instead of expanding
> dhash to expose its hash function publicly?

Yeah a few reasons:

- The algorithm in dhash was difficult to isolate in the code

- The dhash algorithm is tailored to handle tables that can be expanded
or reduced. We can't change the hash table size live as it would make
the client quite complex, so it wasn't a great match. (apologize if I
misunderstood something fundamental).

- I couldn't find out how good the algorithm in dhash was, so I looked
for what pass by the best algorithm today, and murmuhash3 seem to have
the best collision rate among known non-cryptographic fast-hash
functions.

- Using the dhash hash function would have required isolating it and
building it as a static library, because I do not want to add a library
dependency to sss_nss (our goal is to always keep clients as contained
as possible).

- This function is basically part of the ABI contract between the client
and the server side of sssd, and I didn't want to constrain dhash to
change the algorithm to a different one if that was required for
whatever reason. By keeping the 2 implementations unrelated dhash can be
changed at will without fearing consequences on the sssd client/server
ABI.


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list