mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Any USB gadget AIO interface users?
@ 2011-03-22 17:12 Sarah Sharp
  2011-03-23 14:34 ` Jeff Moyer
  0 siblings, 1 reply; 4+ messages in thread
From: Sarah Sharp @ 2011-03-22 17:12 UTC (permalink / raw)
  To: linux-usb, libusb-devel, linux-kernel

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.  The AIO core also seemed to be largely
unmaintained.  Is this still true?

Sarah Sharp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Any USB gadget AIO interface users?
  2011-03-22 17:12 Any USB gadget AIO interface users? Sarah Sharp
@ 2011-03-23 14:34 ` Jeff Moyer
  2011-03-23 19:02   ` Sarah Sharp
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Moyer @ 2011-03-23 14:34 UTC (permalink / raw)
  To: Sarah Sharp; +Cc: linux-usb, libusb-devel, linux-kernel, linux-aio

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?

> 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.

Cheers,
Jeff

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Any USB gadget AIO interface users?
  2011-03-23 14:34 ` Jeff Moyer
@ 2011-03-23 19:02   ` Sarah Sharp
  2011-03-23 20:50     ` Jeff Moyer
  0 siblings, 1 reply; 4+ messages in thread
From: Sarah Sharp @ 2011-03-23 19:02 UTC (permalink / raw)
  To: Jeff Moyer; +Cc: linux-usb, libusb-devel, linux-kernel, linux-aio

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.

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 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?

Sarah Sharp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Any USB gadget AIO interface users?
  2011-03-23 19:02   ` Sarah Sharp
@ 2011-03-23 20:50     ` Jeff Moyer
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff Moyer @ 2011-03-23 20:50 UTC (permalink / raw)
  To: Sarah Sharp; +Cc: linux-usb, libusb-devel, linux-kernel, linux-aio

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-03-23 20:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-22 17:12 Any USB gadget AIO interface users? Sarah Sharp
2011-03-23 14:34 ` Jeff Moyer
2011-03-23 19:02   ` Sarah Sharp
2011-03-23 20:50     ` Jeff Moyer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®