From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@fb.com>
Cc: Christoph Hellwig <hch@lst.de>,
Keith Busch <keith.busch@intel.com>,
tglx@linutronix.de, agordeev@redhat.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: blk-mq: allow passing in an external queue mapping V3
Date: Thu, 15 Sep 2016 16:42:12 +0200 [thread overview]
Message-ID: <20160915144212.GA26430@lst.de> (raw)
In-Reply-To: <de5c219e-fe1f-7524-6054-995ae2f734ae@fb.com>
On Thu, Sep 15, 2016 at 08:34:42AM -0600, Jens Axboe wrote:
> I was going to ask about splitting it, but that looks fine, I can pull
> that in.
>
> The series looks fine to me. My only real concern is giving drivers the
> flexibility to define mappings, I don't want that to evolve into drivers
> (again) doing stupid things wrt mappings. As long as we keep it strictly
> as a tunnel for passing mappings defined by the (previous blk-mq) core
> code, then that's fine.
So my earlier versions just passed in the affinity mask and left
all the mapping in the core. This doesn't really work anymore with
the sibling aware code so I had to add a method. That being said there
are some drivers that might want slightly different mappings.
For example skd (if converted to blk-mq) has MSI-X vectors for it's up
to four queues, but it also has MSI-X vectors for misc book keeping
before those, so we'd need a version of our PCI mapping that adds an
offset to add to queue number when assining the MSI-X vectors.
That being said I structured the map_queues interface so it can't do
anything crazy - it can just build up the cpu to queue mapping array
so there isn't exactly a whole lot of crazy things a driver could do.
next prev parent reply other threads:[~2016-09-15 14:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 14:18 blk-mq: allow passing in an external queue mapping V3 Christoph Hellwig
2016-09-14 14:18 ` [PATCH 01/13] genirq/msi: Add cpumask allocation to alloc_msi_entry Christoph Hellwig
2016-09-19 7:30 ` Alexander Gordeev
2016-09-19 13:50 ` Christoph Hellwig
2016-09-20 7:06 ` Alexander Gordeev
2016-09-20 8:58 ` Thomas Gleixner
2016-09-14 14:18 ` [PATCH 02/13] genirq/affinity: Provide smarter irq spreading infrastructure Christoph Hellwig
2016-09-21 12:29 ` Alexander Gordeev
2016-09-22 21:14 ` Thomas Gleixner
2016-09-14 14:18 ` [PATCH 03/13] genirq/msi: Switch to new " Christoph Hellwig
2016-09-21 12:23 ` Alexander Gordeev
2016-09-22 8:51 ` Alexander Gordeev
2016-09-14 14:18 ` [PATCH 04/13] genirq/affinity: Remove old irq spread infrastructure Christoph Hellwig
2016-09-14 14:18 ` [PATCH 05/13] pci/msi: Retrieve affinity for a vector Christoph Hellwig
2016-09-14 14:18 ` [PATCH 06/13] blk-mq: don't redistribute hardware queues on a CPU hotplug event Christoph Hellwig
2016-09-14 14:18 ` [PATCH 07/13] blk-mq: only allocate a single mq_map per tag_set Christoph Hellwig
2016-09-14 14:18 ` [PATCH 08/13] blk-mq: remove ->map_queue Christoph Hellwig
2016-09-14 14:18 ` [PATCH 09/13] blk-mq: allow the driver to pass in a queue mapping Christoph Hellwig
2016-09-14 14:18 ` [PATCH 10/13] blk-mq: provide a default queue mapping for PCI device Christoph Hellwig
2016-09-19 7:33 ` Alexander Gordeev
2016-09-19 13:49 ` Christoph Hellwig
2016-09-14 14:18 ` [PATCH 11/13] nvme: switch to use pci_alloc_irq_vectors Christoph Hellwig
2016-09-23 22:21 ` Sagi Grimberg
2016-09-26 15:09 ` Christoph Hellwig
2016-09-14 14:18 ` [PATCH 12/13] nvme: remove the post_scan callout Christoph Hellwig
2016-09-14 14:18 ` [PATCH 13/13] blk-mq: get rid of the cpumask in struct blk_mq_tags Christoph Hellwig
2016-09-15 14:44 ` Christoph Hellwig
2016-09-15 14:46 ` Jens Axboe
2016-09-15 14:40 ` blk-mq: allow passing in an external queue mapping V3 Keith Busch
2016-09-15 14:32 ` Christoph Hellwig
2016-09-15 14:34 ` Jens Axboe
2016-09-15 14:42 ` Christoph Hellwig [this message]
2016-09-15 14:44 ` Jens Axboe
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=20160915144212.GA26430@lst.de \
--to=hch@lst.de \
--cc=agordeev@redhat.com \
--cc=axboe@fb.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).