Am Montag, 2. Juli 2007 schrieb David Brownell:
> > Since each sg element refers to a page or more of data,
> > the maximum number of elements is restricted by the maximum allowed
> > transfer size (which is currently 512 KB or 128 pages on i386). The
> > default max transfer size set by usb-storage is 120 KB. Larger values
> > would lead to larger throughput but the benefit would be slight.
>
> The relevant factor their being per-request overhead: usb-storage
> must send a command, transfer data, get a response; and scatterlist
> code only improves the "transfer data" bits. That is, it can get
> rid of wasted bus time between data packets ... but not wasted time
> surrounding the command or response.
But if we curtail the list, we will need more overhead per payload,
as the payload transfered by each transfer gets smaller.
> > However none of this matters if you don't insist on allocating a
> > separate URB for each sg element.
>
> As noted above, for full speed devices we could get similar throughput
> with slightly more clever implementation of scatterlist handling. If
> the HCD has good hardware support for queueing, and the system has fair
> IRQ latency, recycling as few as five URBs might give similar throughput
> to the current "URB per element" approach.
I don't like the idea of the sg code differentiating between the HCDs.
BTW, it seems to me that the current sg code is underutilizing the sg
capability inherent in EHCI's qtds.
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
