From: Daniel Wagner <dwagner@suse.de>
To: linux-nvme@lists.infradead.org
Cc: Sagi Grimberg <sagi@grimberg.me>, Hannes Reinecke <hare@suse.de>,
Chao Leng <lengchao@huawei.com>, Daniel Wagner <dwagner@suse.de>
Subject: [PATCH v4 0/3] Handle number of queue changes
Date: Mon, 29 Aug 2022 11:28:38 +0200 [thread overview]
Message-ID: <20220829092841.14244-1-dwagner@suse.de> (raw)
Updated the first patch with the feedback from Sagi and Hannes.
While at it also collected the review tags.
From the previous cover letter:
We got a report from our customer that a firmware upgrade on the
storage array is able to 'break' host. This is caused a change of
number of queues which the target supports after a reconnect.
Let's assume the number of queues is 8 and all is working fine. Then
the connection is dropped and the host starts to try to
reconnect. Eventually, this succeeds but now the new number of queues
is 10:
nvme0: creating 8 I/O queues.
nvme0: mapped 8/0/0 default/read/poll queues.
nvme0: new ctrl: NQN "nvmet-test", addr 10.100.128.29:4420
nvme0: queue 0: timeout request 0x0 type 4
nvme0: starting error recovery
nvme0: failed nvme_keep_alive_end_io error=10
nvme0: Reconnecting in 10 seconds...
nvme0: failed to connect socket: -110
nvme0: Failed reconnect attempt 1
nvme0: Reconnecting in 10 seconds...
nvme0: creating 10 I/O queues.
nvme0: Connect command failed, error wo/DNR bit: -16389
nvme0: failed to connect queue: 9 ret=-5
nvme0: Failed reconnect attempt 2
As you can see queue number 9 is not able to connect.
As the order of starting and unfreezing is important we can't just
move the start of the queues after the tagset update. So my stupid
idea was to start just the older number of queues and then the rest.
This seems work:
nvme nvme0: creating 4 I/O queues.
nvme nvme0: mapped 4/0/0 default/read/poll queues.
nvme_tcp_start_io_queues nr_hw_queues 4 queue_count 5 qcnt 5
nvme_tcp_start_io_queues nr_hw_queues 4 queue_count 5 qcnt 5
nvme nvme0: new ctrl: NQN "nvmet-test", addr 10.100.128.29:4420
nvme nvme0: queue 0: timeout request 0x0 type 4
nvme nvme0: starting error recovery
nvme0: Keep Alive(0x18), Unknown (sct 0x3 / sc 0x71)
nvme nvme0: failed nvme_keep_alive_end_io error=10
nvme nvme0: Reconnecting in 10 seconds...
nvme nvme0: creating 6 I/O queues.
nvme_tcp_start_io_queues nr_hw_queues 4 queue_count 7 qcnt 5
nvme nvme0: mapped 6/0/0 default/read/poll queues.
nvme_tcp_start_io_queues nr_hw_queues 6 queue_count 7 qcnt 7
nvme nvme0: Successfully reconnected (1 attempt)
nvme nvme0: starting error recovery
nvme0: Keep Alive(0x18), Unknown (sct 0x3 / sc 0x71)
nvme nvme0: failed nvme_keep_alive_end_io error=10
nvme nvme0: Reconnecting in 10 seconds...
nvme nvme0: creating 4 I/O queues.
nvme_tcp_start_io_queues nr_hw_queues 6 queue_count 5 qcnt 5
nvme nvme0: mapped 4/0/0 default/read/poll queues.
nvme_tcp_start_io_queues nr_hw_queues 4 queue_count 5 qcnt 5
nvme nvme0: Successfully reconnected (1 attempt)
changes:
v4:
- updated subject s/sysfs/configfs/
- updated nvmet_subsys_attrs entry placement
- added missing port variable
- collected reviewed tags
v3:
- only allow max_qid changes when port is disabled
- use ctrl->tagset and avoid code churn
- use correct error label for goto
v2:
- removed debug logging
- pass in queue range idx as argument to nvme_tcp_start_io_queues
v1:
- https://lore.kernel.org/linux-nvme/20220812142824.17766-1-dwagner@suse.de/
Daniel Wagner (3):
nvmet: Expose max queues to configfs
nvme-tcp: Handle number of queue changes
nvme-rdma: Handle number of queue changes
drivers/nvme/host/rdma.c | 26 +++++++++++++++++++++-----
drivers/nvme/host/tcp.c | 26 +++++++++++++++++++++-----
drivers/nvme/target/configfs.c | 29 +++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 10 deletions(-)
--
2.37.2
next reply other threads:[~2022-08-29 9:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 9:28 Daniel Wagner [this message]
2022-08-29 9:28 ` [PATCH v4 1/3] nvmet: Expose max queues to configfs Daniel Wagner
2022-08-29 9:28 ` [PATCH v4 2/3] nvme-tcp: Handle number of queue changes Daniel Wagner
2022-08-29 9:28 ` [PATCH v4 3/3] nvme-rdma: " Daniel Wagner
2022-09-05 11:09 ` [PATCH v4 0/3] " Christoph Hellwig
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=20220829092841.14244-1-dwagner@suse.de \
--to=dwagner@suse.de \
--cc=hare@suse.de \
--cc=lengchao@huawei.com \
--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