Re: dev_loss_tmo behavior question

[Andrew Vasquez <andrew.vasquez@qlogic.com>]

On Wed, 28 Jul 2010, James Smart wrote:

> Mike Christie wrote:
> > 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.
> 
> 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...

> > 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?
> 
> 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