Re: [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints

[Jan Kiszka <jan.kiszka@siemens.com>]

On 20.08.26 18:41, Jakub Kicinski wrote:
> On Wed, 19 Aug 2026 16:30:31 +0200 Florian Bezdeka wrote:
>> Some device drivers implement an IRQ balancing / spreading mechanism
>> based on cpumask_local_spread() and irq_set_affinity_hint() (deprecated)
>> or irq_set_affinity_and_hint().
> 
> Not an expert on IRQs, but this may make the API even more confusing.
> irq_set_affinity_and_hint() not setting the affinity seems odd.
> 
> I'd go the other way and either have irq_update_affinity_hint() apply
> the affinity if it's safe to do so, or create a new function for
> "defaults".
> 
> Really, the drivers are dumb here, they are just trying to pass to 
> the core a hint which is: This is Nth of X IRQs, please spread them on
> the NUMA node where the device is attached. Ideally this (Nth of X)
> should even be part of request_irq() args. IRQ core already knows the
> device/NUMA node. Drivers juggling multiple flavors of uAPI-shaped API
> is... not very scalable. People rarely get this right.

Fully agree: drivers should not set affinities. They should just express
desires or additional constraints. The ultimately resulting affinity for
an IRQ should be the result of the various constraints that kernel and
userland may express via NUMA placements, isolcpus, some dynamic
isolation/grouping constraints, or you-name-it.

I think we need a big picture how things should eventually look like and
then develop a strategy how to step-wise convert existing code.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center