From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH v3] nvme: expand nvmf_check_if_ready checks
Date: Wed, 4 Apr 2018 16:42:08 +0300 [thread overview]
Message-ID: <a8d6de5d-5487-8f60-50af-eecb7b885aae@grimberg.me> (raw)
In-Reply-To: <20180328202102.9267-1-jsmart2021@gmail.com>
On 03/28/2018 11:21 PM, James Smart wrote:
> The nvmf_check_if_ready() checks that were added are very simplistic.
> As such, the routine allows a lot of cases to fail ios during windows
> of reset or re-connection. In cases where there are not multi-path
> options present, the error goes back to the callee - the filesystem
> or application. Not good.
>
> The common routine was rewritten and calling syntax slightly expanded
> so that per-transport is_ready routines don't need to be present.
> The transports now call the routine directly. The routine is now a
> fabrics routine rather than an inline function.
>
> The routine now looks at controller state to decide the action to
> take. Some states mandate io failure. Others define the condition where
> a command can be accepted. When the decision is unclear, a generic
> queue-or-reject check is made to look for failfast or multipath ios and
> only fails the io if it is so marked. Otherwise, the io will be queued
> and wait for the controller state to resolve.
>
> Signed-off-by: James Smart <james.smart at broadcom.com>
>
> ---
> v2:
> needed to set nvme status when rejecting io
> v3:
> renamed qlive to queue_live and connectivity to is_connected
> converted from inline routine to fabrics exported routine.
> ---
> drivers/nvme/host/fabrics.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/nvme/host/fabrics.h | 33 ++------------------
> drivers/nvme/host/fc.c | 12 ++-----
> drivers/nvme/host/rdma.c | 14 ++-------
> drivers/nvme/target/loop.c | 11 ++-----
> 5 files changed, 85 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index a1c58e35075e..73ac41f93ae0 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -536,6 +536,82 @@ static struct nvmf_transport_ops *nvmf_lookup_transport(
> return NULL;
> }
>
> +blk_status_t nvmf_check_if_ready(struct nvme_ctrl *ctrl, struct request *rq,
> + bool queue_live, bool is_connected)
> +{
> + struct nvme_command *cmd = nvme_req(rq)->cmd;
> +
> + if (ctrl->state == NVME_CTRL_LIVE && is_connected)
> + return BLK_STS_OK;
Nit: would be nice to have a likely statement here as its the hot
path. Other than that, looks good,
Reviewed-by: Sagi Grimberg <sagi at grmberg.me>
prev parent reply other threads:[~2018-04-04 13:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 20:21 [PATCH v3] nvme: expand nvmf_check_if_ready checks James Smart
2018-03-29 20:57 ` Mike Snitzer
2018-03-29 22:13 ` James Smart
2018-03-30 0:23 ` Mike Snitzer
2018-04-04 13:42 ` Sagi Grimberg [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=a8d6de5d-5487-8f60-50af-eecb7b885aae@grimberg.me \
--to=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