From: Mike Christie <michaelc@cs.wisc.edu>
To: James Smart <James.Smart@Emulex.Com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Hannes Reinecke <hare@novell.com>
Subject: Re: [PATCH] scsi : set target can_queue from devinfo flags
Date: Thu, 25 Sep 2008 13:15:26 -0500 [thread overview]
Message-ID: <48DBD53E.4040604@cs.wisc.edu> (raw)
In-Reply-To: <48DA9746.9090003@emulex.com>
James Smart wrote:
> This sounds reasonable, but I wouldn't eliminate this can_queue limit.
I was not going to elimitate it. It is all muddled in the one mail, so
it is confusing.
I was just going to set it based on target vendor info table in
userspace from a scsi daemon that was going to handle this issue and
handle ramp ups due to QUEUE_FULL ramp downs and other scsi issues like
the handling of sense that indicates disks changes size or report lun
data changes.
Hannes had mentioned he was making some event infrastructure to handle
the sense, and I thought I could extend his userspce code to handle the
ramp up issue and handle setting this value. So for just the
starget->can_queue issue, the daemon would listen for target hotplug
events, then it would do sg io to device on it and get the vendor info
and look up the target in a table and then if found would write to a
starget->can_queue sysfs file to set the value.
The same daemon could also handle the sense handling and handle other
errors like when to ramp up from when we ramp down due to QUEUE_FULLs.
So it is basically a scsi-ml/lib in userpsace that could be easily
packaged for distros to carry.
next prev parent reply other threads:[~2008-09-25 18:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 17:45 [PATCH] scsi : set target can_queue from devinfo flags James Smart
2008-05-14 6:34 ` Hannes Reinecke
2008-05-14 14:39 ` James Smart
2008-05-14 15:01 ` Hannes Reinecke
2008-05-14 19:38 ` James Bottomley
2008-05-14 21:50 ` James Smart
2008-05-15 1:21 ` James Smart
2008-09-24 19:13 ` Mike Christie
2008-09-24 19:17 ` Mike Christie
2008-09-25 18:40 ` Mike Christie
2008-09-25 19:03 ` James Smart
2008-09-24 19:38 ` James Smart
2008-09-25 18:15 ` Mike Christie [this message]
2008-09-26 7:46 ` Hannes Reinecke
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=48DBD53E.4040604@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=James.Smart@Emulex.Com \
--cc=hare@novell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox