All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christof Schmitt <christof.schmitt-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
To: Vasu Dev <vasu.dev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
	devel-s9riP+hp16TNLxjTenLetw@public.gmane.org,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 5/7] scsi-ml: adds queue_depth ramp up code
Date: Fri, 16 Oct 2009 11:29:12 +0200	[thread overview]
Message-ID: <20091016092912.GA7199@schmichrtp.de.ibm.com> (raw)
In-Reply-To: <20091016004700.22451.42962.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>

On Thu, Oct 15, 2009 at 05:47:00PM -0700, Vasu Dev wrote:
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 7b1e20f..3379da6 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -331,6 +331,42 @@ static int scsi_check_sense(struct scsi_cmnd *scmd)
>  	}
>  }
> 
> +static void scsi_handle_queue_ramp_up(struct scsi_device *sdev)
> +{
> +	struct scsi_host_template *sht = sdev->host->hostt;
> +	struct scsi_device *tmp_sdev;
> +
> +	if (!sht->change_queue_depth ||
> +	    sdev->queue_depth == sdev->max_queue_depth)
> +		return;
[...]
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -251,6 +251,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  	sdev->model = scsi_null_device_strs;
>  	sdev->rev = scsi_null_device_strs;
>  	sdev->host = shost;
> +	sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
>  	sdev->id = starget->id;
>  	sdev->lun = lun;
>  	sdev->channel = starget->channel;
> @@ -312,6 +313,8 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  		}
>  	}
> 
> +	sdev->max_queue_depth = sdev->queue_depth;
> +
>  	return sdev;

Running this patches series with the zfcp device driver increases the
queue_depth beyond the maximum. The problem is that after slave_alloc,
the queue_depth is 1 from cmd_per_lun and this is the value used for
max_queue_depth.

zfcp then adjust the queue_depth and tagging in slave_configure. Now,
the queue_depth is 32 and the max_queue_depth is still 1. And the
check for sdev->queue_depth == sdev->max_queue_depth is never true.

What is the best way to solve this? Move the initial assignment of
max_queue_depth to be called after the call to slave_configure? And/or
adjust the check above to sdev->queue_depth >= sdev->max_queue_depth?

--
Christof

  parent reply	other threads:[~2009-10-16  9:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-16  0:46 [PATCH v2 1/7] scsi-ml: modify change_queue_depth to take in reason why it is being called Vasu Dev
     [not found] ` <20091016004639.22451.76363.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-16  0:46   ` [PATCH v2 2/7] scsi error: have scsi-ml call change_queue_depth to handle QUEUE_FULL Vasu Dev
2009-10-16  0:46   ` [PATCH v2 3/7] libfc: convert libfc calling scsi_track_queue_full Vasu Dev
2009-10-16  0:46   ` [PATCH v2 4/7] fcoe, libfc: fix an libfc issue with queue ramp down in libfc Vasu Dev
2009-10-16  0:47   ` [PATCH v2 5/7] scsi-ml: adds queue_depth ramp up code Vasu Dev
     [not found]     ` <20091016004700.22451.42962.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-16  9:29       ` Christof Schmitt [this message]
     [not found]         ` <20091016092912.GA7199-VuU8Q2ydlaqCpDFQwvYvMTJtLkR7yuzc@public.gmane.org>
2009-10-16 18:16           ` Vasu Dev
2009-10-16 23:08     ` [PATCH v3] " Vasu Dev
     [not found]       ` <20091016230824.18916.84116.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-20 18:54         ` Christof Schmitt
2009-10-20 22:32           ` Vasu Dev
2009-10-20 23:14             ` [Open-FCoE] " Joe Eykholt
     [not found]               ` <4ADE444D.5090307-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2009-10-21  7:49                 ` Christof Schmitt
2009-10-21 17:45                   ` [Open-FCoE] " Vasu Dev
     [not found]                   ` <20091021074944.GA3563-VuU8Q2ydlaqCpDFQwvYvMTJtLkR7yuzc@public.gmane.org>
2009-10-21 17:54                     ` Giridhar Malavali
2009-10-21 13:11               ` [Open-FCoE] " James Smart
2009-10-21 13:37             ` Michael Reed
2009-10-22 22:46     ` [PATCH v4 5/7] " Vasu Dev
2009-10-23 13:53       ` Christof Schmitt
2009-10-23 17:51         ` Giridhar Malavali
2009-10-16  0:47   ` [PATCH v2 6/7] libfc: adds queue_depth ramp up to libfc Vasu Dev
2009-10-16  0:47   ` [PATCH v2 7/7] zfcp: Adapt change_queue_depth for queue full tracking Vasu Dev
2009-10-28 22:48   ` [PATCH v2 1/7] scsi-ml: modify change_queue_depth to take in reason why it is being called James Bottomley
     [not found]     ` <1256770118.2989.24.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-10-29  1:43       ` Vasu Dev

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=20091016092912.GA7199@schmichrtp.de.ibm.com \
    --to=christof.schmitt-ta70fqpds9bqt0dzr+alfa@public.gmane.org \
    --cc=James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
    --cc=devel-s9riP+hp16TNLxjTenLetw@public.gmane.org \
    --cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=vasu.dev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.