[dpdk-dev] [PATCH v3 6/7] hash: enable lock-free reader-writer concurrency

Honnappa Nagarahalli Honnappa.Nagarahalli at arm.com
Wed Oct 17 15:54:46 CEST 2018


> >Subject: [PATCH v3 6/7] hash: enable lock-free reader-writer
> >concurrency
> >
> >Add the flag to enable reader-writer concurrency during run time. The
> >rte_hash_del_xxx APIs do not free the keystore element when this flag
> >is enabled. Hence a new API, rte_hash_free_key_with_position, to free
> >the key store element is added.
> >
> >Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
> >Reviewed-by: Gavin Hu <gavin.hu at arm.com>
> >Reviewed-by: Ola Liljedahl <ola.liljedahl at arm.com>
> >Reviewed-by: Steve Capper <steve.capper at arm.com>
> >Reviewed-by: Yipeng Wang <yipeng1.wang at intel.com>
> >
> >+/** Flag to support lock free reader writer concurrency. Writer can be
> >+ * single writer/multi writer.
> [Wang, Yipeng] "Writer can be multi-writer when the
> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD flag is also set."
Agree. What I am trying to say is that lock free reader writer concurrency is support for both single writer or multi writer use cases. This was one of your questions in the earlier version.

> >+ * Currently, extended bucket table feature is not supported with
> [Wang, Yipeng] "extendable bucket table", I also used wrong name sometimes
> but please use this one.
> >@@ -156,6 +169,10 @@ rte_hash_count(const struct rte_hash *h);
> >  * and should only be called from one thread by default.
> >  * Thread safety can be enabled by setting flag during
> >  * table creation.
> >+ * The writer needs to be aware if this API is called to update
> >+ * an existing entry. The application should free any memory
> >+ * allocated for the existing 'data' only after all the readers
> >+ * have stopped referrencing it.
> >  *
> [Wang, Yipeng]
> This comment to me is assuming a specific user use case, and not the library's
> responsibility.
> How about a more general description:
> If the added key is already in the table, the function will update the data of the
> key.
> In such case, it is the user's responsibility to properly handle the old data if
> the old data is still being referenced by other threads.
> Please let me know if I understand it wrong.
Your understanding is correct. I have changed the wordings.



More information about the dev mailing list