RFC USB: HCD/EHCI: giveback of URB in tasklet context
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 of 4 patches 0 repliesNew
2 of 4 patches are in this archive. The cover letter announces 4.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | USB: HCD: support giveback of URB in tasklet context | +0 | 1 reply | |
| 1/4 | USB: HCD: support giveback of URB in tasklet context | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
Quoted 10 lines · On Monday 10 June 2013 10:03:00 Alan Stern wrote:
[Thomas and Steve, please see the question below.]
On Mon, 10 Jun 2013, Ming Lei wrote:
That isn't clear. It is documented that USB completion handlers are called with local interrupts disabled. An IRQ arriving before the tasklet starts up might therefore be serviced during the short interval before the tasklet disables local interrupts, but if that happens it would mean that the completion handler would be delayed.
That is what tasklets do by definition, isn't it?
Quoted 3 lines
In effect, you are prioritizing other IRQs higher than USB completion handlers. Nevertheless, the total time spent with interrupts disabled will remain the same.
It pobably slightly increases. You have colder caches twice. And potentially you swich CPUs.
Quoted 6 lines
(There's one other side effect that perhaps you haven't considered. When multiple URBs are addressed to the same endpoint, their completion handlers are called in order of URB completion, which is the same as the order of URB submission unless an URB is cancelled. By delegating the completion handlers to tasklets, and particularly by using per-CPU tasklets, you may violate this behavior.)
This is quite serious. It mustn't happen.
Regards
Oliver