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? Thanks, Bart.
