jalon [mailto:tho...@monjalon.net]
> >Sent: Thursday, July 12, 2018 1:30 PM
> >To: Wang, Yipeng1 ; Stephen Hemminger
> >
> >Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> >Richardson, Bruce ;
> >honnappa.nagaraha...@arm.com; vgu...@caviumnetworks.com;
> >brijesh.
uly 12, 2018 1:30 PM
>To: Wang, Yipeng1 ; Stephen Hemminger
>
>Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
>Richardson, Bruce ;
>honnappa.nagaraha...@arm.com; vgu...@caviumnetworks.com;
>brijesh.s.si...@gmail.com; Wang, Ren ;
>Gobriel, Sameh ; Tai, Charlie
>Subject: Re: [d
12/07/2018 03:22, Wang, Yipeng1:
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>
> > For small windows, reader-writer locks are slower than a spin lock
> > because there are more cache bounces.
>
> Hi, Stephen,
>
> You are correct and we understand that spinlock might be slightly
Hi, Stephen,
You are correct and we understand that spinlock might be slightly faster than
counter based rwlock in this case. However, the counter based rwlock is the
exception path when TSX fails.
If performance of this exception path is a big concern, a more optimal
read-write lock scheme (e
On Tue, 10 Jul 2018 09:59:58 -0700
Yipeng Wang wrote:
> +
> +static inline void
> +__hash_rw_reader_lock(const struct rte_hash *h)
> +{
> + if (h->readwrite_concur_support && h->hw_trans_mem_support)
> + rte_rwlock_read_lock_tm(h->readwrite_lock);
> + else if (h->readwrite_con
The existing implementation of librte_hash does not support read-write
concurrency. This commit implements read-write safety using rte_rwlock
and rte_rwlock TM version if hardware transactional memory is available.
Both multi-writer and read-write concurrency is protected by rte_rwlock
now. The x8
6 matches
Mail list logo
