On Wed, Nov 06, 2019 at 08:33:01PM +0000, Derrick, Jonathan wrote: > On Thu, 2019-11-07 at 05:27 +0900, Keith Busch wrote: > > On Wed, Nov 06, 2019 at 08:14:41PM +0000, Derrick, Jonathan wrote: > > > Yes that problem exists today > > > > Not really, because we're currently using unamanged interrupts which > > migrate to online CPUs. It's only the managed ones that don't migrate > > because they have a unchangeable affinity. > > > > > and this set limits the exposure as it's > > > a rare case where you have a child NVMe device with fewer than 32 > > > vectors. > > > > I'm deeply skeptical that is the case. Even the P3700 has only 31 IO > > queues, yielding 31 vectors for IO services, so that already won't work > > with this scheme. > > > Darn you're right. At one point I had VMD vector 1 using NVMe AQ, > leaving the 31 remaining VMD vectors for NVMe IO queues. This would > have lined up perfectly. Had changed it last minute and that does break > the scheme for P3700.... > > > But assuming you wanted to only use devices that have at least 32 IRQ > > vectors, the nvme driver also allows users to carve those vectors up > > into fully affinitized sets for different services (read vs. write is > > the one the block stack supports), which would also break if alignment > > to the parent device's IRQ setup is required. > > Wasn't aware of this. Fair enough. Marked the series with "Changes Requested", waiting for a new version. Lorenzo
