On Tue, 18 Nov 2003, Oliver Neukum wrote: > > 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.) > > Exactly. These drivers may have other requirements for minum sizes > or alignments. How do you build that knowledge into the helper functions? > Ideally storage would specify its requirements to scsi core. > Failing that I don't think we should build workarounds into usbcore.
While other drivers in general might have other requirements, I can't imagine what other requirements a USB driver might have. But I agree that it would make sense to have the top-level SCSI drivers refuse to do direct I/O on user buffers that aren't page-aligned. > > Although this becomes moot if we go for the single big bounce buffer, I > > No. It is relevant for deciding whether a bounce buffer must be used or not. > > > 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. > > You can have an sglist that is perfectly valid from a transfer size point > of view, yet cannot be savely dmaed on an incoherent machine. > The issue is read/writing to memory sharing a cacheline with a transfer > buffer. For this very reason drivers had to switch to seperately > allocated transfer buffers on several occasions. All right -- this isn't critical to the main problem, but I still don't get your point. There's nothing special here about USB. If a transfer buffer is suitable for DMA to a SCSI device (assuming a cache-incoherent architecture) then it must also be suitable for a USB device. It should be up to the top-level SCSI sg and st drivers to insure that the buffers meet the cacheline requirements; there's no point in making every one of the low-level drivers do that. For that matter, even on an incoherent machine it usually won't matter. Since the buffers are in userspace, there _won't_ be any access to memory sharing a cacheline with the buffer unless either the user is doing asynchronous I/O or the memory is mapped in another process. Of course the SCSI drivers don't check for either of these. And if either is true then direct I/O isn't safe no matter how the buffers are aligned. But if the I/O is synchronous and the memory isn't mapped elsewhere, then there's no possibility of bad cache accesses during the I/O. So the lack of alignment won't make things any worse than they already are. 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
