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

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 <[email protected]>