On 5/1/20 7:45 PM, Christoph Hellwig wrote:
On Fri, May 01, 2020 at 11:01:29PM +0800, Ming Lei wrote:
We cannot increase MAX_QUEUE arbitrarily as this is a compile time variable,
which seems to relate to a hardware setting.
But I can see to update the reserved command functionality for allowing to
fetch commands from the normal I/O tag pool; in the case of LUN reset it
shouldn't make much of a difference as the all I/O is quiesced anyway.
It isn't related with reset.
This patch reduces active IO queue depth by 1 anytime no matter there is reset
or not, and this way may cause performance regression.
But isn't it the right thing to do? How else do we guarantee that
there always is a tag available for the LU reset?
Precisely. One could argue that this is an issue with the current
driver, too; if all tags have timed-out there is no way how we can send
a LUN reset even now. Hence we need to reserve a tag for us to reliably
send a LUN reset.
And this was precisely the problem what sparked off this entire
patchset; some drivers require a valid tag to send internal, non SCSI
commands to the hardware.
And with the current design it requires some really ugly hacks to make
this to work.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
