Mike Christie wrote:
On 07/28/2010 11:57 AM, Andrew Vasquez wrote:
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?
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?
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
