Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table

[Sergey Fedorov]

On 31/05/16 10:46, Alex Bennée wrote:
> Sergey Fedorov <address@hidden> writes:
>
>> On 25/05/16 04:13, Emilio G. Cota wrote:
>>> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
>>> new file mode 100644
>>> index 0000000..aec60aa
>>> --- /dev/null
>>> +++ b/include/qemu/qht.h
>>> @@ -0,0 +1,183 @@
>> (snip)
>>> +/**
>>> + * qht_init - Initialize a QHT
>>> + * @ht: QHT to be initialized
>>> + * @n_elems: number of entries the hash table should be optimized for.
>>> + * @mode: bitmask with OR'ed QHT_MODE_*
>>> + */
>>> +void qht_init(struct qht *ht, size_t n_elems, unsigned int mode);
>> First of all, thank you for spending your time on the documentation of
>> the API!
>>
>> I was just wondering if it could be worthwhile to pass a hash function
>> when initializing a QHT. Then we could have variants of qht_insert(),
>> qht_remove() and qht_lookup() which does not require a computed hash
>> value but call the function by themselves. This could make sense since a
>> hash value passed the the functions should always be exactly the same
>> for the same object.
> Wouldn't this be for an expansion of the API when we actually have
> something that would use it that way?
>

Yes, I think in "tb hash: track translated blocks with qht" we could just pass 
tb_hash_func() to qht_init().

Kind regards,
Sergey