Messages in this thread | | | Date | Tue, 22 Mar 2022 12:30:42 +0000 | Subject | Re: [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops() | From | John Garry <> |
| |
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.
> 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.
Thanks, John
| |