On Friday 30 March 2007 11:33 am, Oliver Neukum wrote:
> Am Freitag, 30. März 2007 19:56 schrieb Greg KH:
> > > The bottom line is, there's no excuse for using any kind of smp_mb()
> > > in USB drivers. None at all. When we have 100Gbit/s USB, then perhaps
> > > we can talk about it.
> >
> > Perhaps then, but even then, I doubt it...
>
> That's not the issue.
Remember that if every completion callback does
status = urb->status;
at the top, the urb->status issue will by definition go away. That's
effectively what Greg's notion of changing the callback signature will
deliver...
The stuff you're chasing is driver-internal races, which are unrelated
to the interface exposed by usbcore.
> The question is not what we USB needs in terms
> of performance. Every time we use a lock we screw anybody caring about
> interrupt latency. The amount of work some drivers do in irq is awful.
> Usbnet is the laudable exception.
It goes to extreme lengths only because of HCD bugs in the 2.4 kernels,
all of which are now fixed. It can now do away with that tasklet for
all cases except the "ran out of buffers/urbs" ones.
The network stack already handles the "do real work in softirq"
logic, there's no real point (any more) in having usbnet do the
same thing ...
- Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
