mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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?




  reply	other threads:[~2014-04-03  4:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31 14:46 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-10 10:01     ` Christoph Hellwig
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome