Re: Any USB gadget AIO interface users?

[Jeff Moyer <jmoyer@redhat.com>]

Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:

> On Wed, Mar 23, 2011 at 10:34:08AM -0400, Jeff Moyer wrote:
>> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>> 
>> > Has anyone successfully used the asynchronous I/O gadgetfs interface
>> > before?  Specifically, has anyone used it for high-bandwidth isochronous
>> > traffic?
>> >
>> > I ask because I remember discovering about four years ago that there
>> > were several brain-twisty bugs in the in-kernel asynchronous I/O layer
>> > that gadgetfs uses.
>> 
>> Weren't they addressed?  And are you looking to use the gadgetfs aio
>> interface now, or are you looking to get rid of it?  In other words,
>> what's the real motivation behind the question?
>
> I was looking to use it.  The bug in question I remember was about
> cancellation, but I would have to dig in my mailbox from 2007 to find
> the exact issue.

Reference counting in that path is usually the tricky part to get right.
We had one person looking to make use of aio in his driver, iirc, and
that was a major concern of his, as well.  If we can get both of your
requirements together, maybe we can make progress.

> The biggest problem I remember when I was looking at using the aio core
> to replace the ioctls in the usbfs subsystem with true aio operations
> was there was an issue with operation ordering.  In the kernel to
> userspace interface for USB, we want asynchronous operations to a
> particular file to be queued to the hardware in the order they are
> submitted.  So if the userspace application submits asynchronous read A,
> then asynchronous read B, then the buffer for read B doesn't get queued
> to the USB host controller before the buffer for read A.  Otherwise you
> get transmission reordering on the bus, and USB devices aren't very
> happy.

The AIO infrastructure doesn't guarantee that.  It does the setup
required in the context of the calling process, and then queues the
operation to the underlying "device" (where device, in most cases, is a
file or a block device, which means submit_bio is called).  After that,
the AIO code has no control over ordering.  If there are specific
ordering requirements in the application, then maybe AIO isn't the right
fit.  I don't know enough about your application to say.

>> > The AIO core also seemed to be largely unmaintained.  Is this still
>> > true?
>> 
>> Surely you should at least cc the aio list when asking such a question!
>> Anyway, the aio core is maintained by several folks, but nobody is doing
>> active development in that area, to my knowledge.
>
> Sorry, I forgot the aio mailing list existed. :)  In 2007, there was
> lots of talk of using syslets or fibrils in the aio core, and Zack Brown
> had some patches for that, but it seemed like nothing really came out of
> that.  Has anything new been added to the AIO core since then?

Nothing came of it, no.  There haven't been any attempts since, either.

Cheers,
Jeff