> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Thursday, February 17, 2011 3:59 AM > To: Xu, Andiry > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: Re: About interrupters implementation > > On Wed, Feb 16, 2011 at 05:59:14PM +0800, Xu, Andiry wrote: > > Hi Sarah, > > > > As you know xHCI now uses MSI-X by default and has multiple vectors. > > However, it only has one ERST and event ring now and only uses the first > > MSI-X vector. > > > > I've made some patches to allocate multiple ERST and event rings, and > > make devices use different interrupters, to make use of all the MSI-X > > vectors. I've verified them and all the interrupters seem work fine. Do > > you have interest in this? I can send them out as RFC if you are > > interested. > > Yes, please send them. I don't know if I'll have time to test (since I > really should get to your AMD chipset patches first), but it would be > good to get review from the Linux USB community. > > What sort of policy do you have for which USB devices get sent to which > rings? ISTR that you have to decide which interrupter the device will > fall under when the device slot is first allocated, and you can't change > interrupters later unless you deallocate the slot. Is that correct? > Well, you can assign a device to use the same interrupter during its whole life. However, it's not fixed: you can decide the interrupter when queue the TRBs to the transfer ring, and a device can use different interrupters. For example, you can assign a device's control transfer to interrupter 0, and its bulk/isoc/interrupt transfer to interrupter 1. The policy can be flexible. > I would think that bulk-only devices like storage devices that have to > wait on transfers should be put on a ring with the interrupt modulation > interval set very low. At least that was my experience when I was doing > performance testing with USB3-attached SSDs. (The work to add the > interrupt modulation setting as a parameter to the driver is languishing > on my usb-perf branch, feel free to take anything from it.) > > However, I don't think you'd want to put a device that does very large, > bursty transfers on the same ring with say, an isoc device that needs > guaranteed bandwidth. > > So what policy did you decide on? > I have not decided the best policy yet. More investigation and performance tests are needed and as you says, different interrupter should have different IMOD set. Currently I simply assign devices to different interrupters to verify that all of them can work. The INTR_TARGET decision patch is separated so it can be replaced with better algorithm in the future. Thanks, Andiry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
