On Fri, 3 Feb 2006, David Brownell wrote: > > It's not really a group of related requests; it's a single request for > > which the memory buffer consists of several discontiguous pieces. This is > > a significant distinction. With readv/writev you specify a single > > starting offset in the file, whereas with multiple requests you would have > > multiple starting offsets. > > Depends on how you look at it. For an I/O stream like a USB endpoint > (either host or peripheral roles) there's no seeking, so file offsets > are ignored/irrelevant. > > But one issue lurking there is a very good one: coalescing I/O, which > our APIs don't support. That's got to be done before a usb_request > (or on host side, an URB) is submitted. Compare two small i/o vectors, > going out over bulk endpoints and with page-aligned buffers, same data > even!, which must produce the same number of USB packets: > > A: 100 bytes at addr1, 512 bytes at addr2 > B: 512 bytes at addr2, 100 bytes at addr2 > > Request A always requires copying for the packet straddling offset 100 > (relative to message start) but request B never requires copying (so it > could support a full zerocopy I/O model via get_user_pages). That's a > key semantic issue which Badari's patch does not address.
That's a very good point. iovec aio needs to address alignment issues. The easiest answer for now is to require all buffers to be aligned on 512-byte boundaries (or 64 for full speed), in terms of both the buffer's start address and length (except for the last buffer in an iovec, which can have arbitrary length). A more difficult approach has the kernel drivers copying data when the alignment isn't right. > Now, if you ignore that issue, then it's _exactly_ "a group of related > requests" in all non-fault cases. Just as if the individual iovec > entries were always multiples of maxpacket (which I confess I was > assuming ... might be a big use case, but it's not required). > > Also, consider ISO transfers. Each packet can produce distinct faults, > and it's OK (but rare!) if for example every other packet hits a failure. > So an iovec of packets would not be a usable userspace I/O model, since > it would need to report the first failure and abort the other packets. Not necessarily. We could define the I/O model for iso transfers so that operations do not end when a failure occurs. On the other hand, this would require reporting a status and actual transfer length for each packet, which the iovec model does not support. It's not really suited for handling iso transfers. > > The idea makes sense to me. iovecs and aio are essentially orthogonal > > concepts, and the most general implementation would support both. An > > iovec would correspond to a single aio transfer, the only difference being > > that the memory buffer is scattered. > > Also, _something_ must handle coalescing I/O buffers to/from packets. Which > is something I'd rather keep out of the touching-hardware level drivers, > please! They have enough to deal with already, and software coalescing > logic is easily shared. There are USB peripheral DMA controllers that > can manage that coalescing, but only one comes to mind which would do > that on the host side. (And that's cheating, it's an OTG controller > where both roles share the same DMA...) If we require proper data alignment by the user then this isn't a problem. > Remember too that a write(fd, bufptr, n_page*PAGESIZE) syscall will need > to get morphed into kernel buffers. Right now gadgetfs is optimized for > small size and simplicity, so it copies things. That's not friendly for > high speed controllers... at some point it would be good to get rid of > the data buffer alloc + copy it does, using get_user_pages to provide the > "ideal" zerocopy-from-userspace semantics (given friendly alignments). Exactly. And if the hardware drivers implement scatterlist support, then midlevel components like gadgetfs will have to do even less work. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
