diff options
author | James Smart <jsmart2021@gmail.com> | 2017-10-25 16:43:17 -0700 |
---|---|---|
committer | Christoph Hellwig <hch@lst.de> | 2017-11-01 16:34:41 +0100 |
commit | 2b632970da4f288e6dbdc826c34fbf74f40ec94c (patch) | |
tree | 211680023fb17a5eec414d678ddafb599dbe5e42 /drivers/nvme/target/fc.c | |
parent | 3cec7f9de448131778a1428100621fd371db75f4 (diff) | |
download | linux-2b632970da4f288e6dbdc826c34fbf74f40ec94c.tar.bz2 |
nvme-fc: add dev_loss_tmo timeout and remoteport resume support
When a remoteport is unregistered (connectivity lost), the following
actions are taken:
- the remoteport is marked DELETED
- the time when dev_loss_tmo would expire is set in the remoteport
- all controllers on the remoteport are reset.
After a controller resets, it will stall in a RECONNECTING state waiting
for one of the following:
- the controller will continue to attempt reconnect per max_retries and
reconnect_delay. As no remoteport connectivity, the reconnect attempt
will immediately fail. If max reconnects has not been reached, a new
reconnect_delay timer will be schedule. If the current time plus
another reconnect_delay exceeds when dev_loss_tmo expires on the remote
port, then the reconnect_delay will be shortend to schedule no later
than when dev_loss_tmo expires. If max reconnect attempts are reached
(e.g. ctrl_loss_tmo reached) or dev_loss_tmo ix exceeded without
connectivity, the controller is deleted.
- the remoteport is re-registered prior to dev_loss_tmo expiring.
The resume of the remoteport will immediately attempt to reconnect
each of its suspended controllers.
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
[hch: updated to use nvme_delete_ctrl]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'drivers/nvme/target/fc.c')
0 files changed, 0 insertions, 0 deletions