On Sat, Mar 16, 2013 at 09:11:34PM +0200, Anonymous wrote: > I'm writing a kernel driver for xhci. Why? We already have a Linux xhci driver. Why write another one? And why ask for questions anonymously? That's a bit strange, don't you think? > USB3 is used mainly for high-performance external disk drives. Not really, USB 3 is used for everything, my keyboard is USB 3 compliant :) > The driver receives a memory buffer to do DMA from (or to.) What driver? The storage driver? Or the host controller driver? And which USB storage driver spec are you referring to? > Buffer can come from either user-land or kernel-land. In Linux? Where? What driver does that? > So driver can't be sure the buffer is mapped into kernel virtual > address-space. Why not? This should be a simple thing to check. I'm guessing here that you aren't talking about Linux. What operating system are you writing a driver for? > However, in 64-bit mode (x86-64), kernel holds entire physical > memory mapped into section of virtual address space. > So it's (relatively) low cost to do a clflush-pass over the buffer > to make sure none of the buffer is cached. > There are two options for doing the I/O > 1 - Conventional > Use PCIe cache-coherency (snooping) without touching the buffer. > 2 - Using no-snoop > Flush the buffer using clflush as described above. Make sure PCIe > no-snoop is enabled in the PCIe capability, and set the No-Snoop bit > in all transfer TRBs for the buffer. > > I've benchmarked both methods and there seems to be no performance > difference whatsoever. The disks used are far from the fastest on > the marked, but reasonable (40MB - 70MB per second peak speed.) > > So what puzzles me is -- why ever use the xhci no-snoop capability????? 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. 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
