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

[Ing. Alfonso Kuen Arroyo <gerencia@idkmanager.com>]

On Sat Sep 19, 2026, Maurizio Lombardi wrote:
> Yes, but your patch sets NVMET_TCP_MAX_MDTS to 8, which means 1MiB, not
> 4MiB, so a 2MiB command should be rejected, even if it's under the
> MAXH2CDATA limit of 4MiB; or am I missing something?

You are not missing anything - I mixed the two numbers up in my previous
mail. The patch advertises MDTS = 8, i.e. 2^8 * 4 KiB = 1 MiB, the same
value nvmet-rdma reports, not the 4 MiB of NVMET_TCP_MAXH2CDATA. So with
the patch a 2 MiB command does exceed the advertised MDTS, and today the
target would still serve it: nothing in nvmet compares a command's
transfer length against MDTS, the only rejection is the 4 MiB bound in
nvmet_tcp_map_data(). Sorry for the confusion.

> And indeed this is what's missing, because the specification
> explicitely says that "if a command is submitted that exceeds [MDTS],
> then the command is aborted with a status code of Invalid Field in
> Command."
>
> Maybe it can be added separatedly with a dedicated patch.

Agreed on both counts. The enforcement belongs in the core rather than in
a transport - a transfer-length check against nvmet_ctrl_mdts() when the
request is initialised, returning NVME_SC_INVALID_FIELD | NVME_STATUS_DNR -
so that every transport with a get_mdts gets it for free. It is a separate
change with its own blast radius (it turns a currently-served oversized
command into a failed one for non-compliant hosts), so I would rather keep
this patch as the "advertise what we can serve" step and send the
enforcement as a follow-up on top of it. I can prepare that follow-up if
you and the maintainers think it is the right direction; otherwise I am
happy to leave it to whoever prefers to shape it.

Alfonso