From: Hannes Reinecke <hare@suse.de>
To: Max Gurtovoy <mgurtovoy@nvidia.com>,
linux-nvme@lists.infradead.org, hch@lst.de, kbusch@kernel.org,
sagi@grimberg.me
Cc: chaitanyak@nvidia.com, israelr@nvidia.com, oren@nvidia.com,
jsmart2021@gmail.com
Subject: Re: [PATCH 5/7] nvme/nvme-fabrics: introduce nvmf_error_recovery_work API
Date: Tue, 19 Oct 2021 15:34:37 +0200 [thread overview]
Message-ID: <eeb357d6-5431-0fed-8f83-d61b2ac0a35f@suse.de> (raw)
In-Reply-To: <20211018134020.33838-6-mgurtovoy@nvidia.com>
On 10/18/21 3:40 PM, Max Gurtovoy wrote:
> Error recovery work is duplicated in RDMA and TCP transports. Move this
> logic to common code. For that, introduce 2 new ctrl ops to teardown IO
> and admin queue.
>
> Also update the RDMA/TCP transport drivers to use this API and remove
> the duplicated code.
>
> Reviewed-by: Israel Rukshin <israelr@nvidia.com>
> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> ---
> drivers/nvme/host/fabrics.c | 23 +++++++++++++++
> drivers/nvme/host/fabrics.h | 1 +
> drivers/nvme/host/nvme.h | 4 +++
> drivers/nvme/host/rdma.c | 56 ++++++++++++++++---------------------
> drivers/nvme/host/tcp.c | 56 +++++++++++++++----------------------
> 5 files changed, 75 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index 2edd086fa922..544195369c97 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -493,6 +493,29 @@ void nvmf_reconnect_or_remove(struct nvme_ctrl *ctrl)
> }
> EXPORT_SYMBOL_GPL(nvmf_reconnect_or_remove);
>
> +void nvmf_error_recovery_work(struct work_struct *work)
> +{
> + struct nvme_ctrl *ctrl = container_of(work,
> + struct nvme_ctrl, err_work);
> +
> + nvme_stop_keep_alive(ctrl);
> + ctrl->ops->teardown_ctrl_io_queues(ctrl);
> + /* unquiesce to fail fast pending requests */
> + nvme_start_queues(ctrl);
> + ctrl->ops->teardown_ctrl_admin_queue(ctrl);
> + blk_mq_unquiesce_queue(ctrl->admin_q);
> +
> + if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_CONNECTING)) {
> + /* state change failure is ok if we started ctrl delete */
> + WARN_ON_ONCE(ctrl->state != NVME_CTRL_DELETING &&
> + ctrl->state != NVME_CTRL_DELETING_NOIO);
> + return;
> + }
> +
> + nvmf_reconnect_or_remove(ctrl);
> +}
> +EXPORT_SYMBOL_GPL(nvmf_error_recovery_work);
> +
> void nvmf_error_recovery(struct nvme_ctrl *ctrl)
> {
> if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
> diff --git a/drivers/nvme/host/fabrics.h b/drivers/nvme/host/fabrics.h
> index 3d8ec7133fc8..8655eff74ed0 100644
> --- a/drivers/nvme/host/fabrics.h
> +++ b/drivers/nvme/host/fabrics.h
> @@ -190,6 +190,7 @@ int nvmf_get_address(struct nvme_ctrl *ctrl, char *buf, int size);
> bool nvmf_should_reconnect(struct nvme_ctrl *ctrl);
> void nvmf_reconnect_or_remove(struct nvme_ctrl *ctrl);
> void nvmf_error_recovery(struct nvme_ctrl *ctrl);
> +void nvmf_error_recovery_work(struct work_struct *work);
> bool nvmf_ip_options_match(struct nvme_ctrl *ctrl,
> struct nvmf_ctrl_options *opts);
>
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index f9e1ce93d61d..1573edf6e97f 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -493,6 +493,10 @@ struct nvme_ctrl_ops {
> void (*submit_async_event)(struct nvme_ctrl *ctrl);
> void (*delete_ctrl)(struct nvme_ctrl *ctrl);
> int (*get_address)(struct nvme_ctrl *ctrl, char *buf, int size);
> +
> + /* Fabrics only */
> + void (*teardown_ctrl_io_queues)(struct nvme_ctrl *ctrl);
> + void (*teardown_ctrl_admin_queue)(struct nvme_ctrl *ctrl);
> };
>
> /*
As noted by Sagi, this abstraction really is awkward.
Why not have
void (*teardown_ctrl_queues)(struct nvme_ctrl *ctrl, int qid);
and let the callback figure out whether it's for the admin queue
(ie qid == 8) or the normal I/O queue?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
next prev parent reply other threads:[~2021-10-19 13:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 13:40 [PATCH v1 0/7] Centrelize common fabrics code to core drivers Max Gurtovoy
2021-10-18 13:40 ` [PATCH 1/7] nvme: add connect_work attribute to nvme ctrl Max Gurtovoy
2021-10-19 12:32 ` Sagi Grimberg
2021-10-19 13:20 ` Hannes Reinecke
2021-10-20 13:34 ` Himanshu Madhani
2021-10-18 13:40 ` [PATCH 2/7] nvme-fabrics: introduce nvmf_reconnect_or_remove API Max Gurtovoy
2021-10-19 6:26 ` Chaitanya Kulkarni
2021-10-19 12:36 ` Sagi Grimberg
2021-10-19 12:58 ` Max Gurtovoy
2021-10-19 13:21 ` Hannes Reinecke
2021-10-20 13:34 ` Himanshu Madhani
2021-10-18 13:40 ` [PATCH 3/7] nvme: add err_work attribute to nvme ctrl Max Gurtovoy
2021-10-19 12:36 ` Sagi Grimberg
2021-10-20 13:34 ` Himanshu Madhani
2021-10-18 13:40 ` [PATCH 4/7] nvme-fabrics: introduce nvmf_error_recovery API Max Gurtovoy
2021-10-19 13:27 ` Hannes Reinecke
2021-10-20 13:34 ` Himanshu Madhani
2021-10-18 13:40 ` [PATCH 5/7] nvme/nvme-fabrics: introduce nvmf_error_recovery_work API Max Gurtovoy
2021-10-19 6:29 ` Chaitanya Kulkarni
2021-10-19 12:43 ` Sagi Grimberg
2021-10-19 13:17 ` Max Gurtovoy
2021-10-19 13:34 ` Hannes Reinecke [this message]
2021-10-18 13:40 ` [PATCH 6/7] nvme/nvme-fabrics: introduce nvmf_reconnect_ctrl_work API Max Gurtovoy
2021-10-19 6:29 ` Chaitanya Kulkarni
2021-10-19 12:44 ` Sagi Grimberg
2021-10-19 13:18 ` Max Gurtovoy
2021-10-19 13:41 ` Hannes Reinecke
2021-10-18 13:40 ` [PATCH 7/7] nvme-fabrics: add nvmf_init_ctrl/nvmf_teardown_ctrl API Max Gurtovoy
2021-10-19 12:46 ` Sagi Grimberg
2021-10-19 13:20 ` Max Gurtovoy
2021-10-18 14:08 ` [PATCH v1 0/7] Centrelize common fabrics code to core drivers James Smart
2021-10-19 5:36 ` Christoph Hellwig
2021-10-19 6:24 ` Chaitanya Kulkarni
2021-10-19 12:32 ` Sagi Grimberg
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=eeb357d6-5431-0fed-8f83-d61b2ac0a35f@suse.de \
--to=hare@suse.de \
--cc=chaitanyak@nvidia.com \
--cc=hch@lst.de \
--cc=israelr@nvidia.com \
--cc=jsmart2021@gmail.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mgurtovoy@nvidia.com \
--cc=oren@nvidia.com \
--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