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

[Maurizio Lombardi]

On Mon Aug 31, 2026 at 2:51 AM CEST, 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 commit 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.

#define NVMET_TCP_MAXH2CDATA  0x400000 /* 16M arbitrary limit */

So the comment should be fixed, it says NVMET_TCP_MAXH2CDATA is 16M.

Also, it's not entirely clear to me how the target enforces this. Suppose an
host sends a 2 MiB command, violating the MDTS setting, what happens?

Maurizio