[dpdk-dev] [EXT] [PATCH v3 6/6] spinlock: ticket based to improve fairness

Jerin Jacob Kollanukkaran jerinj at marvell.com
Thu Dec 27 13:08:26 CET 2018


On Thu, 2018-12-27 at 10:05 +0000, Gavin Hu (Arm Technology China)
wrote:
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran <jerinj at marvell.com>
> > Sent: Thursday, December 27, 2018 2:58 PM
> > To: Gavin Hu (Arm Technology China) <Gavin.Hu at arm.com>; 
> > dev at dpdk.org
> > Cc: david.marchand at redhat.com; chaozhu at linux.vnet.ibm.com; nd
> > <nd at arm.com>; bruce.richardson at intel.com; thomas at monjalon.net;
> > Joyce
> > Kong (Arm Technology China) <Joyce.Kong at arm.com>;
> > hemant.agrawal at nxp.com; stephen at networkplumber.org; Honnappa
> > Nagarahalli <Honnappa.Nagarahalli at arm.com>
> > Subject: Re: [EXT] [PATCH v3 6/6] spinlock: ticket based to improve
> > fairness
> > 
> > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote:
> > > ---------------------------------------------------------------
> > > ----
> > > ---
> > > From: Joyce Kong <joyce.kong at arm.com>
> > > 
> > > The old implementation is unfair, some threads may take locks
> > > aggressively
> > 
> > I think, one issue here is x86 and ppc follows traditional spinlock
> > and
> > arm64 will be following ticket lock for spinlock implementation.
> > This would change application behaviour on arm64 compared to x86
> > and
> > ppc.
> > 
> > How about having a separate API for ticket lock? That would give,
> > # application choice to use the locking strategy
> > # application behaviour will be same across all arch.
> 
> Ok, will do in v4 to have a new named rte_ticket_spinlock API.

I would prefer rte_ticketlock_[lock/unlock/trylock/is_locked] name
instead of rte_ticket_spinlock_lock etc to reduce the length of the
API.






More information about the dev mailing list