On Mon, 17 Nov 2003, Oliver Neukum wrote: > Two remarks. > 1. Somebody supplying pathological buffers for direct IO gets the > performance he deserves
Very true. > 2. This isn't really the storage drivers problem. It should be solved > at a higher layer > So, if you need to do something in storage about it, choose the simple > solution and use a large bounce buffer. That's a good rationale. (Although the fix would go into the scatter-gather library which belongs to usbcore, not in usb-storage. After all, there may be other drivers at some future time that also want to do low-overhead s-g transfers.) > Secondly, I fear the analysis is incomplete. > On DMA incoherent machines, the size requirement is the transfer size > or a cacheline, whichever is larger and alignment needs to be on cacheline > boundaries. Although this becomes moot if we go for the single big bounce buffer, I disagree. If you're referring to the overall transfer size, in general that's much bigger than a cacheline. If you're referring to the small "splice" buffers of my previous message, they can all get merged into a single large buffer. Since the transfer is all in one direction (read or write) and the host doesn't touch the data while the transfer is in progress, the usual DMA-mapping interface should work out okay. It's true that the region to be mapped must be on a cacheline boundary, but the actual data buffer can be a subset of the mapped region. Alan Stern ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
