From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH] nvme: don't memset() the normal read/write command
Date: Wed, 13 Oct 2021 06:58:22 +0200 [thread overview]
Message-ID: <20211013045822.GA24761@lst.de> (raw)
In-Reply-To: <b38d0d5c-191a-68cd-f6fb-5662706dc366@kernel.dk>
I like this in general, but some comments below:
> cmnd->rw.opcode = op;
> + cmnd->rw.flags = 0;
> + cmnd->rw.command_id = 0;
The command_id is always set in nvme_setup_cmd, so no need to clear it
here.
> cmnd->rw.nsid = cpu_to_le32(ns->head->ns_id);
> + cmnd->rw.rsvd2 = 0;
There should be no need to clear this reserved space.
> + cmnd->rw.metadata = 0;
> cmnd->rw.slba = cpu_to_le64(nvme_sect_to_lba(ns, blk_rq_pos(req)));
> cmnd->rw.length = cpu_to_le16((blk_rq_bytes(req) >> ns->lba_shift) - 1);
> + cmnd->rw.reftag = 0;
> + cmnd->rw.apptag = 0;
> + cmnd->rw.appmask = 0;
All these PI fields are reserved when PI isn't enabled using the control
field. So I think we can stop clearing reftag here entirely, and move
clearing the apptag and appmask down next to the reftag assignment.
>
> +static void nvme_clear_cmd(struct request *req)
> +{
> + if (!(req->rq_flags & RQF_DONTPREP)) {
> + nvme_clear_nvme_request(req);
> + memset(nvme_req(req)->cmd, 0, sizeof(struct nvme_command));
> + }
> +}
> +
> blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct request *req)
> {
> struct nvme_command *cmd = nvme_req(req)->cmd;
> struct nvme_ctrl *ctrl = nvme_req(req)->ctrl;
> blk_status_t ret = BLK_STS_OK;
>
> - if (!(req->rq_flags & RQF_DONTPREP)) {
> - nvme_clear_nvme_request(req);
> - memset(cmd, 0, sizeof(*cmd));
> - }
The nvme_clear_nvme_request is not done unconditionally for the read
and write commands below, which does the wrong thing. So I think we want
to keep it here and just move the memset.
I think the best way is to split this patch into two:
1) remove the memset here and do it unconditionally in the individual
nvme_setup_* handlers, and document there why the extra memsets don't
hurt (no partial completions unlikey SCSI)
2) optimize the read/write case
next prev parent reply other threads:[~2021-10-13 4:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 18:13 [PATCH] nvme: don't memset() the normal read/write command Jens Axboe
2021-10-12 18:31 ` Keith Busch
2021-10-12 18:56 ` Jens Axboe
2021-10-13 4:14 ` Chaitanya Kulkarni
2021-10-13 4:58 ` Christoph Hellwig [this message]
2021-10-18 10:22 ` Christoph Hellwig
2021-10-18 12:33 ` Jens Axboe
2021-10-18 12:37 ` Christoph Hellwig
2021-10-18 12:38 ` Jens Axboe
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=20211013045822.GA24761@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
/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.