nvme-fc: shorten reconnect delay if possible for FC
authorJames Smart <james.smart@broadcom.com>
Fri, 16 Oct 2020 21:29:28 +0000 (14:29 -0700)
committerChristoph Hellwig <hch@lst.de>
Fri, 23 Oct 2020 10:54:45 +0000 (12:54 +0200)
commitf673714a1247669bc90322dfb14a5cf553833796
treefdd30a53e630793a9c6ecf67d1d2adc9f0e0f263
parent88e837ed0f1fddd34a19092aaa7098d579e6c506
nvme-fc: shorten reconnect delay if possible for FC

We've had several complaints about a 10s reconnect delay (the default)
when there was an error while there is connectivity to a subsystem.
The max_reconnects and reconnect_delay are set in common code prior to
calling the transport to create the controller.

This change checks if the default reconnect delay is being used, and if
so, it adjusts it to a shorter period (2s) for the nvme-fc transport.
It does so by calculating the controller loss tmo window, changing the
value of the reconnect delay, and then recalculating the maximum number
of reconnect attempts allowed.

Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
drivers/nvme/host/fc.c