>>
>> Another comment is as you know we also have a new extension to rte_hash
>> to enable extendable buckets and partial-key hashing. Thanks for the
>> comments btw. Could you check if your lockless scheme also applies to
>> those extensions?
>Thank you for reminding me on this. I thought I had co
>
> Hi Honnappa,
>
> Reply inlined:
Hi Yipeng,
Thank you so much for reviewing.
>
> >-Original Message-
> >
> >Currently, reader-writer concurrency problems in rte_hash are
> >addressed using reader-writer locks. Use of reader-writer locks
> >results in following issues:
> >
Hi Honnappa,
Reply inlined:
>-Original Message-
>
>Currently, reader-writer concurrency problems in rte_hash are
>addressed using reader-writer locks. Use of reader-writer locks
>results in following issues:
>
>1) In many of the use cases for the hash table, writer threads
Hi Bruce/Pablo,
I need to get this into 18.11, appreciate any review/feedback soon.
Thank you,
Honnappa
> -Original Message-
> From: Honnappa Nagarahalli
> Sent: Friday, September 14, 2018 4:19 PM
> To: Honnappa Nagarahalli ;
> bruce.richard...@intel.com; pablo.de.lara.gua...@intel.co
I have added the memory ordering ladder diagrams to the DPDK summit slides to
help understand the changes. The slides are available at:
https://dpdkuserspace2018.sched.com/event/G44w/lock-free-read-write-concurrency-in-rtehash.
Please look at the backup slides.
Thank you,
Honnappa
-Origina
Currently, reader-writer concurrency problems in rte_hash are
addressed using reader-writer locks. Use of reader-writer locks
results in following issues:
1) In many of the use cases for the hash table, writer threads
are running on control plane. If the writer is preemp
6 matches
Mail list logo
