Christoph, Sagi: it seems you think /proc/irq/$IRP/smp_affinity
shouldn't be allowed if drivers support managed affinity. Is that correct?
Not just shouldn't, but simply can't.
But as it stands, things are just plain borked if an rdma driver
supports ib_get_vector_affinity() yet the admin changes the affinity via
/proc...
I think we need to fix ib_get_vector_affinity to not return anything
if the device doesn't use managed irq affinity.
Steve, does iw_cxgb4 use managed affinity?
I'll send a patch for mlx5 to simply not return anything as managed
affinity is not something that the maintainers want to do.
I'm beginning to think I don't know what "managed affinity" actually is. Currently iw_cxgb4 doesn't support ib_get_vector_affinity(). I have a patch for it, but ran into this whole issue with nvme failing if someone changes the affinity map via /proc.
That means that the pci subsystem gets your vector(s) affinity right and
immutable. It also guarantees that you have reserved vectors and not get
a best effort assignment when cpu cores are offlined.
You can simply enable it by adding PCI_IRQ_AFFINITY to
pci_alloc_irq_vectors() or call pci_alloc_irq_vectors_affinity()
to communicate post/pre vectors that don't participate in
affinitization (nvme uses it for admin queue).
This way you can easily plug ->get_vector_affinity() to return
pci_irq_get_affinity(dev, vector)
The original patch set from hch:
https://lwn.net/Articles/693653/
