> > > Thinking about it, (like regular vectored IO) it makes sense to return
> > > success if we already queued up part of IO, in case of and error.
> > > Isn't it ? This way, one can go and wait for those IOs to finish.
> >
> > Doesn't make a lot of sense to me, but then I'm probably missing
> > something by having seen about zero context for this notion of
> > merging two radically different I/O models. Got any URLs for LKML
> > discussion about that?
> >
> > AIO is all about one thing: decoupling the submission of an I/O request
> > from its completion. Applications can issue any number of requests and
> > let them complete whenever the OS manages it ... then apps will collect
> > completion status whenever it's convenient to them. Usefully, it's an
> > exact match for the low level I/O model of usb_request (on the peripheral
> > or gadget side) or URB (on the host side). Call it non-threaded I/O and
> > you'd be on the track of what folk like most about it. And likewise,
> > what bothers a few relgious nuts most deeply about it ... but generally,
> > not anyone who writes code that talks directly with the hardware. ;)
> >
> > readv/writev is all about a different thing: coupling the synchronous
> > issuance and completion of a _group_ of related requests.
>
> 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.
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.
> > It does not map
> > directly to any of the controller level interfaces of USB, and the closest
> > match is the synchronous scatterlist API ... a library on top of usbcore.
> > The synchronization is explicitly threaded, and there's some very careful
> > attention paid to fault semantics (at least, in USB there is).
>
> (Slightly off-topic... Do you think it would make sense to move
> scatterlist support directly into the host controller drivers? We already
> have something very much like it in place for iso transfers. It could
> save a lot of work allocating URBs and such if we used it for large
> bulk transfers.)
Or alternatively get rid of the special casing for ISO, which is the
approach I took on the peripheral side in the "gadget" API. It's no
longer needed now that we have sane queueing semantics, although it
probably simplifies some of the host-side periodic scheduling to be
able to batch things. (That could use its a new $SUBJECT, if you want
to discuss and/or provide patches ...)
> > I think you can see why I'm wondering about the basic concept underlying
> > those patches. I could understand writing a library to map readv/writev
> > calls into aio, and arranging to use that for filetypes that don't have
> > any direct implementation for those syscalls; easy to agree to that.
>
> 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...)
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).
> Once you think of it like that, it's
> clear that an I/O submission either fails immediately or else completes
> some time later. When it is complete, the user should be able to find out
> how much data was transferred and retrieve an error code (if the transfer
> terminated early because of an error).
>
> Badari's patch didn't seem to behave this way, which is why I raised the
> question initially.
Yes, that's some of the careful attention that needs to be paid to fault
semantics. :)
- 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
