From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEC98223DEA for ; Mon, 26 Jan 2026 09:10:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769418606; cv=none; b=A9TIUh7DcjCaU+U0uAnFAJQfWp27YKELBNd8yA9zKP2iZ2cIEoZvMkYNwi2qltFxxxiOzxxvbhg3uC2NRvjMzeFM3s1+qUD9tJLGAiCiW8K9Hbv9hieoReymZcRr+jjsClZtI7OmGl7445f7uBXFnsQY+qQl7ruvmhd/VYfAJTs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769418606; c=relaxed/simple; bh=L1kcoyNXsO+ZqCeRNQnXDwBA/OqQBylpI/5EAK0BnzM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K4AKmpz4C61+bcKQKKXMn4dkNHn04upYQM63x06XybdTLK0vHzTVkC2lHgxTmYi4Eo/5Pj7/SoZs0HNSdaSdOhQlbECFzmjhEeTTioRHjrqLOc6E9JgJkJ1oRJ9fDsdVhBGk9DObFxEbSHhYA2HDprc5V3pkMrtpheomtv97ekg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ioAcbdam; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ioAcbdam" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF52EC116C6; Mon, 26 Jan 2026 09:10:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1769418605; bh=L1kcoyNXsO+ZqCeRNQnXDwBA/OqQBylpI/5EAK0BnzM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ioAcbdamNxOQwrUxuLIA382faGv5v012WbaYK2ws2tsLwCDMKz6njVmOuedjHAZ8l DY97uCazh/82Z8WMV1UxK9g1BO/bld3eopG1cdU2n5Smk0eJjLLG6LjJztSYsFOs8A rArwVMhT+dcQL59IIyV8egC0pz+W2UB/5yF0IsV8= Date: Mon, 26 Jan 2026 10:10:02 +0100 From: Greg KH To: raoxu Cc: kenny@panix.com, linux-usb@vger.kernel.org, mathias.nyman@linux.intel.com, michal.pecio@gmail.com, niklas.neronin@linux.intel.com, zhanjun@uniontech.com Subject: Re: [PATCH v10 2/2] usb: xhci: enable secondary interrupters and route Message-ID: <2026012644-chute-gangly-9b7b@gregkh> References: <1FCECDEA86461C52+20260126085828.803972-1-raoxu@uniontech.com> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FCECDEA86461C52+20260126085828.803972-1-raoxu@uniontech.com> 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