Hi Yipeng,
Thank you for the review, appreciate your efforts.
Thank you,
Honnappa
> >
> >RW concurrency is required with single writer and multiple reader
> >usecase as well. Hence, multi-writer should not be enabled by default
> >when RW concurrency is enabled.
> >
> >Fixes: f2e3001b53ec ("hash: support read/write concurrency")
> >Cc: yipeng1.w...@intel.com
> >
> >Signed-off-by: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> >Reviewed-by: Gavin Hu <gavin...@arm.com>
> >---
> > lib/librte_hash/rte_cuckoo_hash.c | 27 ++++++++++++++++-----------
> >lib/librte_hash/rte_cuckoo_hash.h | 2 ++
> > test/test/test_hash_readwrite.c | 6 ++++--
> > 3 files changed, 22 insertions(+), 13 deletions(-)
> >
> >+ uint8_t writer_takes_lock;
> >+ /**< Indicates if the writer threads need to take lock */
>
> [Wang, Yipeng]
> Our understanding is that the difference between writer_takes_lock and
> multi_writer_support flag now is that for the multi-writer case we still have
> the local cache for key-data pair slot. Please correct me if I am wrong.
Yes, that is correct. Need for lock and need for local cache are separated.
>
> But the name is confusing because writer_takes_lock implies multi-writer
> support. Especially the comment here says that writer needs a lock, which
> means multi-writer is supported. So conceptually it does not have different
> meaning than the multi_writer_support by just reading the name.
>
> If you want to distinguish these two implementation (with vs. without cache),
> maybe change the name of multi-writer flag to use_local_cache flag?
Agree, I will change the 'multi-writer' name to 'use_local_cache'. I will keep
the 'writer_takes_lock' flag.
> And the previous locking mechanism need to enable this flag for performance
> reasons, while the LF does not.
> Or just keep the cache for both cases, and I don't think the local cache will
> add too much overhead.
Agree, it might not make much of a performance difference. My goal is to reduce
the memory used when multi-writer is not enabled.
>
> > rte_hash_function hash_func; /**< Function used to calculate hash.
> */
> > uint32_t hash_func_init_val; /**< Init value used by hash_func. */
> > rte_hash_cmp_eq_t rte_hash_custom_cmp_eq; diff --git
> >a/test/test/test_hash_readwrite.c b/test/test/test_hash_readwrite.c
> >index 2a4f7b9..a8fadd0 100644
> >--- a/test/test/test_hash_readwrite.c
> >+++ b/test/test/test_hash_readwrite.c
> >@@ -122,10 +122,12 @@ init_params(int use_htm, int use_jhash)
> > if (use_htm)
> > hash_params.extra_flag =
> > RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT |
> >- RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY;
> >+ RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY |
> >+ RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD;
> [Wang, Yipeng]
> Could you double check that if current applications do not change their code,
> there is no functional issue will be introduced by this change, otherwise this
> would be an API change.
> I believe it will have performance implication though.
It is not advertised that multi-writer add is assumed when read-write
concurrency is enabled. I think we should be ok.
The functionality will be fine. Only difference is that the local-cache will
not be enabled without this flag. So, yes, there will be performance
implication.
>
> Otherwise I am OK with this patch.
