Messages in this thread | | | Date | Tue, 22 Mar 2022 15:03:04 +0100 | From | Hannes Reinecke <> | Subject | Re: [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops() |
| |
On 3/22/22 13:30, John Garry wrote: > On 22/03/2022 12:16, Hannes Reinecke wrote: >> On 3/22/22 12:33, John Garry wrote: >>> On 22/03/2022 11:18, Christoph Hellwig wrote: >>>> On Tue, Mar 22, 2022 at 06:39:35PM +0800, John Garry wrote: >>>>> Add an API to allocate a request queue which accepts a custom set of >>>>> blk_mq_ops for that request queue. >>>>> >>>>> The reason which we may want custom ops is for queuing requests >>>>> which we >>>>> don't want to go through the normal queuing path. >>>> >>>> Eww. I really do not think we should do separate ops per queue, as >>>> that >>>> is going to get us into a deep mess eventually. >>>> >>> >>> Yeah... so far (here) it works out quite nicely, as we don't need to >>> change the SCSI blk mq ops nor allocate a scsi_device - everything is >>> just separate. >>> >>> The other method mentioned previously was to add the request >>> "reserved" flag and add new paths in scsi_queue_rq() et al to handle >>> this, but that gets messy. >>> >>> Any other ideas ...? >>> >> >> As outlined in the other mail, I think might be useful is to have a >> _third_ type of requests (in addition to the normal and the reserved >> ones). >> That one would be allocated from the normal I/O pool (and hence could >> fail if the pool is exhausted), but would be able to carry a different >> payload (type) than the normal requests. > > As mentioned in the cover letter response, it just seems best to keep > the normal scsi_cmnd payload but have other means to add on the internal > command data, like using host_scribble or scsi_cmnd priv data. > Well; I found that most drivers I had been looking at the scsi command payload isn't used at all; the drivers primarily cared about the (driver-provided) payload, and were completely ignoring the scsi command payload.
Similar for ATA/libsas: you basically never issue real scsi commands, but either 'raw' ATA requests or SCSI TMFs. None of which are scsi commands, so providing them is a bit of a waste.
(And causes irritations, too, as a scsi command requires associated pointers like ->device etc to be set up. Which makes it tricky to use for the initial device setup.)
>> And we could have a separate queue_rq for these requests, as we can >> differentiate them in the block layer. > > I don't know, let me think about it. Maybe we could add an "internal" > blk flag, which uses a separate "internal" queue_rq callback. > Yeah, that's what I had in mind.
Cheers,
Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
| |