From: Matias Bjorling <m@bjorling.me>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@fb.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFC] blk-mq: support for shared tags
Date: Wed, 02 Apr 2014 21:10:12 -0700 [thread overview]
Message-ID: <533CDF24.9030902@bjorling.me> (raw)
In-Reply-To: <20140402074632.GA11359@lst.de>
On 04/02/2014 12:46 AM, Christoph Hellwig wrote:
> On Tue, Apr 01, 2014 at 05:16:21PM -0700, Matias Bjorling wrote:
>> Hi Christoph,
>>
>> Can you rebase it on top of 3.14. I have trouble applying it for testing.
>
> Hi Martin,
>
> the series is based on top of Jens' for-next branch. I've also pushed out a
> git tree to the blk-mq-share-tags.2 branch of
>
> git://git.infradead.org/users/hch/scsi.git
>
> to make testing and reviewing easier.
>
Thanks.
Regarding the tags API. I think the best approach is a struct
blk_mq_tags_reg. That'll make their parameters very visible in the
drivers. I'll send a patch with the change, using the nvme driver as an
example.
>> For nvme, there's need for two separate types of queues. The admin queue
>> (before initializing blk-mq) and the actual hardware queues.
>>
>> Should we allow the driver to get/put tags before initializing blk-mq?
>> Or let drivers implement their own framework?
>
> What do you mean with initializing blk-mq? We need to allocate data
> structures for sure, and I don't see much else in terms of initialization
> in blk-mq.
>
For the nvme driver, there's a single admin queue, which is outside
blk-mq's control, and the X normal queues. Should we allow the shared
tags structure to be used (get/put) for the admin queue, without
initializing blk-mq? or should the drivers simply implement their own
tags for their admin queue?
next prev parent reply other threads:[~2014-04-03 4:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 14:46 [RFC] blk-mq: support for shared tags Christoph Hellwig
2014-03-31 14:46 ` [PATCH 1/4] blk->mq: stop pre-initializing req->special Christoph Hellwig
2014-03-31 14:46 ` [PATCH 2/4] blk-mq: initialize request on allocation Christoph Hellwig
2014-03-31 14:46 ` [PATCH 3/4] blk-mq: move request structures into struct blk_mq_tags Christoph Hellwig
2014-04-09 16:23 ` Jens Axboe
2014-04-09 16:23 ` Jens Axboe
2014-04-10 10:01 ` Christoph Hellwig
2014-04-11 2:42 ` Jens Axboe
2014-04-11 2:42 ` Jens Axboe
2014-04-11 7:33 ` Christoph Hellwig
2014-04-11 13:56 ` Jens Axboe
2014-03-31 14:46 ` [PATCH 4/4] blk-mq: support shared tag maps Christoph Hellwig
2014-04-02 0:16 ` [RFC] blk-mq: support for shared tags Matias Bjorling
2014-04-02 7:46 ` Christoph Hellwig
2014-04-03 4:10 ` Matias Bjorling [this message]
2014-04-03 7:36 ` Christoph Hellwig
2014-04-03 16:45 ` Matias Bjorling
2014-04-03 18:01 ` Christoph Hellwig
2014-04-03 21:47 ` Matias Bjorling
2014-04-04 15:19 ` Christoph Hellwig
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=533CDF24.9030902@bjorling.me \
--to=m@bjorling.me \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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.