From: Hannes Reinecke <hare@suse.de>
To: Chad Dupuis <chad.dupuis@qlogic.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"hch@lst.de" <hch@lst.de>,
linux-scsi <linux-scsi@vger.kernel.org>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>,
Saurav Kashyap <saurav.kashyap@qlogic.com>,
Nilesh Javali <nilesh.javali@qlogic.com>
Subject: Re: Blk-mq/scsi-mq Tuning
Date: Fri, 30 Oct 2015 08:44:59 +0100 [thread overview]
Message-ID: <56331FFB.9010703@suse.de> (raw)
In-Reply-To: <D256A425.229C0%chad.dupuis@qlogic.com>
On 10/28/2015 09:11 PM, Chad Dupuis wrote:
> Hi Folks,
>
> We¹ve begun to explore blk-mq and scsi-mq and wanted to know if there were
> any best practices in terms of block layer settings. We¹re looking
> specifically at the FCoE and iSCSI protocols.
>
> A little background on the queues in our hardware first: we have a per
> connection transmit queue and multiple, global receive queues. The
> transmit queues are not pegged to a particular CPU. The receive queues
> are pegged to the first N CPUs where N is the number of receive queues.
> We set the nr_hw_queues in the scsi_host_template to N as well.
>
Weelll ... I think you'll run into issues here.
The whole point of the multiqueue implementation is that you can tag the
submission _and_ completion queue to a single CPU, thereby eliminating
locking.
If you only peg the completion queue to a CPU you'll still have
contention on the submission queue, needing to take locks etc.
Plus you will _inevitably_ incur cache misses, as the completion will
basically never occur on the same CPU which did the submissoin.
Hence the context needs to be bounced to the CPU holding the completion
queue, or you'll need to do a IPI to inform the submitting CPU.
But if you do that you're essentially doing single-queue submission,
so I doubt we're seeing that great improvements.
> In our initial testing we¹re not seeing the performance scale as we would
> expect so we wanted to see if there some Œknobs¹ if you will that we could
> try tuning to try to increase the performance. Also, one question we did
> have is there an official API to be able to set the CPU affinity of the
> hw_ctx_queues?
>
As above, given the underlying design I'm not surprised.
But above you mentioned 'per-connection submission queues'; from which
one could infer that there are several _hardware_ submission queues?
If so, _maybe_ we should look into doing MC/S (in the iSCSI case),
which would allow us to keep the 1:1 submission/completion ratio
preferred by blk-mq and still use several queues ... Hmm?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-10-30 7:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 20:11 Blk-mq/scsi-mq Tuning Chad Dupuis
2015-10-29 18:04 ` Bart Van Assche
2015-10-30 7:44 ` Hannes Reinecke [this message]
2015-10-30 13:25 ` Chad Dupuis
2015-10-30 13:38 ` Hannes Reinecke
2015-10-30 14:12 ` Chad Dupuis
2015-10-30 15:00 ` Hannes Reinecke
2015-10-30 20:15 ` Mike Christie
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=56331FFB.9010703@suse.de \
--to=hare@suse.de \
--cc=bvanassche@acm.org \
--cc=chad.dupuis@qlogic.com \
--cc=giridhar.malavali@qlogic.com \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=nilesh.javali@qlogic.com \
--cc=saurav.kashyap@qlogic.com \
/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).