[PATCH v2 3/7] nvme_fc: add a dev_loss_tmo field to the remoteport

James Smart james.smart at broadcom.com
Wed Oct 11 07:35:08 PDT 2017


On 10/11/2017 3:11 AM, Sagi Grimberg wrote:
>
>> +#define NVME_FC_DEFAULT_DEV_LOSS_TMO 60    /* seconds */
>
> Why not reusing NVMF_DEF_CTRL_LOSS_TMO ? and isn't 60 seconds
> a little to aggressive to give up?

Because there is an existing FC port timeout which is currently over on 
the SCSI side of the house.  The FC port will support both SCSI and 
FC-NVME simultaneously on the FC port - so it spans/affects both.  When 
the "common fc class" is created and moved out from under scsi, it will 
be the one with the value.


>
> What do you do with the ctrl_loss_tmo user parameter?

Well - this patch munged the dev_loss_tmo value into the 
ctrl_loss_tmo-based values. That is an issue - so in a prior comment I 
stated I'm reposting with the controller loss timeout kept separate from 
the fc port dev_loss_tmo. Thus NVMF_DEF_CTRL_LOSS_TMO and ctrl_loss_tmo 
will be used normally - like it is with RDMA. Dev_loss_tmo will be 
tracked at the fc port level and if fires, will trump wherever the 
controller is in its ctrl_loss_tmo

-- james






More information about the Linux-nvme mailing list