Re: [PATCH v10 2/2] usb: xhci: enable secondary interrupters and route

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jan 26, 2026 at 04:58:28PM +0800, raoxu wrote:
> Some xHCI hosts expose multiple MSI/MSI-X vectors and support multiple
> interrupters with independent event rings, but Linux commonly routes all
> transfer completions through interrupter 0.
> 
> Allocate a small capped set of secondary interrupters in xhci_mem_init()
> (MAX_SECONDARY_INTRNUM, default 4) and request up to the matching number
> of IRQ vectors (bounded by what PCI core provides).  Dispatch each vector
> to its interrupter via the per-vector irq_ctx.
> 
> Route transfers per USB device (slot) by assigning vdev->interrupter at
> device allocation time and programming the interrupter target (slot
> context + TRB_INTR_TARGET) from that selection, so completions land on the
> selected event ring.  Drain a slot's secondary event ring at selected
> command completion boundaries to reduce late-event artifacts when teardown
> happens on interrupter 0.

This all says what is happening, but not why.  Why does it matter to
spread out the interrupts?  What is the downside of not doing so?  What
is the benifit of doing so?  What benchmarks or real tests show any
changes at all here?

Given that the USB data path is very slow, because the hardware is slow,
moving interrupts around to other processors feels like an odd thing to
do as it's normally only done for busses that have real data throughput
needs (i.e. keep the irqs next to the cpus where the data is being
processed, like the networking stack does).  For USB this feels odd as
once the data is handled by the host controller driver, the cpu affinity
is totally lost so any benifit you were expecting from spreading
interrupts out is lost.

So again, why is any of this needed at all?  What hardware and workloads
actually matter here?

thanks,

greg k-h