On Wed, Jan 28, 2009 at 02:08:18AM +0000, David Vrabel wrote: > David Brownell wrote: >> On Tuesday 27 January 2009, Inaky Perez-Gonzalez wrote: >>> The problem of having a single URB per s/g node is the overhead. When >>> you need to insert headers in the middle of a data stream (for example) >>> every so many bytes, the URB overhead starts to be felt. >> >> That overhead is linear in the number of bytes, not in the >> number of URBs. One URB of 64KB; or sixteen of 4KB; same >> overhead. Scatterlists are irrelevant. > > They might have the same overhead but they're not equivalent because > you've lost the application layer framing. The is a separate issue to > what Inaky is talking about. > > For best throughput WUSB requires the largest wMaxPacketSize of 3584. If > 64 KiB transfer is split into 16x 4KiB transfers, the device will see > one 3.5 KiB packet, one (short!) 512 B packet and so on. This does not > work. For USB 3.0, it gets even worse. The wMaxPacketSize is always set to 1024 for bulk endpoints, but those endpoints can send and receive bursts of packets (up to at a time 16). If the host controller hardware doesn't get the whole s-g list at once, say because there's a turn around time to queue the next 1024 byte URB, then the hardware won't be able to burst the packets efficiently. > Either: > > 1. The s-g list is passed to the HCD (if the hardware is capable). Is there a reason we can't add a flag to indicate an HCD is capable of processing scatter-gather lists? Support could be added to HCDs over time. I'm already biased towards this solution though. ;) > or, > > 2. URBs with s-g elements that are not a multiple of wMaxPacketSize > length are linearized into one (or more) suitable bounce buffers. Inaky said this was a lot of work, correct? Sarah -- 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
