All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, hch@lst.de, linux-block@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	io-uring@vger.kernel.org, sagi@grimberg.me,
	asml.silence@gmail.com, anuj20.g@samsung.com,
	joshi.k@samsung.com, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv12 11/12] nvme: register fdp parameters with the block layer
Date: Mon, 9 Dec 2024 14:18:19 +0100	[thread overview]
Message-ID: <20241209131819.GA16038@lst.de> (raw)
In-Reply-To: <20241206221801.790690-12-kbusch@meta.com>

> +static int nvme_check_fdp(struct nvme_ns *ns, struct nvme_ns_info *info,
> +			  u8 fdp_idx)

Maybe nvme_query_fdp_runs or something else that makes it clear this
is trying to find the runs field might make sense to name this a little
bit more descriptively.



> +{
> +	struct nvme_fdp_config_log hdr, *h;
> +	struct nvme_fdp_config_desc *desc;
> +	size_t size = sizeof(hdr);
> +	int i, n, ret;
> +	void *log;
> +
> +	info->runs = 0;
> +	ret = nvme_get_log_lsi(ns->ctrl, 0, NVME_LOG_FDP_CONFIGS, 0, NVME_CSI_NVM,

Overly long line here, and same for the second call below.

> +			   (void *)&hdr, size, 0, info->endgid);

And this cast isn't actually needed.

> +	n = le16_to_cpu(h->numfdpc) + 1;
> +	if (fdp_idx > n)
> +		goto out;
> +
> +	log = h + 1;
> +	do {
> +		desc = log;
> +		log += le16_to_cpu(desc->dsze);
> +	} while (i++ < fdp_idx);

Maybe a for loop makes it easier to avoid the uninitialized variable,
e.g.

	for (i = 0; i < fdp_index; i++) {
		..

> +	if (ns->ctrl->ctratt & NVME_CTRL_ATTR_FDPS) {
> +		ret = nvme_query_fdp_info(ns, info);
> +		if (ret)
> +			dev_warn(ns->ctrl->device,
> +				"FDP failure status:0x%x\n", ret);
> +		if (ret < 0)
> +			goto out;
> +	}

Looking at the full series with the next patch applied I'm a bit
confused about the handling when rescanning.  AFAIK the code now always
goes into nvme_query_fdp_info when NVME_CTRL_ATTR_FDPS even if
head->plids/head->nr_plids is already set, and that will then simply
override them, even if they were already set.

Also the old freeing of head->plids in nvme_free_ns_head seems gone in
this version.

Last not but least "FDP failure" is probably not a very helpful message
when it could come from about half a dozen different commands sent to
the device.


  parent reply	other threads:[~2024-12-09 13:18 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 22:17 [PATCHv12 00/12] block write streams with nvme fdp Keith Busch
2024-12-06 22:17 ` [PATCHv12 01/12] fs: add write stream information to statx Keith Busch
2024-12-09  8:25   ` Hannes Reinecke
2024-12-09 11:44   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 02/12] fs: add a write stream field to the kiocb Keith Busch
2024-12-09  8:25   ` Hannes Reinecke
2024-12-09 12:47   ` [PATCHv12 01/12] fs: add write stream information to statx Christian Brauner
2024-12-10  7:24   ` [PATCHv12 02/12] fs: add a write stream field to the kiocb Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 03/12] block: add a bi_write_stream field Keith Busch
2024-12-09  8:26   ` Hannes Reinecke
2024-12-10  7:34   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 04/12] block: introduce max_write_streams queue limit Keith Busch
2024-12-09  8:27   ` Hannes Reinecke
2024-12-10  7:38   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 05/12] block: introduce a write_stream_granularity " Keith Busch
2024-12-09  8:29   ` Hannes Reinecke
2024-12-10  7:45   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 06/12] block: expose write streams for block device nodes Keith Busch
2024-12-09  8:30   ` Hannes Reinecke
2024-12-09 10:58   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 07/12] io_uring: enable per-io write streams Keith Busch
2024-12-09  8:31   ` Hannes Reinecke
2024-12-06 22:17 ` [PATCHv12 08/12] nvme: add a nvme_get_log_lsi helper Keith Busch
2024-12-09  8:31   ` Hannes Reinecke
2024-12-10 12:12   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 09/12] nvme: pass a void pointer to nvme_get/set_features for the result Keith Busch
2024-12-09  8:32   ` Hannes Reinecke
2024-12-10 12:13   ` Nitesh Shetty
2024-12-06 22:17 ` [PATCHv12 10/12] nvme.h: add FDP definitions Keith Busch
2024-12-09  8:33   ` Hannes Reinecke
2024-12-10 12:19   ` Nitesh Shetty
2024-12-06 22:18 ` [PATCHv12 11/12] nvme: register fdp parameters with the block layer Keith Busch
2024-12-09  4:05   ` kernel test robot
2024-12-09 12:44     ` Christoph Hellwig
2024-12-09  8:34   ` Hannes Reinecke
2024-12-09 13:18   ` Christoph Hellwig [this message]
2024-12-09 16:29     ` Keith Busch
2024-12-10  8:45   ` Dan Carpenter
2024-12-10 15:23     ` Keith Busch
2024-12-06 22:18 ` [PATCHv12 12/12] nvme: use fdp streams if write stream is provided Keith Busch
2024-12-09  8:34   ` Hannes Reinecke
2024-12-10  7:27   ` Nitesh Shetty
2024-12-09 12:55 ` [PATCHv12 00/12] block write streams with nvme fdp Christoph Hellwig
2024-12-09 16:07   ` Keith Busch
2024-12-10  1:49     ` Martin K. Petersen
2024-12-10  7:19     ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2024-12-09 20:08 [PATCHv12 11/12] nvme: register fdp parameters with the block layer kernel test robot

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=20241209131819.GA16038@lst.de \
    --to=hch@lst.de \
    --cc=anuj20.g@samsung.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@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.