From: Hannes Reinecke <hare@suse.de> To: John Garry <john.garry@huawei.com>, Christoph Hellwig <hch@lst.de> Cc: axboe@kernel.dk, damien.lemoal@opensource.wdc.com, bvanassche@acm.org, jejb@linux.ibm.com, martin.petersen@oracle.com, ming.lei@redhat.com, chenxiang66@hisilicon.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, dm-devel@redhat.com, beanhuo@micron.com Subject: Re: [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops() Date: Tue, 22 Mar 2022 15:03:04 +0100 [thread overview] Message-ID: <306df4cf-0ee0-2b1e-044c-aed6c70122f9@suse.de> (raw) In-Reply-To: <a5e42012-c1fc-082e-e636-594abc07dd70@huawei.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Hannes Reinecke <hare@suse.de> To: John Garry <john.garry@huawei.com>, Christoph Hellwig <hch@lst.de> Cc: axboe@kernel.dk, bvanassche@acm.org, martin.petersen@oracle.com, chenxiang66@hisilicon.com, damien.lemoal@opensource.wdc.com, linux-kernel@vger.kernel.org, ming.lei@redhat.com, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, dm-devel@redhat.com, linux-scsi@vger.kernel.org, jejb@linux.ibm.com, beanhuo@micron.com Subject: Re: [dm-devel] [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops() Date: Tue, 22 Mar 2022 15:03:04 +0100 [thread overview] Message-ID: <306df4cf-0ee0-2b1e-044c-aed6c70122f9@suse.de> (raw) In-Reply-To: <a5e42012-c1fc-082e-e636-594abc07dd70@huawei.com> 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 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-03-22 14:03 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-22 10:39 [PATCH RFC 00/11] blk-mq/libata/scsi: SCSI driver tagging improvements John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops() John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 11:18 ` Christoph Hellwig 2022-03-22 11:18 ` [dm-devel] " Christoph Hellwig 2022-03-22 11:33 ` John Garry 2022-03-22 11:33 ` [dm-devel] " John Garry 2022-03-22 12:16 ` Hannes Reinecke 2022-03-22 12:16 ` [dm-devel] " Hannes Reinecke 2022-03-22 12:30 ` John Garry 2022-03-22 12:30 ` [dm-devel] " John Garry 2022-03-22 14:03 ` Hannes Reinecke [this message] 2022-03-22 14:03 ` Hannes Reinecke 2022-03-22 15:17 ` John Garry 2022-03-22 15:17 ` [dm-devel] " John Garry 2022-03-22 15:31 ` Hannes Reinecke 2022-03-22 15:31 ` [dm-devel] " Hannes Reinecke 2022-03-23 2:57 ` Bart Van Assche 2022-03-23 2:57 ` [dm-devel] " Bart Van Assche 2022-03-23 9:01 ` John Garry 2022-03-23 9:01 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 02/11] scsi: core: Add SUBMITTED_BY_SCSI_CUSTOM_OPS John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 11:20 ` Christoph Hellwig 2022-03-22 11:20 ` [dm-devel] " Christoph Hellwig 2022-03-22 10:39 ` [PATCH 03/11] libata: Send internal commands through the block layer John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 11:20 ` Christoph Hellwig 2022-03-22 11:20 ` [dm-devel] " Christoph Hellwig 2022-03-22 11:36 ` John Garry 2022-03-22 11:36 ` [dm-devel] " John Garry 2022-04-07 14:32 ` John Garry 2022-04-07 14:32 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 04/11] scsi: libsas: Send SMP " John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 11:23 ` Christoph Hellwig 2022-03-22 11:23 ` [dm-devel] " Christoph Hellwig 2022-03-22 14:37 ` John Garry 2022-03-22 14:37 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 05/11] scsi: libsas: Send TMF " John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 06/11] scsi: core: Add scsi_alloc_request_hwq() John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 07/11] scsi: libsas: Send internal abort commands through the block layer John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 08/11] scsi: libsas: Change ATA support to deal with each qc having a SCSI command John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 09/11] scsi: libsas: Add sas_task_to_unique_tag() John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 10/11] scsi: libsas: Add sas_task_to_hwq() John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 10:39 ` [PATCH 11/11] scsi: hisi_sas: Remove private tag management John Garry 2022-03-22 10:39 ` [dm-devel] " John Garry 2022-03-22 11:30 ` [PATCH RFC 00/11] blk-mq/libata/scsi: SCSI driver tagging improvements Hannes Reinecke 2022-03-22 11:30 ` [dm-devel] " Hannes Reinecke 2022-03-22 12:17 ` John Garry 2022-03-22 12:17 ` [dm-devel] " John Garry
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=306df4cf-0ee0-2b1e-044c-aed6c70122f9@suse.de \ --to=hare@suse.de \ --cc=axboe@kernel.dk \ --cc=beanhuo@micron.com \ --cc=bvanassche@acm.org \ --cc=chenxiang66@hisilicon.com \ --cc=damien.lemoal@opensource.wdc.com \ --cc=dm-devel@redhat.com \ --cc=hch@lst.de \ --cc=jejb@linux.ibm.com \ --cc=john.garry@huawei.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-ide@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=ming.lei@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.