From: Mike Christie <michaelc@cs.wisc.edu>
To: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: James Smart <james.smart@Emulex.Com>,
"brking@linux.vnet.ibm.com" <brking@linux.vnet.ibm.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
Giridhar Malavali <giridhar.malavali@qlogic.com>,
Christof Schmitt <christof.schmitt@de.ibm.com>,
"Love, Robert W" <robert.w.love@intel.com>,
Jing Huang <huangj@Brocade.COM>
Subject: Re: dev_loss_tmo behavior question
Date: Fri, 30 Jul 2010 12:21:49 -0500 [thread overview]
Message-ID: <4C530A2D.5070507@cs.wisc.edu> (raw)
In-Reply-To: <20100728165707.GA9844@plapp.qlogic.org>
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?
next prev parent reply other threads:[~2010-07-30 17:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 21:11 dev_loss_tmo behavior question Mike Christie
2010-07-28 8:45 ` Christof Schmitt
2010-07-28 16:07 ` James Smart
2010-07-28 16:57 ` Andrew Vasquez
2010-07-30 17:21 ` Mike Christie [this message]
2010-07-30 17:28 ` James Smart
2010-07-30 22:15 ` Andrew Vasquez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C530A2D.5070507@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=Kashyap.Desai@lsi.com \
--cc=andrew.vasquez@qlogic.com \
--cc=brking@linux.vnet.ibm.com \
--cc=christof.schmitt@de.ibm.com \
--cc=giridhar.malavali@qlogic.com \
--cc=huangj@Brocade.COM \
--cc=james.smart@Emulex.Com \
--cc=linux-scsi@vger.kernel.org \
--cc=robert.w.love@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).