> >I'd prefer to get rid of the notion of one-shot interrupt transfers, for
> >consistency. That isn't the model for any other "periodic" transfers.
>
> I think better consistency would not come from removing one-shot interrupts,
> but instead resubmitting any URB based on a flag (urb->resubmit)? Resubmission
> could certainly be useful for Bulk transfers; e.g. if you want to read many MB
> of data.
Uck. I want each MByte to go into its own buffer, and
never want to see any overwrite the next without first
letting me process it.
> Could also be useful for iso.
The ISO ring mechanism is already a "resubmission", to use your
term, though it's not exactly "unsubmitted" (unlinked).
> Probably not very useful for Control,
> but why create a special case (like has been done with resubmitting interrupts)?
The USB model includes one-shot requests (bulk, control) and
periodic (re)scheduled requests (interrupt, ISO) which reserve
bandwidth in advance.
The current API reflects that model pretty well except that
ISO scheduling is a bit funky (rings AND multiple segments,
also HCD differences), and one HCD has this strange one-shot
behavior (I call bug, you call feature).
> >Likewise, I prefer the simpler model of having only ONE way to make
> >an interrupt urb stop after submission: usb_urb_unlink(). Adding more
> >modes multiplies the code paths, and multiplies ways to create bugs ...
>
> I like simpler models too, but the problem with usb_urb_unlink() is you're
> effectively aborting the URB. It completes once, then you abort and it
> completes again with -ENOENT (I think). Thus, unless you're doing all
> processing inside the completion handler, the URB gets 'corrupted' after the
> completion. For usbdevfs, where it's read back by the userspace app well after
> the completion, only the error is seen.
That is, you want a different simplification: there is ONLY one-shot
behavior.
> Also, to perform a single-execution (one-shot) interrupt, 2x the work is done
> (it completes, is resubmitted, and is aborted). This causes significant
> overhead that really isn't necessary.
Only if you believe that one-shot "periodic" calls make sense. Seems to
me that's heading _away_ from doing USB periodic scheduling right.
> >> <snip>
> >> queued non-resubmitting interrupt URBs would be very useful when
> >> used by usbdevfs (i.e., userspace programs).
> >
> >Not to be too contrary here, but I'm not sure that's the right model to have
> >for the periodic schedules. The HCDs seem like they should be populating
> >the periodic schedule as interrupt/iso urbs are submitted, and then going
> >away until either an IRQ signals periodic transactions completed, or until
> >the urbs are descheduled/unlinked. No mucking around otherwise; that
> >seems like it'd complicate transaction translators more than necessary.
>
> I might not understand HCDs well enough to follow exactly what you're saying,
> but I don't think the HCD should have to get any more involved (it should
> handle URBs at the same points in time) than it currently is, if urb->resubmit
> functionality is added.
Adding urb->resubmit is changing periodic processing ... and even the
URB scheduling model.
> >There are other models. Maybe SHM ring buffers, seen by userspace,
> >could be how usbdevfs should deal with interrupt and iso transfers. Or
> >maybe something else that can be scheduled once, then left alone.
>
> Yes (actually this was my approach on the first usbdevfs interrupt patch, but in
> a kludgy way), but the problem there is buffer overruns cause the (userspace)
> app to lose data, while the device has no idea that data was lost. If the
> device isn't getting polled, it will either buffer up the data or at least know
> that data was lost. Plus using ring buffers or shared mem starts getting
> significantly more complicated than the current model (which isn't necessarily
> always a bad thing).
The basic conflict here is between the USB model, whereby periodic
requests (interrupt, iso) have guaranteed bandwidth, while scheduling
in Linux is normally non-realtime (and so can't guarantee service limits
implied by that guaranteed bandwidth).
The nice thing about a ring buffer API model is that it can adapt to
various scheduling models -- just have a way the ring can record
that data was lost at a particular spot. That way if something kills
irq latency (non-realtime) badly enough that data is lost (instead
of just buffered) then device drivers will see clean errors. That
should never happen in a realtime system (guaranteed irq latency
might affect ringsize though).
> >The "API model" question came up on LKML recently;
>
> I really need to read LKML more. :-)
I get it in bursts via hypermail, myself. Just happened on that
discussion, it ties into hotplug and system autoconfiguration.
- Dave
> >Johannes mentioned
> >to Linus that USB periodic transfers (interrupt, iso) don't fit into the pipe/socket
> >style model of bulk. (And maybe said as much about control urbs too ... I
> >would have! :) I think it's fair to say that the "usbdevfs" API could be on
> >the "rethink this" list for 2.5 ... maybe backported, maybe not.
>
> Hmm...
>
> --
> Dan Streetman
> [EMAIL PROTECTED]
>
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
