From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8D9F-0007ts-BF for qemu-devel@nongnu.org; Wed, 01 Jun 2016 16:53:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8D9B-0007sq-7O for qemu-devel@nongnu.org; Wed, 01 Jun 2016 16:53:52 -0400 Received: from mail-lf0-x241.google.com ([2a00:1450:4010:c07::241]:33181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8D9A-0007sc-W1 for qemu-devel@nongnu.org; Wed, 01 Jun 2016 16:53:49 -0400 Received: by mail-lf0-x241.google.com with SMTP id w16so3171971lfd.0 for ; Wed, 01 Jun 2016 13:53:48 -0700 (PDT) References: <1464138802-23503-1-git-send-email-cota@braap.org> <1464138802-23503-11-git-send-email-cota@braap.org> <574B487B.5080200@gmail.com> <877fea8yac.fsf@linaro.org> From: Sergey Fedorov Message-ID: <574F4B5A.6030309@gmail.com> Date: Wed, 1 Jun 2016 23:53:46 +0300 MIME-Version: 1.0 In-Reply-To: <877fea8yac.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: "Emilio G. Cota" , QEMU Developers , MTTCG Devel , Paolo Bonzini , Richard Henderson On 31/05/16 10:46, Alex Bennée wrote: > Sergey Fedorov 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