On Tuesday 27 January 2009, David Vrabel wrote: > They might have the same overhead but they're not equivalent because > you've lost the application layer framing. Not entirely; though, be careful when you say "application", since that's far away, through the block layer. In this case what's lost is the fact that the *block layer* does not care about certain boundaries ... although DMA infrastructure most certainly does. > The is a separate issue to what Inaky is talking about. Right, which makes it an argument I can almost accept, instead of one that makes me want to reject it out of hand. The issue being raised is quite clear. Though not one very relevant to USB 3.0 and its 1 KB wMaxPacketSize ... :) > 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. The reason I say I can "almost" buy this is that in DMA terms, the largest possible zero-copy transfer *is* about 3.5 KiB ... unless the system has an IOMMU to coalesce pages so that the DMA engine sees a single 64 KiB transfer. (And if it does, then the WUSB adapter won't see 16x transfers.) If you want a good solution, you'll need to finger a different problem. :) Or to put it differently: without an IOMMU you're going to need to do a lot of buffer copying regardless. Once 3.5K by direct DMA from the first page (plus header), then seven via bouce buffers, one more direct DMA, and the rest with bounce buffers. Right? 2 KiB wMaxPacketSize would work nicely though. And ISTR another issue that's not yet been raised: the max packet size can change. Something is moved between TX and RX, radio S/N degrades, suddenly 3.5KiB is no longer doable... - 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
