Re: [PATCH v2] nvmet-tcp: report a bounded MDTS instead of "no limit"

[Sagi Grimberg]

On 31/08/2026 0:00, Sagi Grimberg wrote:
> On 29/08/2026 4:39, Alfonso Kuen wrote:
> > nvmet-tcp does not implement .get_mdts, so nvmet_ctrl_mdts() falls back
> > to the port value (0 by default) and identify-controller advertises "no
> > maximum data transfer size". The initiator believes it:
> > nvme_init_ctrl_finish() sets max_hw_sectors to UINT_MAX.
> >
> > What the initiator then issues is decided by the block layer. The
> > generic cap is 4 MiB (BLK_DEF_MAX_SECTORS_CAP), but a namespace that
> > advertises a large NOWS raises it: blk_validate_limits() takes
> > max_sectors from io_opt once io_opt exceeds that cap. On the array we
> > measured, NOWS is 65535, so io_opt is 32 MiB and the initiator emitted
> > 32 MiB commands -- from a controller that advertised no MDTS at all.
> >
> > The target cannot serve those, in one of two ways depending on the
> > kernel.
> >
> > Since 4a3f00262a04 ("nvmet-tcp: bound SGL data length before allocating
> > command buffers"), nvmet_tcp_map_data() rejects any len above
> > NVMET_TCP_MAXH2CDATA (4 MiB) with NVME_SC_SGL_INVALID_DATA | DNR, so the
> > command fails hard and deterministically. That is the right response to
> > an oversized command, but the initiator had no way to avoid sending it:
> > nothing advertised the limit it was exceeding.
> >
> > Before that commit the command reached sgl_alloc(), which for 32 MiB
> > needs 8192 scatterlist entries -- 256 KiB, an order-6 kmalloc. Under
> > fragmentation that fails, and it surfaces as NVME_SC_INTERNAL, a generic
> > status, so NVMe multipath does not fail the command over to another
> > path. A 1 MiB command needs 256 entries, 8 KiB, served from the
> > kmalloc-8k slab, which does not fail. That failure mode is intermittent
> > and load-dependent rather than deterministic; on a vendor kernel
> > predating the bound it cost us roughly 98 GiB of a 2 TiB image copy,
> > with the copy tool exiting 0.
> >
> > nvmet-rdma has advertised a bounded MDTS since "nvmet-rdma: Implement
> > get_mdts controller op" (Max Gurtovoy, Mar 2020), which left the other
> > transports untouched.
>
> Nit - instead of this patch reference - you should simply say:

Commit ec6d20e16c2d ("nvmet-rdma: Implement get_mdts controller op") left
the other transports untouched...

Other than that looks good
Reviewed-by: Sagi Grimberg <sagi@xxxxxxxxxxx>