On 3/14/19 4:19 PM, Bart Van Assche wrote:
On Wed, 2019-03-13 at 23:52 -0400, Douglas Gilbert wrote:
On 2019-03-13 10:39 p.m., Bart Van Assche wrote:
On 3/13/19 6:32 PM, Douglas Gilbert wrote:
I agree that scsi_ioctl_reset() should be taught how to produce a request
that doesn't blow up intermediate code expecting all requests to be well
made with respect to mq.
Hi Doug,
Do you perhaps have a proposal for how to do that without allocating a new
request from the error handler and without reserving a request for error
handling purposes.
Well yes. The SCSI ML could tell the block layer that the LU/device
was unavailable (temporarily) and then the ML would communicate
directly with the LLD. A block layer/mq bypass ...
Probably don't like that one. Why rule out reserving a request (e.g. one
per host)?
The lowest supported queue depth is one so we reserving a request may break
some SCSI LLDs. Additionally, reserving one request may have a performance
impact.
BTW, it is not clear to me why a struct scsi_cmnd pointer is passed to the
eh_*_reset_handler() callbacks. Has it ever been considered to pass a struct
scsi_device pointer to these callback functions instead? In other words, are
there any eh_*_reset_handler() callbacks that use more information from struct
scsi_cmnd than the device pointer?
Yes, one has.
And indeed, one has a complete patchset for doing so.
However, as it turns out some obnoxious drivers actually have to
allocate a command tag for TMFs, which currently is resolved by (re-)
using the tag from the passed in command.
Which clearly doesn't work anymore when switching to struct scsi_device,
struct scsi_target, or struct Scsi_Host.
Hence I have an additional patchset for implementing 'private' commands
for SCSI, which would allow those drivers to request a private command
and use the tag from there.
Which all sounds quite elegant, but then I ran into the mpt3sas driver
which has two _different_ sets of private commands (hi-priority ones for
TMF and 'normal' one for internal commands).
Sadly the current blk-mq abstraction only allows for _one_ type of
private commands (as you have only one bitmap to choose from).
And as of now I don't have a clear idea how to approach this...
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
