DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH] hash: fix incorrect lookup if key is all zero
Date: Thu, 17 Sep 2015 10:04:18 +0100	[thread overview]
Message-ID: <1442480658-4741-1-git-send-email-pablo.de.lara.guarch@intel.com> (raw)

If user has not added an all zero key in the hash table,
and tries to look it up, it results in an incorrect hit,
as dummy slot in the key table has all zero as well.

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 doc/guides/rel_notes/release_2_2.rst |  5 +++++
 lib/librte_hash/rte_cuckoo_hash.c    | 27 +++++++++++++++++----------
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 682f468..e4460f7 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -8,6 +8,11 @@ New Features
 Resolved Issues
 ---------------
 
+* **hash: Fixed incorrect lookup if key is all zero. **
+
+Fixed issue in hash library that occurred if an all zero
+key was not added in the table and the key was looked up,
+resulting in an incorrect hit.
 
 Known Issues
 ------------
diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index 7019763..62d7143 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -861,15 +861,22 @@ lookup_stage2(unsigned idx, hash_sig_t prim_hash, hash_sig_t sec_hash,
 /* Lookup bulk stage 3: Check if key matches, update hit mask and return data */
 static inline void
 lookup_stage3(unsigned idx, const struct rte_hash_key *key_slot, const void * const *keys,
-		void *data[], uint64_t *hits, const struct rte_hash *h)
+		const int32_t *positions, void *data[], uint64_t *hits,
+		const struct rte_hash *h)
 {
 	unsigned hit;
+	unsigned key_idx;
 
 	hit = !h->rte_hash_cmp_eq(key_slot->key, keys[idx], h->key_len);
 	if (data != NULL)
 		data[idx] = key_slot->pdata;
 
-	*hits |= (uint64_t)(hit) << idx;
+	key_idx = positions[idx] + 1;
+	/*
+	 * If key index is 0, force hit to be 0, in case key to be looked up
+	 * is all zero (as in the dummy slot), which would result in a wrong hit
+	 */
+	*hits |= (uint64_t)(hit && !!key_idx)  << idx;
 }
 
 static inline void
@@ -961,8 +968,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void **keys,
 		lookup_stage2(idx21, primary_hash21, secondary_hash21,
 			primary_bkt21, secondary_bkt21,	&k_slot21, positions,
 			&extra_hits_mask, key_store, h);
-		lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-		lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+		lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+		lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
 	}
 
 	k_slot30 = k_slot20, k_slot31 = k_slot21;
@@ -988,8 +995,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void **keys,
 	lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
 		secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
 		key_store, h);
-	lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-	lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+	lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+	lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
 
 	k_slot30 = k_slot20, k_slot31 = k_slot21;
 	idx30 = idx20, idx31 = idx21;
@@ -1009,14 +1016,14 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void **keys,
 	lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
 		secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
 		key_store, h);
-	lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-	lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+	lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+	lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
 
 	k_slot30 = k_slot20, k_slot31 = k_slot21;
 	idx30 = idx20, idx31 = idx21;
 
-	lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-	lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+	lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+	lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
 
 	/* ignore any items we have already found */
 	extra_hits_mask &= ~hits;
-- 
2.4.2

             reply	other threads:[~2015-09-17  9:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17  9:04 Pablo de Lara [this message]
2015-09-17 10:14 ` Thomas Monjalon
2015-09-17 10:30 ` [dpdk-dev] [PATCH v2] " Pablo de Lara
2015-09-28 10:29   ` Bruce Richardson
2015-11-04  0:07     ` Thomas Monjalon

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=1442480658-4741-1-git-send-email-pablo.de.lara.guarch@intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    /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).