From: Andrew Vasquez <andrew.vasquez@qlogic.com>
To: Mike Christie <michaelc@cs.wisc.edu>
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 15:15:51 -0700 [thread overview]
Message-ID: <20100730221551.GI12731@plapp.qlogic.org> (raw)
In-Reply-To: <4C530A2D.5070507@cs.wisc.edu>
On Fri, 30 Jul 2010, 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'm fine with that too...
-- av
prev parent reply other threads:[~2010-07-30 22:15 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
2010-07-30 17:28 ` James Smart
2010-07-30 22:15 ` Andrew Vasquez [this message]
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=20100730221551.GI12731@plapp.qlogic.org \
--to=andrew.vasquez@qlogic.com \
--cc=Kashyap.Desai@lsi.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=michaelc@cs.wisc.edu \
--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).