Running some basic tests with this patch ( https://tglx.de/~tglx/patches.tar ) applied on my device, at first glance, the affinity feature is working. I didn't run stress test to test the stability, and the Kernel version we used is a bit old, so I only applied change in this 2 patches -> Subject: genirq: Add interrupt redirection infrastructure -> Subject: PCI: dwc: Enable MSI affinity support And adding if check on irq_chip_redirect_set_affinity() and irq_set_redirect_target() to avoid cpumask_first() return nr_cpu_ids int irq_chip_redirect_set_affinity(struct irq_data *data, const struct cpumask *dest, bool force) { .... .... if (target >= nr_cpu_ids) target = smp_processor_id(); irq_data_update_effective_affinity(data, cpumask_of(target)); } static void irq_set_redirect_target(struct irq_desc *desc) { const struct cpumask *m = irq_data_get_effective_affinity_mask(&desc->irq_data); unsigned int cpu = cpumask_first(m); if (cpu >= nr_cpu_ids) cpu = smp_processor_id(); WRITE_ONCE(desc->redirect.target_cpu, cpu); } May I ask, would this patch be officially added to the 6.14 kernel ? Thanks On Sat, Mar 8, 2025 at 3:49 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Fri, Mar 07 2025 at 19:10, Tsai Sung-Fu wrote: > > Thanks for your detailed explanation and feedback, I am a bit confused about the > > #4 you mentioned here -> > > > >> 4) Affinity of the demultiplex interrupt > > > > Are you saying there is a chance to queue this demultiplexing IRQ event > > to the current running CPU ? > > The demultiplexing interrupt (currently a chained handler, which is > hidden from /proc/irq/) stays at the affinity which the kernel decided > to assign to it at startup. That means it can't be steered to a > particual CPU and nobody knows to which CPU it is affine. You can only > guess it from /proc/interrupts by observing where the associated > demultiplex interrupts are affine to. > > So ideally you want to be able to affine the demultiplexing interrupt > too. That requires to switch it to a regular interrupt for > simplicity. We could expose those hidden chained handlers affinity too, > but that needs some surgery vs. locking etc. > > > And that's really an approach worth to try, I will work on it. > > I've played with this on top of variant of Marc's changes to use MSI > parent interrupts for such controllers too: > > https://lore.kernel.org/all/20241204124549.607054-1-maz@xxxxxxxxxx/ > > A completely untested and largely uncompiled preview is here: > > https://tglx.de/~tglx/patches.tar > > The MSI parent parts are in flux. Marc will look at them in the next > weeks, but I picked them up because it simplifies the whole business a > lot. If you find bugs in that series, you can keep them :) > > Thanks, > > tglx
