Re: [PATCH v4 7/7] bbdev: add a lock option for enqueue/dequeue operation

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 6 Jul 2022 12:01:19 -0700
Tom Rix <trix@redhat.com> wrote:

> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> > Locking is not explicitly required but can be valuable
> > in case the application cannot guarantee to be thread-safe,
> > or specifically is at risk of using the same queue from multiple threads.
> > This is an option for PMD to use this.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> >   lib/bbdev/rte_bbdev.h | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
> > index b7ecf94..8e7ca86 100644
> > --- a/lib/bbdev/rte_bbdev.h
> > +++ b/lib/bbdev/rte_bbdev.h
> > @@ -407,6 +407,8 @@ struct rte_bbdev_queue_data {
> >   	struct rte_bbdev_stats queue_stats;  /**< Queue statistics */
> >   	enum rte_bbdev_enqueue_status enqueue_status; /**< Enqueue status when op is rejected */
> >   	bool started;  /**< Queue state */
> > +	rte_rwlock_t lock_enq; /**< lock protection for the Enqueue */
> > +	rte_rwlock_t lock_deq; /**< lock protection for the Dequeue */  
> 
> No.
> 
> This is a good idea but needs a use before introducing another element, 
> particularly a complicated one like locking
> 
> Tom

Having two locks on same cacheline will create lots of ping/pong false sharing.

Also, unless the reader is holding the lock for a significant fraction of the time
a regular spin lock will be faster.