Re: [PATCH v1] mpt3sas: Limit NVMe request size to 2 MiB

[Keith Busch <kbusch@kernel.org>]

On Fri, Apr 10, 2026 at 06:11:22AM +0200, Damien Le Moal wrote:
> On 2026/04/09 20:42, Ranjan Kumar wrote:
> 
> >  		if (pcie_device->nvme_mdts)
> > -			lim->max_hw_sectors = pcie_device->nvme_mdts / 512;
> > +			lim->max_hw_sectors = min_t(u32,
> > +					pcie_device->nvme_mdts / 512,
> > +					(SZ_2M / 512) - 8);
> > +		else
> > +			lim->max_hw_sectors = (SZ_2M / 512) - 8;
> 
> I am very confused here: SZ_2MB assumes that you have an SSD with a minimum page
> size of 4K, which can fit 4K / 8 = 512 PRP entries, each referencing 4K (one
> page), so a maximum of 2MiB. However, if I am not mistaken, there is nothing in
> nvme specs that forces the MPS field to be 0 (which leads to a page size of 4K).
>
> So this seems incorrect to me, even though that will probably work for the vast
> majority of SSDs out there, some exotic ones will not be correctly supported.
> 
> Keith ? Am I missing something here ?
> 
> Or do we simply do not care about SSDs with a minimum page size > 4K having
> their maximum command size truncated ?

Spec doesn't require it, but industry converged on that as always being
the minimum supported page size. The nvme driver rejects any device that
doesn't support 4k pages because they can't be reliably supported on a
lot of archs, even ones with larger page sizes. So it should be a safe
assumption that everyone supports 4k since no on is complaining. :)

On the patch, I initially left the "- 8" in the calculation to account
for page offsets. But it's not necessary because that gets absorbed in
PRP1 within the command, so we'd have at most 512 entries in the PRP
list for a 2M transfer.