[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalab
Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table
Wed, 1 Jun 2016 23:53:46 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
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 @@
>>> + * 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().
- Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table,
Sergey Fedorov <=