Re: [dpdk-dev] [RFC 0/3] RCU integration with hash library

["Wang, Yipeng1" <yipeng1.wang@intel.com>]

>-----Original Message-----
>From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Dharmik Thakkar
>Sent: Saturday, August 31, 2019 11:58 PM
>Cc: dev@dpdk.org; honnappa.nagarahalli@arm.com; ruifeng.wang@arm.com; Dharmik Thakkar <dharmik.thakkar@arm.com>
>Subject: [dpdk-dev] [RFC 0/3] RCU integration with hash library
>
>This patchset integrates RCU QSBR support with hash library.
>
>Note: This patchset has dependency on another patchset:
>      https://patchwork.dpdk.org/cover/57813/
>
>Refer to RCU documentation to understand various aspects of
>integrating RCU library into other libraries.
>
>Introduce a new API rte_hash_rcu_qsbr_add for application to
>register a RCU variable that hash library will use.
>
>Add functional and performance test cases.
>
>Fix 'ixgbe_ethdev.h' to avoid multiple definitions of 'bool'.
>(Please note that this fix is temporary. Recommend suggesting better
>solution)
>
>Dharmik Thakkar (3):
>  net/ixgbe: avoid multpile definitions of 'bool'
>  lib/hash: integrate RCU QSBR
>  test/hash: add tests for integrated RCU QSBR
>
> app/test/test_hash_readwrite_lf.c    | 700 ++++++++++++++++++++++++++-
> drivers/net/ixgbe/ixgbe_ethdev.h     |   1 +
> lib/librte_hash/Makefile             |   2 +-
> lib/librte_hash/meson.build          |   2 +
> lib/librte_hash/rte_cuckoo_hash.c    | 354 +++++++++++++-
> lib/librte_hash/rte_cuckoo_hash.h    |   3 +
> lib/librte_hash/rte_hash.h           |  38 +-
> lib/librte_hash/rte_hash_version.map |   2 +-
> 8 files changed, 1065 insertions(+), 37 deletions(-)
>
>--
>2.17.1

[Wang, Yipeng] 
Hi Dharmik, thanks for the code!

I agree with Stephen that many people may not use RCU,
and when they use, they may want some control in the application level.
I can see the benefit to have certain RCU helper functions inside the
libraries when people indeed uses QSBR as you designed, 
but I am not sure if the benefits justify the effort to put it in many DPDK libraries.
It adds new APIs, requires future maintenance, and so on, given the
feature can be totally realized by the user application with small cost I assume.

I believe your plan is to add similar helper functions to many other libraries. I think
we could consider them as a single proposal, and it makes sense to bring it up to
the technical committee for a broader discussion.