> > But one observation I had was that " irq_set_affinity_and_hint(*irqs++, > > NULL);" is essentially a no-op and we end up relying on the initial > > placement from pci_alloc_irq_vectors(). > > Yes you are, assuming you're not binding them before in your call chain. > > > Even though in these tests we > > were not able to reproduce it, but with this distribution there is a > > chance we end up clustering the mana queue IRQs, while other vCPUs are > > not running any network load. > > That sounds like an IRQ balancer bug which you're unable to reproduce. > > > It's because the placement depends on > > system-wide IRQ state at allocation time. > > I don't understand this point. The > > irq_set_affinity_and_hint(*irqs++, NULL); > > simply means: I trust system IRQ balancer to pick the best CPU for my > IRQ at runtime. It doesn't refer any "IRQ state at allocation time". > > > The linear approach however gaurantees each queue IRQ lands on a > > distinct vCPU regardless of system state. Even after stressing the cpus > > using stress-ng, we did not observe any significant throughput drop. > > If you just do nothing, it would lead to the same numbers, right? What > does that "non-significant throughput drop" mean? It sounds like the > linear approach is slightly worse.
The numbers are not worse, they almost same in both the cases. > > -- > > So, as you can't demonstrate solid benefit for the 'linear' IRQ placement, > I would just stick to the no-affinity logic. Thankyou Yury, We are investigating on more test scenarios and trying to capture numbers with both, your proposed change and the one from this patch. We will keep you updated about the results. - Vennela
