Re: [PATCH] scsi: break from queue depth adjusting loops when device found

From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>,
	Stephen Cameron <stephenmcameron@gmail.com>
Cc: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	"Stephen M. Cameron" <scameron@beardog.cce.hp.com>,
	"james.bottomley@parallels.com" <james.bottomley@parallels.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Vasu Dev <vasu.dev@linux.intel.com>,
	Mike Christie <michaelc@cs.wisc.edu>
Subject: Re: [PATCH] scsi: break from queue depth adjusting loops when device found
Date: Sun, 27 Jul 2014 17:36:35 +0200	[thread overview]
Message-ID: <53D51C83.3020502@suse.de> (raw)
In-Reply-To: <20140726161721.GA6743@lst.de>

On 07/26/2014 06:17 PM, Christoph Hellwig wrote:
> On Sat, Jul 26, 2014 at 11:14:35AM -0500, Stephen Cameron wrote:
>> Hmm, I forgot that that patch was in there, I wasn't trying to keep pushing
>> it along.  From the previous discussion, I got the impression I was simply
>> wrong, and that this patch wasn't needed, so I had meant to drop it, I just
>> forgot to actually drop it.
>
> It's more complicated - as Robert indicated you're tenically right, although
> in practice it's not what the existing users expect.  If you have some
> cycles for it I'd love to at lest get the per-LUN and per-target
> ramp up/down in ASAP.  We can then start looking into doing it even
> better based on the target response later on.
>
The current implementation is based on the needs of the FC HBAs, which 
would need a way to throttle I/O to avoid flooding a target port.
The reason it was done per target is (from what I can tell) due to a 
specific implementation from a large vendor which is using a 
per-target-port request queue.
And more often than not defaulting to SCSI-2 conformance to be 'legacy 
compatible'. So no way one could use any shiny new commands.

Having said that it has been quite some time since it's been 
implemented, and it _might_ be that things have changed and we can get 
away with a per-LUN throttling. As I doubt we'll get information about 
this from the various storage vendors (at least not from those we've got 
issues with even today) we probably have to bite the bullet here and 
test things out.

But hey, it's worth a shot anyway. So, storage vendors, speak up!

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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