Re: [PATCH v11 2/2] usb: xhci: enable secondary interrupters and route transfers per slot

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jan 27, 2026 at 10:39:00AM +0800, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
> 
> 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.
> 
> This is not about increasing USB link throughput, but about avoiding a
> driver-imposed single hot spot.

What do you mean exactly by "hot spot"?  Usually this is a good thing,
driver code is in the cache, as are the data structures, so this keeps
data flowing well with less latencies.  Why would you not want this?

> On hosts that already provide multiple
> MSI/MSI-X vectors and independent event rings, routing all completions
> through interrupter 0 creates unnecessary contention (serialized event
> handling/locks and coupled moderation), increasing CPU cost and tail
> latency under many active devices/endpoints.

So this is a MSI routing issue, not a cpu cache issue?

And exactly what type of contention is happening here?  How can it be
measured and noticed?  The latencies involved in USB are huge due to the
protocol and hardware, why would a CPU even notice such things?

> Using secondary interrupters
> simply matches the hardware's design, similar in spirit to merged
> xHCI-sideband work: exploit available parallel paths rather than
> funneling all events through one.

What do you mean by "secondary interrupters"?  The sideband work was for
a totally different issue, whereby the normal hardware and CPU was
bypassed to allow it to remain powered down and to save battery life.
Spreading interrupts across CPU cores does the exact opposite of that,
ensuring that cores can NOT go to sleep when the work should be only
done by one of them.

In short, please post numbers showing how this really is noticable
somehow.

thanks,

greg k-h