From: james.smart@broadcom.com (James Smart)
Subject: [PATCH 4/4] nvme: delete discovery controller after 2 minutes
Date: Tue, 21 Aug 2018 14:01:56 -0700 [thread overview]
Message-ID: <a1911312-0e01-d869-5473-4e70d4950629@broadcom.com> (raw)
In-Reply-To: <20180821134329.69577-5-hare@suse.de>
On 8/21/2018 6:43 AM, Hannes Reinecke wrote:
> If the CLI crashes before the 'disconnect' command is issued or when
> the 'async_connect' option is used the controller is never removed.
> This patch cleans up stale discovery controllers after 2 minutes,
>
> Signed-off-by: Hannes Reinecke <hare at suse.com>
> ---
> drivers/nvme/host/core.c | 5 +++++
> drivers/nvme/host/fabrics.c | 2 +-
> drivers/nvme/host/nvme.h | 1 +
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 358be6d217d9..b3738b327731 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -866,6 +866,11 @@ static void nvme_keep_alive_work(struct work_struct *work)
> struct nvme_ctrl *ctrl = container_of(to_delayed_work(work),
> struct nvme_ctrl, ka_work);
>
> + if (ctrl->opts->discovery_nqn) {
> + nvme_delete_ctrl(ctrl);
> + return;
> + }
> +
> if (nvme_keep_alive(ctrl)) {
> /* allocation failure, reset the controller */
> dev_err(ctrl->device, "keep-alive failed\n");
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index e484205b4cad..b98662760051 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -827,7 +827,7 @@ static int nvmf_parse_options(struct nvmf_ctrl_options *opts,
> }
>
> if (opts->discovery_nqn) {
> - opts->kato = 0;
> + opts->kato = NVME_DISCOVERY_TIMEOUT;
> opts->nr_io_queues = 0;
> opts->duplicate_connect = true;
> }
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 8a4ed46b986b..551a6b1dbc8c 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -32,6 +32,7 @@ extern unsigned int admin_timeout;
>
> #define NVME_DEFAULT_KATO 5
> #define NVME_KATO_GRACE 10
> +#define NVME_DISCOVERY_TIMEOUT 120
>
> extern struct workqueue_struct *nvme_wq;
> extern struct workqueue_struct *nvme_reset_wq;
this doesn't necessarily track to the new TP that adds kato support to
discovery controllers, nor the fabric spec update that has the host
tracking kato and deleting the controller (whether discovery controller
or not) (the actual kato as set on the controller with the grace period).
I would rather have this be a generic timer on a host that tracks to the
kato timeout and deletes the controller (doesn't matter if discovery or
not) if kato times out.??? If the controller is an older discovery
controller that doesn't support kato - then the 1st kato timeout should
fail and remove the controller.? If it's newer and supports kato, it
would be assumed the controller stays live for an extended period- just
like a storage controller.
-- james
next prev parent reply other threads:[~2018-08-21 21:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 13:43 [RFC PATCH 0/4] nvme async-connect and discovery uevents Hannes Reinecke
2018-08-21 13:43 ` [PATCH 1/4] nvme-rdma: use reconnect_work for initial connect Hannes Reinecke
2018-08-21 14:10 ` Max Gurtovoy
2018-08-21 14:18 ` Hannes Reinecke
2018-08-21 13:43 ` [PATCH 2/4] nvme: implement 'async_connect' cli option Hannes Reinecke
2018-08-21 21:01 ` James Smart
2018-08-21 13:43 ` [PATCH 3/4] nvme: implement 'discovery' sysfs entry and discovery uevents Hannes Reinecke
2018-08-21 21:01 ` James Smart
2018-08-22 7:23 ` Hannes Reinecke
2018-08-22 8:51 ` Hannes Reinecke
2018-08-21 13:43 ` [PATCH 4/4] nvme: delete discovery controller after 2 minutes Hannes Reinecke
2018-08-21 21:01 ` James Smart [this message]
2018-08-22 7:32 ` Hannes Reinecke
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=a1911312-0e01-d869-5473-4e70d4950629@broadcom.com \
--to=james.smart@broadcom.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