From: James Bottomley <James.Bottomley@steeleye.com>
To: "Smart, James" <James.Smart@Emulex.com>
Cc: Linux SCSI Reflector <linux-scsi@vger.kernel.org>
Subject: RE: Transport affected timeouts...
Date: 21 Apr 2004 15:20:48 -0400 [thread overview]
Message-ID: <1082575283.2583.6.camel@mulgrave> (raw)
In-Reply-To: <3356669BBE90C448AD4645C843E2BF2802C016CE@xbl.ma.emulex.com>
On Wed, 2004-04-21 at 12:53, Smart, James wrote:
> Where do we go from here ?
>
> What we are doing in our driver is the following:
> - Cancel the mid-layer timeout
> - Set timeout to (cmd->timeout_per_command/HZ) + hba_offset
> - Start timer based on new timeout value
Well, this is unacceptable. Only the mid layer should be mucking with
mid-layer timers.
> Where hba_offset is: (2 * R_A_TOV) + administrative increment (default 0)
> Where R_A_TOV is the fabric-reported timeout. R_A_TOV is at least a round
> trip time, plus 2 times max delivery delay time within the fabric. (default
> 10 seconds). This value can change based on fabric reconfiguration or
> plugging the adapter into a differnet fabric.
I'm still not clear on what you're trying to achieve.
the scsi_host_self_blocked interface was created with reconfig events in
mind...it still won't stop in-progress timers, but I've been considering
adding that feature for things like FC lip events.
James
next prev parent reply other threads:[~2004-04-21 19:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-21 16:53 Transport affected timeouts Smart, James
2004-04-21 19:20 ` James Bottomley [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-22 21:36 Smart, James
2004-04-22 21:45 ` Brian King
2004-05-03 15:49 ` Brian King
2004-04-22 18:54 Smart, James
2004-04-22 19:02 ` James Bottomley
2004-04-22 19:09 ` Brian King
2004-04-22 16:28 Smart, James
2004-04-22 18:14 ` Brian King
2004-04-16 20:13 Smart, James
2004-04-16 19:39 Smart, James
2004-04-16 19:46 ` James Bottomley
2004-04-16 15:40 Smart, James
2004-04-16 19:24 ` James Bottomley
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=1082575283.2583.6.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=James.Smart@Emulex.com \
--cc=linux-scsi@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.