public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Sagi Grimberg <sagig@dev.mellanox.co.il>
Cc: Jens Axboe <axboe@kernel.dk>,
	James Bottomley <JBottomley@Parallels.com>,
	Nicholas Bellinger <nab@linux-iscsi.org>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 12/15] scsi: initial blk-mq support
Date: Thu, 6 Feb 2014 08:16:15 -0800	[thread overview]
Message-ID: <20140206161615.GA16916@infradead.org> (raw)
In-Reply-To: <52F349F9.7090509@dev.mellanox.co.il>

On Thu, Feb 06, 2014 at 10:38:17AM +0200, Sagi Grimberg wrote:
> Both you and Nic offer a single HW queue per sdev.
> I'm wandering if that should be the LLD's decision (if chooses to
> use multiple queues)?
> 
> Trying to understand how LLDs will fit in a way they exploit
> multi-queue and actually
> maintain multiple queues. SRP/iSER for example maintain a single
> queue per connection
> (or session in iSCSI). Now with multi-queue all requests of that
> shost will eventually
> boil-down to posting on a single queue which might transition the
> bottleneck to the LLDs.
> 
> I noticed virtio_scsi implementation is choosing a queue per command
> based on current
> processor id without any explicit mapping (unless I missed it).
> 
> I guess my question is where do (or should) LLDs plug-in to this mq scheme?

Just using blk-mq helps with lock contention and cacheline issues, while
being conceptually simple, that's why it's the priority.  See the
proposal I sent before the patch series for more details.

That being said if you have simple enough patches for real multiqueue
support I'd be more than happy to carry them along.

  reply	other threads:[~2014-02-06 16:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 12:41 [PATCH 00/15] A different approach for using blk-mq in the SCSI layer Christoph Hellwig
2014-02-05 12:41 ` [PATCH 01/15] block: rework flush sequencing for blk-mq Christoph Hellwig
2014-02-06  2:08   ` Muthu Kumar
2014-02-06 16:18     ` Christoph Hellwig
2014-02-05 12:41 ` [PATCH 02/15] blk-mq: support at_head inserations for blk_execute_rq Christoph Hellwig
2014-02-06  2:27   ` Muthu Kumar
2014-02-06 16:17     ` Christoph Hellwig
2014-02-06 17:05       ` Muthu Kumar
2014-02-06 17:10         ` Christoph Hellwig
2014-02-05 12:41 ` [PATCH 03/15] blk-mq: divert __blk_put_request for MQ ops Christoph Hellwig
2014-02-05 12:41 ` [PATCH 04/15] blk-mq: handle dma_drain_size Christoph Hellwig
2014-02-05 12:41 ` [PATCH 05/15] blk-mq: initialize sg_reserved_size Christoph Hellwig
2014-02-05 12:41 ` [PATCH 06/15] scsi: reintroduce scsi_driver.init_command Christoph Hellwig
2014-02-05 12:41 ` [PATCH 07/15] block: remove unprep_rq_fn Christoph Hellwig
2014-02-05 12:41 ` [PATCH 08/15] scsi: cleanup scsi_end_request calling conventions Christoph Hellwig
2014-02-05 12:41 ` [PATCH 09/15] scsi: centralize command re-queueing in scsi_dispatch_fn Christoph Hellwig
2014-02-05 12:41 ` [PATCH 10/15] scsi: split __scsi_queue_insert Christoph Hellwig
2014-02-05 12:41 ` [PATCH 11/15] scsi: factor out __scsi_init_queue Christoph Hellwig
2014-02-05 12:41 ` [PATCH 12/15] scsi: initial blk-mq support Christoph Hellwig
2014-02-06  8:38   ` Sagi Grimberg
2014-02-06 16:16     ` Christoph Hellwig [this message]
2014-02-06 22:11   ` Nicholas A. Bellinger
2014-02-07  8:45     ` Mike Christie
2014-02-07 12:42       ` Christoph Hellwig
2014-02-07 12:51     ` Christoph Hellwig
2014-02-05 12:41 ` [PATCH 13/15] scsi: partially stub out scsi_adjust_queue_depth when using blk-mq Christoph Hellwig
2014-02-05 12:41 ` [PATCH 14/15] iscsi_tcp: use blk_mq Christoph Hellwig
2014-02-05 12:41 ` [PATCH 15/15] virtio_scsi: " Christoph Hellwig
2014-02-10 11:35 ` [PATCH 00/15] A different approach for using blk-mq in the SCSI layer Christoph Hellwig
2014-02-10 19:38   ` Nicholas A. Bellinger
2014-02-24 14:46 ` 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=20140206161615.GA16916@infradead.org \
    --to=hch@infradead.org \
    --cc=JBottomley@Parallels.com \
    --cc=axboe@kernel.dk \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=sagig@dev.mellanox.co.il \
    /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