linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jsmart2021@gmail.com (James Smart)
Subject: [PATCH v2 0/7] nvme_fc: add dev_loss_tmo support
Date: Tue, 26 Sep 2017 21:50:39 -0700	[thread overview]
Message-ID: <20170927045046.22238-1-jsmart2021@gmail.com> (raw)

FC, on the SCSI side, has long had a device loss timeout which governed
how long it would hide connectivity loss to remote targets. The timeout
value is maintained in the SCSI FC transport and admins are used to
going there to maintain it.

Eventually, the SCSI FC transport will be moved into something
independent from and above SCSI so that SCSI and NVME protocols can
be peers. In the meantime, to add the functionality now, and sync with
the SCSI FC transport, the LLDD will be used as the conduit. The
initial value for the timeout can be set by the LLDD when it creates
the remoteport via nvme_fc_register_remoteport(). Later, if the value
is updated via the SCSI transport, the LLDD can call a new nvme_fc
routine to update the remoteport's dev_loss_tmo value, which can then
be propagated to the nvme controllers on the remoteport.

The fabrics implementation already has a similar timer, the
ctrl_loss_tmo. The timer defaults to 60s with reconnect retry intervals
every 10s. The nvme_fc transport will set the ctlr_loss_tmo to the lesser
of the ctrl_loss_tmo set at controller creation and the dev_loss_tmo
value for the remote port the controller is attached via. The nvme_fc
behaves like the other transports - it retries up to the ctrl_loss_tmo
time window, with reconnect retries a periodic intervals. The reconnect
retries will be disabled if there is not connectivity to the remote port.

The patches were cut on the nvme-4.14 branch
Patch 7, which adds the dev_loss_tmo timeout, is dependent on the
nvme_fc_signal_discovery_scan() routine added by this patch:
http://lists.infradead.org/pipermail/linux-nvme/2017-September/012781.html
The patch has been approved but not yet pulled into a tree.

James Smart (7):
  nvme core: allow controller RESETTING to RECONNECTING transition
  nvme_fc: change ctlr state assignments during reset/reconnect
  nvme_fc: add a dev_loss_tmo field to the remoteport
  nvme_fc: add dev_loss_tmo to controller
  nvme_fc: check connectivity before initiating reconnects
  nvme_fc: move remote port get/put/free location
  nvme_fc: add dev_loss_tmo timeout and remoteport resume support

 drivers/nvme/host/core.c       |   1 +
 drivers/nvme/host/fc.c         | 481 +++++++++++++++++++++++++++++++++++------
 include/linux/nvme-fc-driver.h |  11 +-
 3 files changed, 421 insertions(+), 72 deletions(-)

-- 
2.13.1

             reply	other threads:[~2017-09-27  4:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27  4:50 James Smart [this message]
2017-09-27  4:50 ` [PATCH v2 1/7] nvme core: allow controller RESETTING to RECONNECTING transition James Smart
2017-10-04  8:28   ` Christoph Hellwig
2017-10-11 10:02     ` Sagi Grimberg
2017-09-27  4:50 ` [PATCH v2 2/7] nvme_fc: change ctlr state assignments during reset/reconnect James Smart
2017-10-05  7:57   ` Christoph Hellwig
2017-10-07 15:53     ` James Smart
2017-10-11 10:07       ` Sagi Grimberg
2017-10-11 14:29         ` James Smart
2017-09-27  4:50 ` [PATCH v2 3/7] nvme_fc: add a dev_loss_tmo field to the remoteport James Smart
2017-10-11 10:11   ` Sagi Grimberg
2017-10-11 14:35     ` James Smart
2017-09-27  4:50 ` [PATCH v2 4/7] nvme_fc: add dev_loss_tmo to controller James Smart
2017-10-05  8:00   ` Christoph Hellwig
2017-10-07 16:08     ` James Smart
2017-10-11 10:17       ` Sagi Grimberg
2017-10-11 15:10         ` James Smart
2017-10-11 10:14   ` Sagi Grimberg
2017-09-27  4:50 ` [PATCH v2 5/7] nvme_fc: check connectivity before initiating reconnects James Smart
2017-10-05  8:01   ` Christoph Hellwig
2017-09-27  4:50 ` [PATCH v2 6/7] nvme_fc: move remote port get/put/free location James Smart
2017-10-05  8:03   ` Christoph Hellwig
2017-10-11 10:18   ` Sagi Grimberg
2017-09-27  4:50 ` [PATCH v2 7/7] nvme_fc: add dev_loss_tmo timeout and remoteport resume support James Smart
2017-10-11 10:29   ` Sagi Grimberg
2017-10-11 14:52     ` James Smart

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=20170927045046.22238-1-jsmart2021@gmail.com \
    --to=jsmart2021@gmail.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;
as well as URLs for NNTP newsgroup(s).