Message-ID: <aHqN_hpJl84T1Usi@arm.com>
Date: Fri, 18 Jul 2025 19:10:06 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Will Deacon <will@...nel.org>,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Heiko Carstens <hca@...ux.ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Leon Romanovsky <leon@...nel.org>,
	linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
	llvm@...ts.linux.dev, Ingo Molnar <mingo@...hat.com>,
	Bill Wendling <morbo@...gle.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>,
	Salil Mehta <salil.mehta@...wei.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Yisen Zhuang <yisen.zhuang@...wei.com>,
	Arnd Bergmann <arnd@...db.de>,
	Leon Romanovsky <leonro@...lanox.com>, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Mark Rutland <mark.rutland@....com>,
	Michael Guralnik <michaelgur@...lanox.com>, patches@...ts.linux.dev,
	Niklas Schnelle <schnelle@...ux.ibm.com>,
	Jijie Shao <shaojijie@...wei.com>
Subject: Re: [PATCH v3 6/6] IB/mlx5: Use __iowrite64_copy() for write
 combining stores

On Tue, Jul 15, 2025 at 08:52:00AM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 15, 2025 at 11:15:25AM +0100, Will Deacon wrote:
> > > Since STP was rejected alread we've only tested the Neon version. It
> > > does make a huge improvement, but it still somehow fails to combine
> > > rarely sometimes. The CPU is really bad at this :(
> > 
> > I think the thread was from last year so I've forgotten most of the
> > details, but wasn't STP rejected because it wasn't virtualisable? 
> 
> Yes, that was the claim.
> 
> > In which case, doesn't NEON suffer from exactly the same (or possibly
> > worse) problem?
> 
> In general yes, in specific no.

For a generic iowrite function, I wouldn't use STP or Neon since it may
end up being used on emulated MMIO.

BTW, for Neon, don't you need kernel_neon_begin/end()? This may have its
own overhead and also BUG_ON for different contexts. Again, not suitable
for a generic function.

Unfortunately, there's no way to know what this function is called on.
We might try to infer that the kernel started at EL2 but even that is
not entirely correct with nested virt. Or the OS may start at EL1 but
have direct access to mlx5 where we'd want the faster option.

> mlx5 (and other RDMA devices) have long used Neon for MMIO in
> userspace, so any VMM assigning mlx5 devices simply must make this
> work - it is already not optional. So we know that all VMs out there
> with mlx5 support neon for mlx5, and it is safe for mlx5 to use.

I can't think of any generic solution here, it may have to be a hack
specific to mlx5. We can also add add support for ST64B and have some
condition on system_supports_st64b() for future systems.

Even if we could handle virtualisation, I wonder whether
__iowrite64_copy() is the right function to implement 128-bit stores or
the larger 64-byte atomic stores. At least the comment for the generic
function suggests that it writes in 64-bit quantities. Some MMIO may
only handle such writes. A function like memcpy_toio() is more generic,
it doesn't imply any restrictions on the size of the writes (though I
think it guarantees natural alignment for the stores).

-- 
Catalin

Powered by blists - more mailing lists