Hi, > -----Original Message----- > From: Honnappa Nagarahalli <[email protected]> > Sent: Friday, June 7, 2019 1:27 PM > To: Ananyev, Konstantin <[email protected]>; Phil Yang (Arm > Technology China) <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected]; > Gavin Hu (Arm Technology China) <[email protected]>; nd > <[email protected]>; nd <[email protected]> > 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
