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

[Ing . Alfonso Kuen Arroyo]

On Tue Sep 01, 2026, Maurizio Lombardi wrote:
> #define NVMET_TCP_MAXH2CDATA 0x400000 /* 16M arbitrary limit */
>
> So the comment should be fixed, it says NVMET_TCP_MAXH2CDATA is 16M.

Agreed - the value is 4 MiB and the comment is stale; it predates this
patch. I'll send a separate one-line patch for the comment rather than
fold an unrelated change into this one.

> 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?

It doesn't enforce it, and this patch doesn't add enforcement. MDTS is a
limit the host is required to honour (the base spec says the host shall
not submit a command exceeding it), and nvmet has no per-command check
against it, neither in the core nor in the transports.

What the target does have is the hard limit in nvmet_tcp_map_data():
since 4a3f00262a04 a data length above NVMET_TCP_MAXH2CDATA fails with
NVME_SC_SGL_INVALID_DATA | DNR before any buffer is allocated. So today
there are two numbers: the one the target will actually accept (4 MiB)
and the one it advertises (none). The patch makes them the same number,
so a compliant host never builds the command that the second check would
reject. With MDTS = 4 MiB, a 2 MiB command is within the limit and is
served normally; a command above the limit from a host that ignores MDTS
is rejected by the existing map_data check exactly as it is now - only
with a reason the host could have known in advance.

If you'd rather see the advertised limit derived from
NVMET_TCP_MAXH2CDATA directly (so the two cannot drift) instead of the
constant I used, I'm happy to respin as v4 that way.

Alfonso