On Sat, May 23, 2020 at 08:19:58AM -0700, Bart Van Assche wrote: > On 2020-05-21 19:39, Ming Lei wrote: > > You may argue that two hw queue may share single managed interrupt, that > > is possible if driver plays the trick. But if driver plays the trick in > > this way, it is driver's responsibility to guarantee that the managed > > irq won't be shutdown if either of the two hctxs are active, such as, > > making sure that hctx->cpumask + hctx->cpumask <= this managed interrupt's affinity. > > It is definitely one strange enough case, and this patch doesn't > > suppose to cover this strange case. But, this patch won't break this > > case. Also just be curious, do you have such in-tree case? and are you > > sure the driver uses managed interrupt? > > I'm concerned about the block drivers that use RDMA (NVMeOF, SRP, iSER, > ...). The functions that accept an interrupt vector argument > (comp_vector), namely ib_alloc_cq() and ib_create_cq(), can be used in PCI_IRQ_AFFINITY isn't used in RDMA driver, so RDMA NIC uses non-managed irq. > such a way that completion interrupts are handled on another CPU than > those in hctx->cpumask. As I explained, this patchset doesn't rely on that interrupts have to be fired on hctx->cpumask, and it only changes the submission io path, which is blk-mq's generic code path which doesn't depend on any driver's specific behavior. Please let us know if your concerns are addressed. Thanks, Ming
