On Tuesday 27 January 2009, Sarah Sharp wrote: > > 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. That's a separate problem, though -- it's not packetization, it's inability to queue lots of data at once. Let's try to be clear on the problems, to avoid settling prematurely on solutions. > > 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. ;) Presumably those scatterlists would already be DMA-mapped... Did you consider just passing lists of URBs, instead? Or other data structures that aren't more or less specific to the block layer code? > > 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? I don't know what he said. ;) The MMC stack already has a way to kick in some block layer bounce buffer logic already. It seems trivial to kick in. I suspect that having usb-storage kick that in when running over WUSB would be a good solution to that particular issue; lots better than re-whacking HCDs to grok scatterlists. And really easy, too... - Dave -- 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
