On 5/2/20 6:10 PM, Bart Van Assche wrote:
On 2020-05-02 01:49, Hannes Reinecke wrote:
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.
Hi Hannes,
The above explanation seems incomplete to me. The code in
drivers/scsi/scsi_error.c and several SCSI LLDs use scsi_eh_prep_cmnd()
and scsi_eh_restore_cmnd() to reset a controller without allocating a
new command. Has it been considered to use that approach in the csiostor
driver?
As outlined in the response to Ming, the problem is the ioctl path.
When called from ioctl we do _not_ have a valid command, hence drivers
have to figure out if the command is valid (ie coming from SCSI EH), or
invalid (ie coming from ioctl).
I'm trying to unify both call paths by having the SCSI EH functions to
always allocate a (reserved) SCSI command.
I have not moved this into the caller, as using a reserved command
requires modifications of the driver itself (at least by setting
'nr_reserved_cmds').
Also, the above approach does not work when we run into a command
timeout; which, from my experience, is the majority of cases.
For timeout commands we precisely can _not_ re-use the command tag, as
the command itself is still assumed live somewhere (otherwise we could
have aborted it, and we wouldn't have to call the EH functions...).
But that means that any associated resources (like FC oxids) are still
active on the wire, and re-using them would actually be a violating of
the spec.
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
