From: Vasu Dev <vasu.dev@linux.intel.com>
To: Christof Schmitt <christof.schmitt@de.ibm.com>
Cc: michaelc@cs.wisc.edu, linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH 9/9] libfc: adds queue_depth ramp up to libfc
Date: Wed, 02 Sep 2009 11:00:37 -0700 [thread overview]
Message-ID: <1251914437.29277.99.camel@vi2.jf.intel.com> (raw)
In-Reply-To: <20090828104442.GA4550@schmichrtp>
On Fri, 2009-08-28 at 12:44 +0200, Christof Schmitt wrote:
> On Thu, Aug 27, 2009 at 01:56:31PM -0700, Vasu Dev wrote:
<snip>
>
> I reused the default_depth settings for checking the maximum queue
> depth. But i am wondering if the check should happen differently.
> Would it make more sense to have an adjustable maximum_depth attribute
> for each SCSI device? Or would it be possible to always increase the
> queue depth until the storage returns QUEUE_FULL again?
Increasing only up to initially configured maximum_depth by LLD is
required otherwise there won't be any upper bound on qdepth increase and
in case of no traffic the qdepth will keep on increasing since there
won't be any QUEUE_FULL event in that case and that might lead to other
issues with qdepth related other resources in the stack.
Currently scsi-ml is not aware of maximum_depth but as you suggested
above it can be added to each scsi_device and then common scsi-ml ramp
up code can ramp up up to configured maximum_depth. But that would
require adding maximum_depth field to scsi_device for only ramp up
purpose and given ramp up call back is required for LLD requiring their
additional resources adjustment I had LLD checked for maximum_depth.
However I think moving qdepth increment qdepth++ to scsi-ml common ramp
up code will eliminate increment in each LLD. I'll do that move.
Thanks
Vasu
> ---
> zfcp: Adapt change_queue_depth for queue full tracking
>
> From: Christof Schmitt <christof.schmitt@de.ibm.com>
>
> Adapt the change_queue_depth callback in zfcp for the new reason
> parameter. Simply pass each call back to the SCSI midlayer, there are
> no resource adjustments necessary for zfcp.
>
> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com>
> ---
> drivers/s390/scsi/zfcp_scsi.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> --- a/drivers/s390/scsi/zfcp_scsi.c 2009-08-28 12:00:12.000000000 +0200
> +++ b/drivers/s390/scsi/zfcp_scsi.c 2009-08-28 12:01:27.000000000 +0200
> @@ -28,9 +28,25 @@ char *zfcp_get_fcp_sns_info_ptr(struct f
> return fcp_sns_info_ptr;
> }
>
> -static int zfcp_scsi_change_queue_depth(struct scsi_device *sdev, int depth)
> +static int zfcp_scsi_change_queue_depth(struct scsi_device *sdev, int depth,
> + int reason)
> {
> - scsi_adjust_queue_depth(sdev, scsi_get_tag_type(sdev), depth);
> + switch (reason) {
> + case SCSI_QDEPTH_SYSFS_REQ:
> + scsi_adjust_queue_depth(sdev, scsi_get_tag_type(sdev), depth);
> + break;
> + case SCSI_QDEPTH_QFULL:
> + scsi_track_queue_full(sdev, depth);
> + break;
> + case SCSI_QDEPTH_RAMP_UP:
> + depth++;
> + if (depth <= default_depth)
> + scsi_adjust_queue_depth(sdev, scsi_get_tag_type(sdev),
> + depth);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> return sdev->queue_depth;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-09-02 18:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 18:03 [RFC PATCH 0/9] RFC: handle queue_depth adjustments because of QUEUE_FULLs in scsi_error.c Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 1/9] scsi-ml: modify change_queue_depth to take in reason why it is being called Vasu Dev
2009-08-27 10:21 ` Christof Schmitt
2009-08-27 21:09 ` Vasu Dev
2009-08-28 16:56 ` Mike Christie
2009-08-26 18:03 ` [RFC PATCH 2/9] scsi error: have scsi-ml call change_queue_depth to handle QUEUE_FULL Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 3/9] drivers: convert drivers setting the change_queue_depth callback Vasu Dev
2009-08-26 18:19 ` Jeff Garzik
2009-08-26 21:50 ` Vasu Dev
2009-08-26 21:55 ` Mike Christie
2009-08-26 18:03 ` [RFC PATCH 4/9] drivers: convert fc drivers calling scsi_track_queue_full Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 5/9] scsi: updates sdev to add queue_depth ramp up code Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 6/9] scsi: adds sdev->queue_ramp_up_period to sysfs Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 7/9] scsi: add common queue_depth ramp up code Vasu Dev
2009-08-26 18:03 ` [RFC PATCH 8/9] fcoe, libfc: fix an libfc issue with queue ramp down in libfc Vasu Dev
2009-08-26 18:04 ` [RFC PATCH 9/9] libfc: adds queue_depth ramp up to libfc Vasu Dev
2009-08-27 10:19 ` Christof Schmitt
2009-08-27 20:56 ` Vasu Dev
2009-08-28 10:44 ` Christof Schmitt
2009-09-02 18:00 ` Vasu Dev [this message]
2009-09-01 22:57 ` [RFC PATCH 0/9] RFC: handle queue_depth adjustments because of QUEUE_FULLs in scsi_error.c Vasu Dev
2009-09-02 1:46 ` Mike Christie
2009-09-02 18:01 ` Vasu Dev
2009-09-03 8:17 ` Swen Schillig
2009-09-14 11:21 ` Christof Schmitt
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=1251914437.29277.99.camel@vi2.jf.intel.com \
--to=vasu.dev@linux.intel.com \
--cc=christof.schmitt@de.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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.