On Monday 18 April 2005 2:37 pm, Alan Stern wrote: > On Mon, 18 Apr 2005, Oliver Neukum wrote: > > > > > Their own fault. Drivers can do any number of stupid things with > > > > interrupts > > > > disabled. > > > > > > Well sure, but that doesn't help. It's part of the API, it's necessary if > > > > Is it necessary or is it part of the API? If the latter, then the API should > > be changed. USB always did an embarrasing amount of work in interrupt > > except for the brave people like Dave who actually use tasklets themselves.
The main place I use tasklets, rather than a work queue, is in "usbnet" as leftover from some 2.4 code that was coping with the fact that neither of the UHCI drivers behaved well when completion handlers did certain things; as in, they oopsed. That could be removed from the 2.6 code, I think, but at this point it's more of a "why bother changing working code". > > The migratory path should be quite clear. > > As far as I know it's not necessary. The API could indeed be changed. > But that's a bigger job than I want to get into just now! And it'd also be worth understanding _why_ it should change. That is, what problem would it address? And why should _that_ invasive change be prioritized over the other choices? > > > completion routines are called with interrupts disabled and they resubmit, > > > and it's why the mem_flags argument had to be added to usb_submit_urb. > > > > It would be needed anyway for the block IO path. > > Agreed. Although as long as we're changing the API, why not arrange > things so that everything is pre-allocated along with the URB and > mem_flags isn't needed at all? It's not clear that can be done, for one thing. Rewriting and re-testing all the HCDs is no small feat ... and those flags would still need to be passed into URB allocation in any case. > > > By the way, I'm a little surprised at all the commotion caused by this > > > proposal to use a tasklet. That wasn't the essence of the "commotion". Using a tasklet for its normal role -- bottom half irq processing -- was noncontroversial, other than the normal pushback one should expect for changes alleged to improve one of several interrelated performance metrics. (All boiling down to "prove it makes things better, not worse.") The "commotion" was wanting change semantics. > > > Plenty of other drivers and subsystems use > > > them. The network code does almost everything in bottom halves, and it > > > doesn't suffer from any shortage of latency requirements. And what about > > > the block layer? Why should USB be any different? > > > > It shouldn't. The completion handler should have been called in a bottom > > half > > from the beginning. That's not entirely clear. Recall that when it _was_ called that way in at least one driver, it didn't much affect performance ... but it did trigger some other problems. > > But you are proposing something unheard of. Nobody has ever used a tasklet > > outside of IRQ handling in a strict sense. The networking code is using > > tasklets only on the recieve path. hard_start_xmit() is called > > conventionally. Not necessarily. It's often called by protocol code to retransmit things. I'd have to look to be sure, but I think that's actually the typical case ... lots of protocol code runs in tasklets, both RX and TX side. > Ah yes. I rather expected you would mention that. > > The difference is that with network drivers the submission and completion > paths are fairly independent. But with USB they are intimately connected > by the need to maintain the hardware schedule. Network drivers maintain hardware schedules too. It's a lot simpler (usually just one RX or TX queue per driver), but that's just a detail. Most network device drivers I've looked at just keep IRQs blocked during the schedule manipulation ... just like all the current HCDs, and in fact most Linux code that mucks directly with hardware. It's the protocol code -- analagous to USB device drivers -- that makes use of tasklets. I think it's very defensible to say that USB device drivers should do minimal work in completion handlers, punting anything significant to a tasklet or other context. That said, I think Alan's got some tricky issues to deal with in UHCI ... it demands sooo many TDs per request. - Dave > Performance issues aside, > I think a single tasklet to handle everything would be the right way to > go. > > Alan Stern > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime info, > new features, or free trial, at: http://www.businessobjects.com/devxi/728 > _______________________________________________ > linux-usb-devel@lists.sourceforge.net > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
