On Thu, 5 Feb 2004, Martin Diehl wrote: > > I can see two possible difficulties. One is that the driver may have been > > handed a transfer buffer that is not guaranteed to be long enough to hold > > an entire maximum-size packet; the driver would have to allocate a bounce > > buffer and that might amount to a serious overhead (particularly since the > > bad consequences are restricted to a relatively small set of devices). > > Good point, bounce buffers might really hurt. But I'm not sure how serious > this concern is, because it's only IN direction we have to think about. > > For network-like drivers the allocation of rx-skb is under control. Well, > storage might be a problem - AFAIK the buffers come from the scsi layer. I > might be wrong but my naive expectation would be thos buffers would be > multiple of 512 bytes anyway so it would serve without bounce buffer even > for highspeed?
For usb-storage transfers that come by way of the block layer, yes, all the transfer lengths will be multiples of 512. Other transfers that originate in the high-level SCSI drivers usually have shorter transfer lengths, although the buffers themselves are 512 bytes -- I'm not sure if it's wise to depend on that however. Transfers that originate from user processes (via scsi-generic) may have shorter buffers. Or longer ones; isn't there a CD Digital Audio command to read raw audio data that fills a 2352-byte buffer for each frame? There's another issue which may be relevant. Some USB-IDE bridge devices don't like it if the transfer length specified in the SCSI CDB differs from the requested USB transfer length. For IN transfers where the USB length is larger than the CDB length this may not matter; I'm not certain. Matt Dharm knows all about this kind of problem. > > The second difficulty is that the maxpacket size can be fairly large, up > > to 1024 bytes for high-speed interrupt and isochronous endpoints. The > > additional overhead won't be extreme but it might be worth considering. > > Well, it doesn't need to perfectly cover any possible case. Something like > rounding up bulk/interrupt and control data IN buffers to the next > multiple of 64 would help out in many cases I believe. That seems like a reasonable thing to do. 64 isn't very big, and if high-speed devices require this kind of treatment we can worry about it later. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
