From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de>
Cc: Keith Busch <kbusch@kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: ioccsz and iorcsz check failing
Date: Tue, 19 Dec 2023 19:24:17 +0200 [thread overview]
Message-ID: <d2754a5a-8162-4e66-89ba-466127eb7d3a@nvidia.com> (raw)
In-Reply-To: <0efbe093-6f9e-4026-92aa-3442bde68e7b@grimberg.me>
On 18/12/2023 18:04, Sagi Grimberg wrote:
>
>>> Is anything else in the identify wrong, or is it just these
>>> fabrics fields?
>>
>> So what I am seeing on the wire are a few fabrics commands (connect, get
>> property) followed by the nvme id ctrl command (opcode 0x6).
>>
>> nvmet: nvmet_req_init:962
>> nvmet: nvmet_parse_admin_cmd:1011
>> nvmet: nvmet_parse_discovery_cmd:359 opcode 6
>>
>> This calls then nvmet_execute_disc_identify, so adding
>>
>> --- a/drivers/nvme/target/discovery.c
>> +++ b/drivers/nvme/target/discovery.c
>> @@ -249,6 +249,7 @@ static void nvmet_execute_disc_identify(struct
>> nvmet_req *req)
>> {
>> struct nvmet_ctrl *ctrl = req->sq->ctrl;
>> struct nvme_id_ctrl *id;
>> + u32 cmd_capsule_size;
>> u16 status = 0;
>>
>> if (!nvmet_check_transfer_len(req, NVME_IDENTIFY_DATA_SIZE))
>> @@ -289,6 +290,17 @@ static void nvmet_execute_disc_identify(struct
>> nvmet_req *req)
>> id->sgls |= cpu_to_le32(1 << 2);
>> if (req->port->inline_data_size)
>> id->sgls |= cpu_to_le32(1 << 20);
>> + /*
>> + * Max command capsule size is sqe + in-capsule data size.
>> + * Disable in-capsule data for Metadata capable controllers.
>> + */
>> + cmd_capsule_size = sizeof(struct nvme_command);
>> + if (!ctrl->pi_support)
>> + cmd_capsule_size += req->port->inline_data_size;
>> + id->ioccsz = cpu_to_le32(cmd_capsule_size / 16);
>
> Yes, this is the culprit. Nice that it exposed a bug.
>
> There is no in-capsule data for discovery controllers afaict.
Also, the discovery controllers can't support PI AFAIK.
next prev parent reply other threads:[~2023-12-19 17:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 14:48 ioccsz and iorcsz check failing Daniel Wagner
2023-12-15 18:08 ` Keith Busch
2023-12-18 9:59 ` Sagi Grimberg
2023-12-18 13:57 ` Daniel Wagner
2023-12-18 16:04 ` Sagi Grimberg
2023-12-19 17:24 ` Max Gurtovoy [this message]
2023-12-19 19:59 ` Sagi Grimberg
2023-12-19 23:55 ` Max Gurtovoy
2023-12-20 0:10 ` Max Gurtovoy
2023-12-20 9:02 ` Daniel Wagner
2023-12-20 9:13 ` Sagi Grimberg
2023-12-19 17:28 ` Daniel Wagner
2023-12-19 18:54 ` Caleb Sander
2023-12-19 19:58 ` Sagi Grimberg
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=d2754a5a-8162-4e66-89ba-466127eb7d3a@nvidia.com \
--to=mgurtovoy@nvidia.com \
--cc=dwagner@suse.de \
--cc=hch@lst.de \
--cc=kbusch@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox