Note that this doesn't provide any reason not to get rid of that flag a bit later in the 2.5 series.
This sub-thread addresses different issues related to bulk queueing. Ones I agree also need to be handled consistently. >>>I'd like to see all those URBs terminated immediately, but >>>I'm sure others would like to see them all executed as if nothing had >>>happened. >> >>I agree that it makes no sense to continue processing later URBs queued >>on that same endpoint. Similarly when the endpoint halts, or one URB >>is canceled. The transfer stream has been broken, and recovery needs >>to be done before the endpoint can be used again. Having some other >>URB queued (or not, in the non-queued case) doesn't change the need for >>that recovery before proceeding. > > Ah, and now the counter-example: I see what you're saying, but I can't see it as an important case since there are two straightforward ways to address that problem that come quickly to mind. > Consider a usb-storage 'read' command. I now have 5 URBs queued on a > bulk-in endpoint to transfer the data. Behind that, I have a 6th URB which > is supposed to fetch the status. > > If the read fails due to short read, I still want the 6th URB to execute so > I can get the status. From the last time I did this analysis, I recall that doing status through bulk transfers is only one of several modes supported by USB-storage (it can go over interrupt, bulk, and maybe even control as I recall). Only in the read-bulk-only case could that particular kind of queuing potentially work. All other cases _must_ submit status urbs only after data phases complete, and that works just as well for this one too. So it's simpler not to try to add special code for this case ... or, considering how infrequently errors happen, to recognize the "status urb auto-killed" case, and re-issue it specially! > Yes, I could not queue that URB until after the transfer is completed, but > it would be more effecient (read: faster and lower CPU requirement) if I > could queue it ahead of time (or during the sequence of read-URBs for the > data). The cost to queue the URB is going to be about the same regardless of when it's queued, too. The only advantage to doing it (in that one case) early would be some reduced latency for the completion. That's typically going to be about a microframe (for EHCI). > Realistically, I can come up with needs for both behaviors (kill the queue > and don't kill the queue). I think we need a method to differentiate > between them. I think "need" is really overstating it given the two solutions I pointed out above. > And, just to throw something out there... suppose I'm queueing bulk-in URBs > to transfer some data. But, my CPU is slow (for whatever reason -- perahps > I'm decoding too much p0rn DVD), and I don't actually submit the 3rd URB > until after the 2nd completed. But, the 2nd completed with a short > packet.... so what's the behavior? If this the "short packet is no error" case, the third URB gets submitted and works as usual. But if it's an abnormal termination, then your question becomes more interesting: > If #2 and #3 were submitted before #2 > completed, then #3 would terminate (under your rules, see above). But, now > we have a race condition where #3 doesn't terminate because it doesn't > appear to be part of a long queue of URBs. My "storage-0104.patch" had a partial fix for this, interlocking the completion handler with the code submitting new URBs. (You may recall that patch taught usb-storage how to queue its data stage URBs, thereby getting about twice as much performance out of EHCI and a few percent more out of OHCI ... I may never have tested it with UHCI.) I say "partial" only because there was an SMP case I ignored. But I think the basic solution there generalizes nicely: - Completion handler can prevent submissions of new URBs on that queue - HCD handles all urbs actually submitted - Then there's that SMP case (I needed a more global spinlock) The basic observation is that handshaking the add-to-queue (submit_urb) code and the take-from-queue (urb completion) code lets you completely prevent such races. Since the HC is going to halt queue processing on error, the HCD can automatically handle variants of that potential race like #2 finishing (abnormal/error), then driver queuing #3, before the completion for #2 is called (but after the error). > It's those sorts of sceanrios I'm worried about. Again, I return to my > argument about scatter-gather, which is what I see as the primary use of > queued URBs. I can understand that from the usb-storage perspective, although the only unique issue I can see is the _potential_ to share DMA mappings (which might matter on non-x86 hardware). That's not how I've used it ... :) I'd rather get basic issues solved first, and defer optimizations until they turn out to be necessary. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
