On Sat, Mar 16, 2013 at 10:00:38PM +0200, Anonymous wrote: > On 16/03/2013 09:44 PM, Greg KH wrote: > >I'm guessing here that you aren't talking about Linux. > > My question is not related to Linux. It's related to xhci, and I > asked on this mailing list because it's a public list with people > experienced in xhci. So are the usb-if lists, I suggest you ask there instead, they should be able to help you out a bit better. Asking technical questions anonymously, is a bit rude, don't you think? What benefit do we have here of actually answering them correctly? You are asking for a "favor" here, while not offering up anything in return. Usually the "return benefit" of answering questions on this list is the improvement of Linux. You are asking that I, or anyone else, spend our time to benefit some other operating system or company with no chance for a benefit. How is that even something that is ok to ask? Unless you don't want your manager to realize you are asking Linux developers for help, in that case, I understand, no one wants to admit those open source developers actually know anything, or can help out their own company in any way. :) > The question is: what possible scenario could make the no-snoop > option in transfer TRBs useful? I explained in detail why I believe > it's useless. > > >The "old" usb storage spec is extreemly slow, that is the issue. If you > >use the "new" spec, using streams, then you can start to actually use > >the hardware well, and then you might see some speedups. > > > >If you are using the old spec, then the delays in the driver and device > >itself will swamp any perceived speedups you might do here in the xhci > >driver for this. Look at a USB trace to verify this, it should be > >pretty obvious there. > > Right, but streams have nothing to do with the no-snoop option. > It's an unrelated feature. (Other than no-snoop bit also being > present on transfer TRBs posted to a stream transfer ring... - which > again, doesn't explain why no-snoop might give any benefit) No, you said you didn't see any speed differences, and I'm saying it has nothing to do with the snoop option for the host controller, and everything to do with the protocol being used and the speed of the device in implementing that protocol (look at the round-trip time of a single request.) Look at the data on the wire, and notice all of the delay and gaps that could have been filled with real data, but the protocol involved here (the "old" usb storage spec) prevents the full use of the xhci controller. Now if you actually were able to keep the host controller busy, then I would guess that the snooping option might actually be noticeable. But until you can do that, you can't even see it in the measurements, right? In short, be very aware of what you are measuring. Have you looked at the data on the wire and seen the large gaps? greg k-h -- 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
