Re: [PATCH RFC 0/3] genirq: Allow drivers to respect userspace IRQ affinities

[Florian Bezdeka <florian.bezdeka@siemens.com>]

On Thu, 2026-08-20 at 17:12 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-19 16:30:29 [+0200], Florian Bezdeka wrote:
> …
> > The typical shortcoming of those implementations: They do not honor RT
> > relevant settings like the smp_default_affinity or isolated CPU cores.
> 
> "irqaffinity" if you refer to the boot command argument.
> "default_smp_affinity" if you refer to the proc file.

The latter. Sorry.

All the system configuration has to happen during runtime, not during
boot time. There is no "fixed" or "static" configuration that is known
at boot time here.

> 
> > Device IRQs are balanced over "all" or "all online CPUs".
> …
> > That raises the question why request_irq() is called on "link up" time,
> > while the low level vector allocation takes place during device probing.
> > At least that seems to be the common pattern. Can someone tell me why
> > this is done this way? Shouldn't we call request_irq() at the same time?
> 
> The IRQ vector is created while the system enumerates the IRQ-chips.
> Once the devices are enumerated (such as the NICs) the devices is linked
> with its IRQ. I think an exception are MSI-X devices which could ask for
> one or more interrupt and then (at device's probe time) the PCI core
> will link the requested amount of interrupts so their actual number
> could change.
> The driver _could_ request a "managed interrupt" which would be mapped
> to a specific CPU. The difference to a "regular interrupt" is that if
> that CPU goes down, the interrupt is not "moved" to another CPU. Instead
> is remains off and the driver needs to deal with this (this is common
> for NVME devices).

I can't see yet how managed interrupts could help here. 

Those device IRQs can happily be migrated, co-located and of course we
want them to be configurable by userspace (/proc/irq/<n>/ interface),
which is also not possible for managed IRQs.

> 
> If the device is not programmed (as in IP address has been assigned,
> link is up) then it should not create any interrupts. So it might be
> reasonable to not request an interrupt either.
> I *think* uarts do the same.
> 

I'm fine with that - and thanks for explaining the current
implementation again, it matches my understanding. But: There must be a
way that userspace can configure affinities for "un-requested" IRQs
already.

As already mentioned the /proc/irq/<n> interface gets populated on
request_irq() time, which might be too late to be able to set an
affinity before the first IRQ arrives.

Please note that the default_smp_affinity can also change during
runtime, so that we have to honor the current value each time we do the
balancing / spreading.

Florian