scsi: lpfc: NVMe remote port devloss_tmo from lldd
authorJames Smart <jsmart2021@gmail.com>
Tue, 14 Jul 2020 21:14:12 +0000 (14:14 -0700)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 15 Jul 2020 20:10:00 +0000 (16:10 -0400)
commit1f546823147693a054320d05d94f4515fb01748f
treec762ae242b35e51162645ddfeff8f8f3bfe26978
parentba8ca097089b1372d36d5b789c231b6c2c797d31
scsi: lpfc: NVMe remote port devloss_tmo from lldd

nvme-fc allows the driver to specify a default devloss_tmo value when
registering the remote port. The lpfc driver is currently not doing so,
although it is implementing a driver internal node loss value of 30s which
also is used on the SCSI FC remote port. As no devloss_tmo is set, the
nvme-fc transport defaults to 60s. So there are competing timers.

Additionally, due to the competing timers, it is possible the NVMe rport is
removed but the SCSI rport remains. It is possible that the SCSI FC rport,
which was registered for the NVMe port even if it doesn't utilize the SCSI
protocol, had been tuned to not match either the 60s (nvme-fc default) or
30s (lldd default), it gets out of whack. The lldd will defer to the SCSI
FC rport as long as the SCSI FC rport has not had its devloss_tmo expire.

Correct the situation by specifying a default devloss_tmo to the nvme-fc
transport when registering the rport.  Take the value from the SCSI FC
rport if it exists, otherwise use the driver default.

Link: https://lore.kernel.org/r/20200714211412.11773-1-jsmart2021@gmail.com
Tested-by: Martin George <Martin.George@netapp.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/lpfc/lpfc_nvme.c