Re: Control of IRQ Affinities from Userspace

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, Nov 26 2025 at 10:20, Florian Bezdeka wrote:
> On Tue, 2025-11-25 at 17:31 +0100, Thomas Gleixner wrote:
>> > This question can not be answered with yes/no. It depends. Affinities
>> > are based on the default_smp_affinity during creation. But as it turned
>> > out there are drivers that overwrite those affinities after IRQ
>> > creation.
>> 
>> Which ones?
>
> The problem at hand is the stmmac
> (drivers/net/ethernet/stmicro/stmmac/stmmac_main), which is pulled in by
> a couple of others like the dwmac_intel in our case.
>
> Searching for the problematic irq_set_affinity_hint() call in
> drivers/net/ethernet reveals more "affected" drivers but each of them
> requires some double checking. In some cases the supplied cpumask or the
> "time of the call" might be OKish.

The question is whether that affinity hint has a functional requirement
to be applied or not. I don't think so because those interrupts can be
moved by userspace as it sees fit.

So it's easy enough to make this "set" part conditional and restrict it
to some TBD mask (housekeeping, default ...) under some isolation magic.

>> > The user normally configures the number of HW queues that the NIC should
>> > use. In most cases in combination with some HW packet filters to achieve
>> > best packet separation. IMHO the user should not have to deal with any
>> > (additional) CPU mask on that level. RT tuning will / should handle
>> > that.
>> 
>> How so. The kernel magically knows what the user wants?
>
> We can already identify the IRQs that belong to a certain hardware queue
> (NAPI threads) and move it when necessary. I just wanted to express that
> there might not be a need for an additional API / cpumask.

Ok.

>> Not a so dead road :)
>
> Grml... I definitely fat-fingered the query. Anyway, this housekeeping
> API still seems very boot-time oriented to me. Can't see yet where this
> housekeeping cpumasks are filled up by the cgroup/cpuset infrastructure.
>
> cgroups/cpusets don't care about "isolation" in that sense yet. It's
> just about cpumasks for compute. Am I missing something?

There is work in progress on various related ends:

  https://lore.kernel.org/all/20251105210348.35256-1-frederic@kernel.org
  https://lore.kernel.org/all/20251120145653.296659-1-gmonaco@redhat.com
  https://lore.kernel.org/all/20251105043848.382703-1-longman@redhat.com
  https://lore.kernel.org/all/20251121143500.42111-3-frederic@kernel.org

There is certainly more going on it that area, but those were the bits
and pieces I could remember from the top of my head. Waiman and Gabriele
should be able to fill in some blanks, but that discussion should move
to LKML then.

Thanks,

        tglx