All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maurizio Lombardi" <mlombard@arkamax.eu>
To: "Ing. Alfonso Kuen Arroyo" <gerencia@idkmanager.com>,
	"Maurizio Lombardi" <mlombard@arkamax.eu>
Cc: <hch@lst.de>, <sagi@grimberg.me>, <kch@nvidia.com>,
	<linux-nvme@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] nvmet-tcp: report a bounded MDTS instead of "no limit"
Date: Sat, 19 Sep 2026 09:53:33 +0200	[thread overview]
Message-ID: <DLJ4POIDTYXQ.2AOJP9BJAWEOX@arkamax.eu> (raw)
In-Reply-To: <178978683646.43804.6940923486189370705@idkmanager.com>

On Sat Sep 19, 2026 at 5:00 AM CEST, Ing. Alfonso Kuen Arroyo wrote:
> 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.

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."
(Identify – Identify Controller Data Structure, I/O Command Set
Independent)

Maybe it can be added separatedly with a dedicated patch.

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

Yes, but your patch sets NVMET_RDMA_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?

Maurizio


  reply	other threads:[~2026-09-19  7:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260828222356.1264-1-gerencia@idkmanager.com>
2026-08-29  1:39 ` [PATCH v2] nvmet-tcp: report a bounded MDTS instead of "no limit" Alfonso Kuen
2026-08-30 21:00   ` Sagi Grimberg
2026-08-30 21:02     ` Sagi Grimberg
2026-08-31  0:51   ` [PATCH v3] " Alfonso Kuen
2026-09-01 14:06     ` Maurizio Lombardi
2026-09-19  3:00       ` Ing. Alfonso Kuen Arroyo
2026-09-19  7:53         ` Maurizio Lombardi [this message]
2026-09-19  7:57           ` Maurizio Lombardi
2026-09-19 14:39             ` Ing. Alfonso Kuen Arroyo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DLJ4POIDTYXQ.2AOJP9BJAWEOX@arkamax.eu \
    --to=mlombard@arkamax.eu \
    --cc=gerencia@idkmanager.com \
    --cc=hch@lst.de \
    --cc=kch@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.