Hi, > -----Original Message----- > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Sent: Friday, June 7, 2019 1:27 PM > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Phil Yang (Arm > Technology China) <phil.y...@arm.com>; dev@dpdk.org > Cc: tho...@monjalon.net; jer...@marvell.com; hemant.agra...@nxp.com; > Gavin Hu (Arm Technology China) <gavin...@arm.com>; nd > <n...@arm.com>; nd <n...@arm.com> > Subject: RE: [dpdk-dev] [PATCH v1 3/3] test/mcslock: add mcs queued lock > unit test > > > Hi, > > > > > > > > Unit test and perf test for MCS queued lock. > > > > Perf test is important of course, but first I think we need more > > robust functional test to make sure that lock does work properly. > > At least something like ticketlock test but probably with bigger > > number of iterations. > > 10K seems quite small here. Yes. I agree. I think we should also consider the total time consuming of the test. As more cores are involved in the lock contention, more time is required to complete the test.
> > In fact with this one we'll have 3 lock methods, I think it makes > > sense to have one united UT framework for them, so only actual > > lock/unlock would be different. +1. Since the APIs of MCS lock is different with spinlock and ticket lock, so I am wondering that what will this united UT framework look like? Will it be the same test case that integrates 3 sets of lock tests running with different cmd line? > +1 > > > Konstantin > > > > > > > <snip> Thanks, Phil Yang
