RE: [PATCH 1/1] eal: correct memory ordering in MCS lock

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> On Mon, 3 Nov 2025 18:06:05 +0000
> Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:
> 
> > >
> > > On 11/3/25 11:07, Stephen Hemminger wrote:
> > > > On Mon, 3 Nov 2025 09:12:39 -0600
> > > > Wathsala Vithanage <wathsala.vithanage@arm.com> wrote:
> > > >
> > > >> MCS lock is broken, it's just a matter of time it will run into a deadlock.
> > > >>
> > > >> drivers/dma/cnxk is a user of MCS lock.
> > > > I am surprised that a driver would use mcslock.
> > > > MCSlock is targeted at case of large number of CPU's with lots of
> contention.
> > > > It will likely be slower than spinlock or ticketlock for the use case of driver.
> > > It appears in |drivers/dma/cnxk/cnxk_dmadev_fp.c|, perhaps the
> > > maintainer can clarify.
> > >
> >
> > If MCS lock is really broken, it needs to be fixed anyway.
> > It might be used by other third-party libs/apps that do use on DPDK.
> 
> 100% agree it must be fixed.
> It would be good to have test or static analysis tool that could validate all the lock
> types.

+1
Another option would be to have sort of stress test for all locking types we have in our UT.
At least for ring I found it very useful.