From: Daniel Wagner <dwagner@suse.de>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Keith Busch <kbusch@kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: Re: [PATCH blktests v2 0/3] Test different queue counts
Date: Wed, 29 Mar 2023 08:25:59 +0200 [thread overview]
Message-ID: <20230329062559.k4qltulx4oldx3pa@carbon.lan> (raw)
In-Reply-To: <6dcf501f-8863-b448-01fa-1252e73a87f5@nvidia.com>
On Wed, Mar 29, 2023 at 03:30:17AM +0000, Chaitanya Kulkarni wrote:
> On 3/28/23 11:35, Keith Busch wrote:
> > On Wed, Mar 22, 2023 at 11:16:45AM +0100, Daniel Wagner wrote:
> >> Setup different queues, e.g. read and poll queues.
> > If you wanted to add a similar test for pci, you do it by echo'ing the desired
> > options to:
> >
> > /sys/modules/nvme/parameters/{poll_queues,write_queues}
> >
> > Then do an 'nvme reset' on the target nvme pci device.
> >
> > I'll just note that such a test will currently fail, and fixing that doesn't
> > look like fun. :)
>
> then we should definitely add it ;) ha ha.
>
> I was actually wondering about pci based on the discussion on this thread
> was mainly focused on tcp and rdam, thanks for the suggestion Keith.
The test is fabric centric because we configure the queues via the 'nvme
connect' call, something we can't do for PCI. It look likes it needs another
new test for PCI. Let me get this one sorted out first though.
prev parent reply other threads:[~2023-03-29 6:26 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
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 [this message]
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=20230329062559.k4qltulx4oldx3pa@carbon.lan \
--to=dwagner@suse.de \
--cc=chaitanyak@nvidia.com \
--cc=kbusch@kernel.org \
--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