> > 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 simple way to meet Badari's current goal is: calculate the length
of the whole iovec, use that to allocate the right size i/o buffer, then
have the AIO write path gather data into that, and the AIO read "retry"
path scatter data out of it after reads complete.
Then there'd be the asymmetry that IN endpoints can be halted using read()
but not with readv() -- similarly for OUT and write() -- but that's a very
livable issue.
> 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).
Those are appropriate requirements with O_DIRECT file descriptors, where
userspace already expects extra restrictions on syscall parameters.
I think USB's restriction would be that packets must never span pages;
neither usb_request nor urb restrict buffer start addresses, other than
for dma-safety. (The "512 byte alignment" restriction makes sense for
disk-centric file I/O.)
> A more difficult approach has the kernel
> drivers copying data when the alignment isn't right.
The current driver copies, and it'd be simpler not to try changing that
except as part of a general "support direct i/o" update. At which point
all the black magic would be in a new address_space.direct_IO() method,
kicking in for {aio_,}{read,write}(), and {read,write}v() syscalls.
- Dave
-------------------------------------------------------
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
