From: John Garry <john.garry@huawei.com>
To: Bart Van Assche <bvanassche@acm.org>, <axboe@kernel.dk>,
<damien.lemoal@opensource.wdc.com>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <hch@lst.de>, <ming.lei@redhat.com>,
<hare@suse.de>
Cc: <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: Wed, 23 Mar 2022 09:01:33 +0000 [thread overview]
Message-ID: <378065de-3cb8-b44f-66e9-747960bcd990@huawei.com> (raw)
In-Reply-To: <e74776f0-505b-8b4f-effd-519bce9bdc79@acm.org>
On 23/03/2022 02:57, Bart Van Assche wrote:
> On 3/22/22 03:39, 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.
>
Hi Bart,
> Custom ops shouldn't be required for this. See e.g. how tmf_queue
> is used in the UFS driver for an example of a queue implementation
> with custom operations and that does not require changes of the block
> layer core.
The UFS code uses a private tagset (in ufs_hba.tmf_tag_set) for only
management of TMF tags/memories. This tagset does not really have any
custom operations. All it has is a stub of .queue_rq CB in
ufshcd_queue_tmf() and that is because this CB is compulsory.
As for the idea of having multiple tagsets per shost with real custom
operations, this idea was mentioned before, but I think managing
multiple tagsets could be trouble. For a start, it would mean that we
need a distinct allocation of reserved and regular tags, and sometimes
we don't want this - as Hannes mentioned earlier, many HBAs have low
queue depth and cannot afford to permanently carve out a bunch of
reserved tags.
Thanks,
John
WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com>
To: Bart Van Assche <bvanassche@acm.org>, <axboe@kernel.dk>,
<damien.lemoal@opensource.wdc.com>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <hch@lst.de>, <ming.lei@redhat.com>,
<hare@suse.de>
Cc: linux-scsi@vger.kernel.org, chenxiang66@hisilicon.com,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org, dm-devel@redhat.com,
beanhuo@micron.com
Subject: Re: [dm-devel] [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops()
Date: Wed, 23 Mar 2022 09:01:33 +0000 [thread overview]
Message-ID: <378065de-3cb8-b44f-66e9-747960bcd990@huawei.com> (raw)
In-Reply-To: <e74776f0-505b-8b4f-effd-519bce9bdc79@acm.org>
On 23/03/2022 02:57, Bart Van Assche wrote:
> On 3/22/22 03:39, 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.
>
Hi Bart,
> Custom ops shouldn't be required for this. See e.g. how tmf_queue
> is used in the UFS driver for an example of a queue implementation
> with custom operations and that does not require changes of the block
> layer core.
The UFS code uses a private tagset (in ufs_hba.tmf_tag_set) for only
management of TMF tags/memories. This tagset does not really have any
custom operations. All it has is a stub of .queue_rq CB in
ufshcd_queue_tmf() and that is because this CB is compulsory.
As for the idea of having multiple tagsets per shost with real custom
operations, this idea was mentioned before, but I think managing
multiple tagsets could be trouble. For a start, it would mean that we
need a distinct allocation of reserved and regular tags, and sometimes
we don't want this - as Hannes mentioned earlier, many HBAs have low
queue depth and cannot afford to permanently carve out a bunch of
reserved tags.
Thanks,
John
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-03-23 9:01 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
2022-03-22 14:03 ` [dm-devel] " 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 [this message]
2022-03-23 9:01 ` 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=378065de-3cb8-b44f-66e9-747960bcd990@huawei.com \
--to=john.garry@huawei.com \
--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=hare@suse.de \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.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: link
Be 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.