Hi,
I guess your proposal is to let the user application to handle all the
concurrency using RCU and locks. That could be complementary
and orthogonal to our current implementation. User could choose to do this way
if TSX is not available, and if they want more control over the
concurrency impl
Hi Yipeng,
I agree with you on RCU. It solves only part of the problem and
requires application involvement. Use of atomics is required to solve few more
problems.
Not solving the preemptible writer issue will change the behavior for existing
applications, is that ok?
I will submit a R
Hi, Honnappa,
Thanks for the comment.
RCU can handle one of the currency issue (key deletion while lookup) that has
been discussed before, but we think it is not easy for RCU-alone to
protect reader from cuckoo path displacement. Also, RCU solution requires user
interaction.
We agree that the
Hi Yipeng/Pablo,
Apologies for my delayed comments
-Original Message-
From: Yipeng Wang
Sent: Monday, July 9, 2018 5:45 AM
To: pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; yipeng1.w...@intel.com; bruce.richard...@intel.com; Honnappa
Nagarahalli ; vgu...@caviumnetworks.com;
This patch set adds the read-write concurrency support in rte_hash.
A new flag value is added to indicate if read-write concurrency is needed
during creation time. Test cases are implemented to do functional and
performance tests.
The new concurrency model is based on rte_rwlock. When Intel TSX is
5 matches
Mail list logo