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@xxxxxxx +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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
