dev_loss_tmo behavior question
Hi FC driver developers,
I am trying to figure out what is the correct behavior when setting dev_loss_tmo.
With lpfc, qla2xx, and ibmfc if I set dev_loss_tmo using /sys/class/fc_remote_port/rport-xx/dev_loss_tmo, and then we add devices the slave_configure functions for these drivers reset the dev_loss_tmo to a driver value.
The addition of devs could be from something like a user rescan, or from a scan started by a remote port addition.
With fcoe, fnic, mptfc, bfa and zfcp the dev_loss_tmo value set from sysfs will not be reset by a driver value on rescans.
Which drivers should be changed?
Quoted 10 lines · Mike Christie
Hi FC driver developers,
I am trying to figure out what is the correct behavior when setting
dev_loss_tmo.With lpfc, qla2xx, and ibmfc if I set
dev_loss_tmousing/sys/class/fc_remote_port/rport-xx/dev_loss_tmo, and then we add devices theslave_configurefunctions for these drivers reset thedev_loss_tmoto a driver value.
Quoted 7 lines
The addition of devs could be from something like a user rescan, or from a scan started by a remote port addition.
With fcoe, fnic, mptfc, bfa and zfcp the
dev_loss_tmovalue set from sysfs will not be reset by a driver value on rescans.Which drivers should be changed?
At least for zfcp, i don't see a reason for the driver to change the value for dev_loss_tmo. A user could delete the SCSI device at any time from userspace (echo 1 > /sys/.../delete), so the driver has to be able to handle the device removal at any time. And then it should not matter if the removal is triggered from userspace or from the FC transport's dev_loss_tmo.
Christof
Quoted 7 lines · Mike Christie
Hi FC driver developers,
I am trying to figure out what is the correct behavior when setting
dev_loss_tmo.With lpfc, qla2xx, and ibmfc if I set
dev_loss_tmousing/sys/class/fc_remote_port/rport-xx/dev_loss_tmo, and then we add devices theslave_configurefunctions for these drivers reset thedev_loss_tmoto a driver value.The addition of devs could be from something like a user rescan, or from a scan started by a remote port addition.
Looking at lpfc - this is a totally insane thing to do, and definitely a bug. Addition or removal of sdevs should not change a rport setting.
Quoted 4 lines
With fcoe, fnic, mptfc, bfa and zfcp the
dev_loss_tmovalue set from sysfs will not be reset by a driver value on rescans.Which drivers should be changed?
lpfc, qla2xx, and ibmfc.
-- james s
Quoted 11 lines · James Smart
Quoted 10 lines · Mike Christie
Hi FC driver developers,
I am trying to figure out what is the correct behavior when setting
dev_loss_tmo.With lpfc, qla2xx, and ibmfc if I set
dev_loss_tmousing/sys/class/fc_remote_port/rport-xx/dev_loss_tmo, and then we add devices theslave_configurefunctions for these drivers reset thedev_loss_tmoto a driver value.
Quoted 5 lines
Quoted 2 lines
The addition of devs could be from something like a user rescan, or from a scan started by a remote port addition.
Looking at lpfc - this is a totally insane thing to do, and definitely a bug. Addition or removal of sdevs should not change a rport setting.
Completely agree...
Quoted 6 lines
Quoted 4 lines
With fcoe, fnic, mptfc, bfa and zfcp the
dev_loss_tmovalue set from sysfs will not be reset by a driver value on rescans.Which drivers should be changed?
lpfc, qla2xx, and ibmfc.
I'm curious though, each driver would still need to seed the rport's dev_loss_tmo value (in the case of qla2xxx, ha->port_down_retry_count), but, by doing so after rport-addition (fc_remote_port_add()), the driver could still overwrite a previous sysfs setting. Internally, upon rport creation, the dev_loss_tmo value is seeding with fc_dev_loss_tmo (a module parameter -- 60 seconds). Should we extend the transport so the the 'default seeding value' can be specified once at fc_host creation-time?
BTW: fnic looks to be doing the same 'bad' behaviour in their slave_alloc() call too...
-- av
Quoted 9 lines · Andrew Vasquez
I'm curious though, each driver would still need to seed the rport's
dev_loss_tmovalue (in the case of qla2xxx,ha->port_down_retry_count), but, by doing so after rport-addition (fc_remote_port_add()), the driver could still overwrite a previous sysfs setting. Internally, upon rport creation, thedev_loss_tmovalue is seeding withfc_dev_loss_tmo(a module parameter -- 60 seconds). Should we extend the transport so the the 'default seeding value' can be specified once atfc_hostcreation-time?
I was going to add a fc_transport callout that gets called when the rport is allocated so drivers can do other rport initialization if they wanted. It is only called the first time when it is actually allocated not every time fc_remote_port_add is called. Would that be more useful?
Quoted 11 lines · Mike Christie
Quoted 9 lines · Andrew Vasquez
I'm curious though, each driver would still need to seed the rport's
dev_loss_tmovalue (in the case of qla2xxx,ha->port_down_retry_count), but, by doing so after rport-addition (fc_remote_port_add()), the driver could still overwrite a previous sysfs setting. Internally, upon rport creation, thedev_loss_tmovalue is seeding withfc_dev_loss_tmo(a module parameter -- 60 seconds). Should we extend the transport so the the 'default seeding value' can be specified once atfc_hostcreation-time?
Quoted 1 line
I was going to add a
fc_transportcallout that gets called when the rport is allocated so drivers can do other rport initialization if they wanted. It is only called the first time when it is actually allocated not every timefc_remote_port_addis called. Would that be more useful?
I would assume this is a fc_host attribute, used in fc_remote_port_add.
Per your last sentence, I assume :
if the rport comes back within the devloss window it definitely is kept to the last value set in the rport
if devloss expires, only if you have target id bindings (where you keep the rport struct as a container for the binding, thus it is part of the saved binding) would you keep the last value set, and it only applies if the binding matches.
if no target id bindings, then it would be set again to the fc_host value when fc_remote_port_add() is called.
-- james s
Quoted 11 lines · Mike Christie
Quoted 9 lines · Andrew Vasquez
I'm curious though, each driver would still need to seed the rport's
dev_loss_tmovalue (in the case of qla2xxx,ha->port_down_retry_count), but, by doing so after rport-addition (fc_remote_port_add()), the driver could still overwrite a previous sysfs setting. Internally, upon rport creation, thedev_loss_tmovalue is seeding withfc_dev_loss_tmo(a module parameter -- 60 seconds). Should we extend the transport so the the 'default seeding value' can be specified once atfc_hostcreation-time?
Quoted 4 lines
I was going to add a
fc_transportcallout that gets called when the rport is allocated so drivers can do other rport initialization if they wanted. It is only called the first time when it is actually allocated not every timefc_remote_port_addis called. Would that be more useful?
I'm fine with that too...
-- av