From: Dan Williams > Yes, but I think we need to centralize the context under which > commands are submitted. The complicating factor is the mix of > synchronous command submission and interrupt driven asynchronous > command queuing. I think we can simplify it by making it all > submitted from a single event queue context. I'm investigating if > that is a workable solution... Given that the entire network stack runs from (I believe) 'process level' contexts (NAPI functions), it is rather surprising that the USB stack runs everything from the actual interrupt context (or in the callers context with interrupts disabled). For large SMP systems disabling interrupts and acquiring global locks like that just doesn't scale. Even for 'normal' URB it ought to be possible to queue them for later submission - rather than having to immediately put them on the transfer ring. Ideally the 'event' ring ought to be large enough for all the events that the controller can add. This is approximately 1 per TD (2 for short RX) and one per command. So much like the 'reserved command' slots (which aren't implemented correctly) there should probably be 'reserved event' slots - otherwise the event ring might become full (if the host stops servicing interrupts for any length of time.) Avoiding the need for large numbers of events really means restricting the number of TD (that request interrupts). isoc and disk might limit this anyway, but network traffic can queue a much larger number of TD. I've seen 20 tx TD (all nearly 60kB) queued. Every time one completes another is immediately added. usbnet needs to be taught how to do BQL, and something (somehow) reduce the number of interrupts. (end of ramble) David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
