Linux block layer
 help / color / mirror / Atom feed
From: Daniel Wagner <dwagner@suse.de>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>
Subject: Re: [PATCH blktests v2 0/3] Test different queue counts
Date: Mon, 27 Mar 2023 17:41:45 +0200	[thread overview]
Message-ID: <20230327154145.ev5m33q4rl4jf7r5@carbon.lan> (raw)
In-Reply-To: <20230323110651.fdblmaj4fac2x5qh@shindev>

On Thu, Mar 23, 2023 at 11:06:53AM +0000, Shinichiro Kawasaki wrote:
> On Mar 22, 2023 / 11:16, Daniel Wagner wrote:
> > Setup different queues, e.g. read and poll queues.
> > 
> > There is still the problem that _require_nvme_trtype_is_fabrics also includes
> > the loop transport which has no support for different queue types.
> > 
> > See also https://lore.kernel.org/linux-nvme/20230322002350.4038048-1-kbusch@meta.com/
> 
> Hi Daniel, thanks for the patches. The new test case catches some bugs. Looks
> valuable.
> 
> I ran the test case using various nvme_trtype on kernel v6.2 and v6.3-rc3, and
> observed hangs. I applied the 3rd patch in the link above on top of v6.3-rc3 and
> confirmed the hang disappears. I would like to wait for the kernel fix patch
> delivered to upstream, before adding this test case to blktests master.

Okay makes sense.

> When I ran the test case without setting nvme_trtype, kernel reported messages
> below:
> 
> [  199.621431][ T1001] nvme_fabrics: invalid parameter 'nr_write_queues=%d'
> [  201.271200][ T1030] nvme_fabrics: invalid parameter 'nr_write_queues=%d'
> [  201.272155][ T1030] nvme_fabrics: invalid parameter 'nr_poll_queues=%d'

BTW, I've added a '|| echo FAIL' to catch those.

> Is it useful to run the test case with default nvme_trtype=loop?

No, we should run this test only for those transport which actually support the
different queue types. Christoph suggest to figure out before running the test
if it is actually supported. So my first idea was to check what options are
supported by reading /dev/nvme-fabrics. But this will return all options we are
parsed by fabrics.c but not the subset which each transport might only support.

So to figure this out we would need to do a full setup just to figure out if it
is supported. I think the currently best approach would just to limit this test
to tcp and rdma. Maybe we could add something like

rc:
_require_nvme_trtype() {
	local trtype
	for trtype in "$@"; do
		if [[ "${nvme_trtype}" == "$trtype" ]]; then
			return 0
		fi
	done
	SKIP_REASONS+=("nvme_trtype=${nvme_trtype} is not supported in this test")
	return 1
}

047:
requires() {
	_nvme_requires
	_have_xfs
	_have_fio
	_require_nvme_trtype tcp rdma
	_have_kver 4 21
}

What do you think?

Thanks,
Daniel

  reply	other threads:[~2023-03-27 15:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 10:16 [PATCH blktests v2 0/3] Test different queue counts Daniel Wagner
2023-03-22 10:16 ` [PATCH blktests v2 1/3] nvme/rc: Parse optional arguments in _nvme_connect_subsys() Daniel Wagner
2023-03-22 11:08   ` Daniel Wagner
2023-03-23 10:45   ` Shinichiro Kawasaki
2023-03-22 10:16 ` [PATCH blktests v2 2/3] nvme/rc: Add nr queue parser arguments Daniel Wagner
2023-03-23 10:46   ` Shinichiro Kawasaki
2023-03-22 10:16 ` [PATCH blktests v2 3/3] nvme/047: Test different queue counts Daniel Wagner
2023-03-23 10:55   ` Shinichiro Kawasaki
2023-03-23 11:06 ` [PATCH blktests v2 0/3] " Shinichiro Kawasaki
2023-03-27 15:41   ` Daniel Wagner [this message]
2023-03-28  8:45     ` Shinichiro Kawasaki
2023-03-28 18:20       ` Chaitanya Kulkarni
2023-03-29  0:57         ` Shinichiro Kawasaki
2023-03-28 18:35 ` Keith Busch
2023-03-29  3:30   ` Chaitanya Kulkarni
2023-03-29  6:25     ` Daniel Wagner

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=20230327154145.ev5m33q4rl4jf7r5@carbon.lan \
    --to=dwagner@suse.de \
    --cc=chaitanyak@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro.kawasaki@wdc.com \
    /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