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.
