>>>With the way it is right now, with enforcing bandwidth reservation,
>>>there's the possibility that resubmit will fail for lack of bandwidth.
>>
>>In the pseudocode above, where is that possibility? I don't see it.
>
>
> Umm, I just described it.
>
> How about this:
I added a label for what I think is your third column.
> hub driver other driver [ PER-ENDPOINT ACTION ]
> submit_urb bandwidth allocated
> callback bandwidth deallocated
NYET ^^^^^^^^^^^^^^^^^^^^^
> submit_urb bandwidth allocated
NOT! ^^^^^^^^^^^^^^^^^^^^^
> submit_urb failed, insufficient bandwidth
No, the bandwidth wouldn't have been de-allocated until after the
callback returned ... and since the callback submitted an urb,
it was never de-allocated. (That's the "NYET".) No failure.
The second driver is clearly broken, it has no business using
the hub interface's endpoint! But I'll assume it's some other
thread in the hub driver that decided to do that, so it was
a legit attempt to queue a second transfer.
That "NOT!" is something I didn't add because it wouldn't
come up unless queue lengths got greater than 1, which wasn't
what I was describing. In fact the only time submit_urb
allocates bandwidth is if it's the first urb queued to that
endpoint. (I said that some other places in this thread. The
bandwidth doesn't get allocated twice.)
So your picture, updated, should resemble:
Activity #1 Activity #2 Endpoint Action
----------- ----------- ---------------
submit schedule, reserving bandwidth
complete () (still scheduled, qlen = 0)
submit (still scheduled, qlen = 1)
(re)submit (still scheduled, qlen = 2)
hcd queuecheck qlen != 0, don't de-schedule
Is that clearer?
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
