summaryrefslogtreecommitdiffstats
path: root/drivers/nvme/target/fc.c
diff options
context:
space:
mode:
authorJames Smart <jsmart2021@gmail.com>2017-10-25 16:43:17 -0700
committerChristoph Hellwig <hch@lst.de>2017-11-01 16:34:41 +0100
commit2b632970da4f288e6dbdc826c34fbf74f40ec94c (patch)
tree211680023fb17a5eec414d678ddafb599dbe5e42 /drivers/nvme/target/fc.c
parent3cec7f9de448131778a1428100621fd371db75f4 (diff)
downloadlinux-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