lkml.org 
[lkml]   [2022]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2022-03-22 15:04    [W:5.860 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site