From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, "Abdullah Ömer Yamaç" <omer.yamac@ceng.metu.edu.tr>,
"Yipeng Wang" <yipeng1.wang@intel.com>,
"Sameh Gobriel" <sameh.gobriel@intel.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"Vladimir Medvedkin" <vladimir.medvedkin@intel.com>,
"David Marchand" <david.marchand@redhat.com>,
"Abdullah Ömer Yamaç" <aomeryamac@gmail.com>
Subject: Re: [PATCH v2] lib/hash: new feature adding existing key
Date: Thu, 3 Oct 2024 15:37:21 -0700 [thread overview]
Message-ID: <20241003153721.2eb45ebd@hermes.local> (raw)
In-Reply-To: <5156487.LM0AJKV5NW@thomas>
On Fri, 16 Feb 2024 13:43:52 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> Any review please?
> If maintainers agree with the idea, we should announce the ABI change.
>
>
> 23/10/2023 10:29, Abdullah Ömer Yamaç:
> > From: Abdullah Ömer Yamaç <omer.yamac@ceng.metu.edu.tr>
> >
> > In some use cases inserting data with the same key shouldn't be
> > overwritten. We use a new flag in this patch to disable overwriting
> > data for the same key.
> >
> > Signed-off-by: Abdullah Ömer Yamaç <omer.yamac@ceng.metu.edu.tr>
> >
> > ---
> > Cc: Yipeng Wang <yipeng1.wang@intel.com>
> > Cc: Sameh Gobriel <sameh.gobriel@intel.com>
> > Cc: Bruce Richardson <bruce.richardson@intel.com>
> > Cc: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> > Cc: David Marchand <david.marchand@redhat.com>
> > ---
> > lib/hash/rte_cuckoo_hash.c | 10 +++++++++-
> > lib/hash/rte_cuckoo_hash.h | 2 ++
> > lib/hash/rte_hash.h | 4 ++++
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
> > index 19b23f2a97..fe8f21bee4 100644
> > --- a/lib/hash/rte_cuckoo_hash.c
> > +++ b/lib/hash/rte_cuckoo_hash.c
> > @@ -32,7 +32,8 @@
> > RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY | \
> > RTE_HASH_EXTRA_FLAGS_EXT_TABLE | \
> > RTE_HASH_EXTRA_FLAGS_NO_FREE_ON_DEL | \
> > - RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF)
> > + RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF | \
> > + RTE_HASH_EXTRA_FLAGS_DISABLE_UPDATE_EXISTING_KEY)
> >
> > #define FOR_EACH_BUCKET(CURRENT_BKT, START_BUCKET) \
> > for (CURRENT_BKT = START_BUCKET; \
> > @@ -148,6 +149,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
> > unsigned int readwrite_concur_support = 0;
> > unsigned int writer_takes_lock = 0;
> > unsigned int no_free_on_del = 0;
> > + unsigned int no_update_data = 0;
> > uint32_t *ext_bkt_to_free = NULL;
> > uint32_t *tbl_chng_cnt = NULL;
> > struct lcore_cache *local_free_slots = NULL;
> > @@ -216,6 +218,9 @@ rte_hash_create(const struct rte_hash_parameters *params)
> > no_free_on_del = 1;
> > }
> >
> > + if (params->extra_flag & RTE_HASH_EXTRA_FLAGS_DISABLE_UPDATE_EXISTING_KEY)
> > + no_update_data = 1;
> > +
> > /* Store all keys and leave the first entry as a dummy entry for lookup_bulk */
> > if (use_local_cache)
> > /*
> > @@ -428,6 +433,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
> > h->ext_table_support = ext_table_support;
> > h->writer_takes_lock = writer_takes_lock;
> > h->no_free_on_del = no_free_on_del;
> > + h->no_update_data = no_update_data;
> > h->readwrite_concur_lf_support = readwrite_concur_lf_support;
> >
> > #if defined(RTE_ARCH_X86)
> > @@ -707,6 +713,8 @@ search_and_update(const struct rte_hash *h, void *data, const void *key,
> > k = (struct rte_hash_key *) ((char *)keys +
> > bkt->key_idx[i] * h->key_entry_size);
> > if (rte_hash_cmp_eq(key, k->key, h) == 0) {
> > + if (h->no_update_data == 1)
> > + return -EINVAL;
This is buggy, the caller assumes -1 on error in several places.
See:
ret = search_and_update(h, data, key, prim_bkt, sig);
if (ret != -1) {
__hash_rw_writer_unlock(h);
*ret_val = ret;
return 1;
}
These paths would exercised when table had to expand.
Also any new functionality like this would need tests in functional test.
prev parent reply other threads:[~2024-10-03 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 7:26 [PATCH] lib/hash: new feature adding existing key Abdullah Ömer Yamaç
2023-03-13 7:35 ` Abdullah Ömer Yamaç
2023-03-13 15:48 ` Stephen Hemminger
2023-09-29 15:42 ` David Marchand
2023-10-23 8:11 ` [PATCH v2] " Abdullah Ömer Yamaç
2023-10-23 8:29 ` Abdullah Ömer Yamaç
2024-02-16 12:43 ` Thomas Monjalon
2024-10-03 22:37 ` Stephen Hemminger [this message]
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=20241003153721.2eb45ebd@hermes.local \
--to=stephen@networkplumber.org \
--cc=aomeryamac@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=omer.yamac@ceng.metu.edu.tr \
--cc=sameh.gobriel@intel.com \
--cc=thomas@monjalon.net \
--cc=vladimir.medvedkin@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.