DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Fu, Qiaobin" <qiaobinf@bu.edu>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Michel Machado <michel@digirati.com.br>,
	"Doucette, Cody, Joseph" <doucette@bu.edu>,
	"Wang, Yipeng1" <yipeng1.wang@intel.com>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	"Gobriel, Sameh" <sameh.gobriel@intel.com>,
	"Tai, Charlie" <charlie.tai@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v2] hash table: add an iterator over conflicting	entries
Date: Fri, 17 Aug 2018 02:33:36 +0000	[thread overview]
Message-ID: <AM6PR08MB3672D768972DF868A471CF89983D0@AM6PR08MB3672.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <B12F9F5F-2F3B-4E26-B3B6-0680075C2938@bu.edu>

Hi Fu,
	Thank you for the patch. I have few comments below.

Thank you,
Honnappa

-----Original Message-----
From: dev <dev-bounces@dpdk.org> On Behalf Of Fu, Qiaobin
Sent: Thursday, August 16, 2018 2:30 AM
To: Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
Cc: dev@dpdk.org; Michel Machado <michel@digirati.com.br>; Doucette, Cody, Joseph <doucette@bu.edu>; Wang, Yipeng1 <yipeng1.wang@intel.com>; Wiles, Keith <keith.wiles@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>; Tai, Charlie <charlie.tai@intel.com>; Stephen Hemminger <stephen@networkplumber.org>; Fu, Qiaobin <qiaobinf@bu.edu>
Subject: [dpdk-dev] [PATCH v2] hash table: add an iterator over conflicting entries

Function rte_hash_iterate_conflict_entries() iterates over the entries that conflict with an incoming entry.

Iterating over conflicting entries enables one to decide if the incoming entry is more valuable than the entries already in the hash table. This is particularly useful after an insertion failure.

v2:
* Fix the style issue

* Make the API more universal

Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
Reviewed-by: Cody Doucette <doucette@bu.edu>
Reviewed-by: Michel Machado <michel@digirati.com.br>
Reviewed-by: Keith Wiles <keith.wiles@intel.com>
Reviewed-by: Yipeng Wang <yipeng1.wang@intel.com>
---
 lib/librte_hash/rte_cuckoo_hash.c    | 81 ++++++++++++++++++++++++++++
 lib/librte_hash/rte_hash.h           | 41 ++++++++++++++
 lib/librte_hash/rte_hash_version.map |  7 +++
 3 files changed, 129 insertions(+)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index a07543a29..de69f9966 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -42,6 +42,13 @@ static struct rte_tailq_elem rte_hash_tailq = {  };
 EAL_REGISTER_TAILQ(rte_hash_tailq)
 
+struct rte_hash_iterator_conflict_entries_state {
+	const struct rte_hash *h;
+	uint32_t              vnext;
+	uint32_t              primary_bidx;
+	uint32_t              secondary_bidx;
+};
+
 struct rte_hash *
 rte_hash_find_existing(const char *name)  { @@ -1160,3 +1167,77 @@ rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, uint32
 
 	return position - 1;
 }
+
+/* Get the primary bucket index given the precomputed hash value. */ 
+static inline uint32_t rte_hash_get_primary_bucket(const struct 
+rte_hash *h, hash_sig_t sig) {
+	return sig & h->bucket_bitmask;
+}
+
+/* Get the secondary bucket index given the precomputed hash value. */ 
+static inline uint32_t rte_hash_get_secondary_bucket(const struct 
+rte_hash *h, hash_sig_t sig) {
+	return rte_hash_secondary_hash(sig) & h->bucket_bitmask; }
+
IMO, to keep the code consistent, we do not need to have the above 2 functions.

+int32_t __rte_experimental
+rte_hash_iterator_conflict_entries_init(const struct rte_hash *h,
+	hash_sig_t sig, struct rte_conflict_iterator_state *state) {
+	struct rte_hash_iterator_conflict_entries_state *__state;
+
+	RETURN_IF_TRUE(((h == NULL) || (state == NULL)), -EINVAL);
+
+	__state = (struct rte_hash_iterator_conflict_entries_state *)state;
+	__state->h = h;
+	__state->vnext = 0;
+	__state->primary_bidx = rte_hash_get_primary_bucket(h, sig);
+	__state->secondary_bidx = rte_hash_get_secondary_bucket(h, sig);
+
+	return 0;
+}
+
+int32_t __rte_experimental
+rte_hash_iterate_conflict_entries(struct rte_conflict_iterator_state *state,
+	const void **key, const void **data)
+{
+	struct rte_hash_iterator_conflict_entries_state *__state;
+
+	RETURN_IF_TRUE(((state == NULL) || (key == NULL) ||
+		(data == NULL)), -EINVAL);
+
+	__state = (struct rte_hash_iterator_conflict_entries_state *)state;
+
+	while (__state->vnext < RTE_HASH_BUCKET_ENTRIES * 2) {
+		uint32_t bidx = (__state->vnext < RTE_HASH_BUCKET_ENTRIES) ?
+			__state->primary_bidx : __state->secondary_bidx;
+		uint32_t next = __state->vnext & (RTE_HASH_BUCKET_ENTRIES - 1);
+		uint32_t position = __state->h->buckets[bidx].key_idx[next];
+		struct rte_hash_key *next_key;
+		/*
+		 * The test below is unlikely because this iterator is meant
+		 * to be used after a failed insert.
+		 * */
+		if (unlikely(position == EMPTY_SLOT))
+			goto next;
+
+		/* Get the entry in key table. */
+		next_key = (struct rte_hash_key *) (
+			(char *)__state->h->key_store +
+			position * __state->h->key_entry_size);
+		/* Return key and data. */
+		*key = next_key->key;
+		*data = next_key->pdata;
+
+next:
+		/* Increment iterator. */
+		__state->vnext++;
+
+		if (likely(position != EMPTY_SLOT))
+			return position - 1;
+	}
+
+	return -ENOENT;
+}


I think, we can make this API similar to 'rte_hash_iterate'. I suggest the following API signature:

int32_t
rte_hash_iterate_conflict_entries (const struct rte_hash *h, const void **key, void **data, hash_sig_t sig, uint32_t *next)

primary and secondary bucket indices can be calculated from 'sig', 'next' is the iterator for the entries in the bucket (or conflicted entries). 'next' can go across the primary and secondary buckets. This will avoid creating 'rte_hash_iterator_conflict_entries_init' API.

I also suggest to change the API name to ' rte_hash_iterate_bucket_entries' - 'bucket' is a well understood term in the context of hash algorithms.

Do we also need to have 'rte_hash_iterate_conflict_entries_with_hash' API?

diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h index f71ca9fbf..7ecb6a7eb 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -61,6 +61,11 @@ struct rte_hash_parameters {
 /** @internal A hash table structure. */  struct rte_hash;
 
+/** @internal A hash table conflict iterator state structure. */ struct 
+rte_conflict_iterator_state {
+	uint8_t space[64];
+};
+

The size depends on the current size of the state, which is subject to change with the algorithm used.

 /**
  * Create a new hash table.
  *
@@ -419,6 +424,42 @@ rte_hash_lookup_bulk(const struct rte_hash *h, const void **keys,
  */
 int32_t
 rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, uint32_t *next);
+
+/**
+ * Initialize the iterator over entries that conflict with a new entry.
+ *
+ * @param h
+ *   Hash table to iterate
+ * @param sig
+ *   Precomputed hash value for the new entry.
+ * @return
+ *   - 0 if successful.
+ *   - -EINVAL if the parameters are invalid.
+ */
+int32_t __rte_experimental
+rte_hash_iterator_conflict_entries_init(const struct rte_hash *h,
+	hash_sig_t sig, struct rte_conflict_iterator_state *state);
+
+/**
+ * Iterate over entries that conflict with a new entry.
+ *
+ * @param state
+ *   Pointer to the iterator state.
+ * @param key
+ *   Output containing the key where current iterator
+ *   was pointing at.
+ * @param data
+ *   Output containing the data associated with key.
+ *   Returns NULL if data was not stored.
+ * @return
+ *   Position where key was stored, if successful.
+ *   - -EINVAL if the parameters are invalid.
+ *   - -ENOENT if there is no more conflicting entries.
+ */
+int32_t __rte_experimental
+rte_hash_iterate_conflict_entries(struct rte_conflict_iterator_state *state,
+	const void **key, const void **data);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_hash/rte_hash_version.map b/lib/librte_hash/rte_hash_version.map
index 52a2576f9..c1c343e52 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -45,3 +45,10 @@ DPDK_16.07 {
 	rte_hash_get_key_with_position;
 
 } DPDK_2.2;
+
+EXPERIMENTAL {
+	global:
+
+	rte_hash_iterator_conflict_entries_init;
+	rte_hash_iterate_conflict_entries;
+};
--
2.17.1

  reply	other threads:[~2018-08-17  2:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-16  7:30 Fu, Qiaobin
2018-08-17  2:33 ` Honnappa Nagarahalli [this message]
2018-08-17 13:34   ` Michel Machado
2018-08-17 19:41     ` Honnappa Nagarahalli
2018-08-18 22:45       ` Michel Machado
2018-08-18 23:08       ` Michel Machado
2018-08-21  5:10         ` Honnappa Nagarahalli
2018-08-21 12:41           ` Michel Machado
2018-08-21 23:42             ` Honnappa Nagarahalli
2018-08-24  0:33               ` Wang, Yipeng1
2018-08-24 12:34                 ` Michel Machado
2018-08-27  3:12                   ` Honnappa Nagarahalli
2018-08-27 18:27                     ` Michel Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR08MB3672D768972DF868A471CF89983D0@AM6PR08MB3672.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=charlie.tai@intel.com \
    --cc=dev@dpdk.org \
    --cc=doucette@bu.edu \
    --cc=keith.wiles@intel.com \
    --cc=michel@digirati.com.br \
    --cc=nd@arm.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=qiaobinf@bu.edu \
    --cc=sameh.gobriel@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=yipeng1.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).