Date: Wed, 8 Apr 2015 18:21:50 -0400 From: Alexander Kabaev <kabaev@gmail.com> To: Jim Harris <jimharris@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r281280 - head/sys/dev/nvme Message-ID: <20150408182150.03c2b832@kan> In-Reply-To: <201504082146.t38LkJ9s058300@svn.freebsd.org> References: <201504082146.t38LkJ9s058300@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, 8 Apr 2015 21:46:19 +0000 (UTC) Jim Harris <jimharris@FreeBSD.org> wrote: > Author: jimharris > Date: Wed Apr 8 21:46:18 2015 > New Revision: 281280 > URL: https://svnweb.freebsd.org/changeset/base/281280 > > Log: > nvme: fall back to a smaller MSI-X vector allocation if necessary > > Previously, if per-CPU MSI-X vectors could not be allocated, > nvme(4) would fall back to INTx with a single I/O queue pair. > This change will still fall back to a single I/O queue pair, but > allocate MSI-X vectors instead of reverting to INTx. > > MFC after: 1 week > Sponsored by: Intel > > Modified: > head/sys/dev/nvme/nvme_ctrlr.c > > Modified: head/sys/dev/nvme/nvme_ctrlr.c > ============================================================================== > --- head/sys/dev/nvme/nvme_ctrlr.c Wed Apr 8 21:10:13 > 2015 (r281279) +++ head/sys/dev/nvme/nvme_ctrlr.c Wed > Apr 8 21:46:18 2015 (r281280) @@ -1144,9 +1144,17 @@ > nvme_ctrlr_construct(struct nvme_control /* One vector per IO queue, > plus one vector for admin queue. */ num_vectors = > ctrlr->num_io_queues + 1; > - if (pci_msix_count(dev) < num_vectors) { > + /* > + * If we cannot even allocate 2 vectors (one for admin, one > for > + * I/O), then revert to INTx. > + */ > + if (pci_msix_count(dev) < 2) { > ctrlr->msix_enabled = 0; > goto intx; > + } else if (pci_msix_count(dev) < num_vectors) { > + ctrlr->per_cpu_io_queues = FALSE; > + ctrlr->num_io_queues = 1; > + num_vectors = 2; /* one for admin, one for I/O */ > } > > if (pci_alloc_msix(dev, &num_vectors) != 0) { Huh, Linux just falls back to as many vectors as it can and just allocates them between per-cpu queues in a round-robin manner. I think is is a better approach than what we have here, would you consider it? -- Alexander Kabaev [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUlqf8ACgkQQ6z1jMm+XZbkrACgkCASyf6ZLPccX3kZ9hqpHSa4 6ZEAmQGvCWmkCdtEV94sU6F5MMttgkoz =C4p0 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150408182150.03c2b832>