On 11/11/2016 11:22 AM, Hannes Reinecke wrote:
On 11/11/2016 05:35 PM, Christoph Hellwig wrote:
On Fri, Nov 11, 2016 at 04:46:34PM +0100, Hannes Reinecke wrote:
This patch enables full scsi-mq support for the hpsa driver.
Due to some reports of performance regressions this patch
also adds a parameter 'use_blk_mq' which can be used to
disable multiqueue support if required.
This patch looks odd to me. The hardware does not seem to support
multiple submission queues, which makes exposing nr_hw_queues > 1
rather pointless given that the block layer (using blk-mq or the legacy
path) can already steer completions to the submitting cpu.
Well, it's the same as with megasas and mpt3sas. Each of those have
a single MMIO register where the driver writes the address of the
command into. What exactly the hardware does in the back doesn't
really matter here; the command is in memory and the hardware can
access it as it sees fit. So from that point of view we can assume
having a submission queue to match the completion queue;
With that setup we do have a contention point on the single command
register, but that's about it.
That's just wrong. We can have multiple completion queues without having
multiple submission queues. And for that to work ideally, you tell
blk/scsi-mq that you have 1 queue, since that is what you have. You
don't get great submission side scaling, but we can't pull that stuff
out of thin air. How you interface to the hardware DOES matter, it's the
whole point of multiple submission queues. Trying to make up some
imaginary 1:1 mapping between submission and completion queues is
nonsensical, when it doesn't exist.
We still should benefit from scsi-mq, though.
Sure, but with 1 submission queue.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
