On Monday 26 December 2005 2:35 pm, Alan Stern wrote:
s.
>
> CONFIG_USB_BANDWIDTH isn't _really_ needed.
I think it was there historically because the first implementations
didn't work correctly. In fact, the model underlying that current
usb_check_bandwidth() call is incorrect ... reservations for periodic
bandwidth (isochronous and interrupt transfers) are per-endpoint,
not per-urb.
> What it does (or rather, what
> it would do if it worked properly) is prevent the kernel from
> overcommitting on USB bandwidth.
It's also completly ignored for
- ohci-hcd, which never overcommits;
- sl811-hcd, works just like ohci in that respect;
- isp116x-hcd, ditto;
- ehci-hcd, can't risk overcommit with transaction translators(*);
The only HCDs that use usb_check_bandwidth() are the CRIS HCD
(which, last I heard, neither built nor, after fixing build errors,
worked) and UHCI. Which is why this patch is incorrect ...
The long term solution is to get rid of that CONFIG_ symbol and
the code backing it, and then have all the HCD properly reserve
periodic bandwidth, using a per-endpoint approach.
- Dave
(*) The issues folk have mentioned with bandwidth reservation for
EHCI are more "full and low speed devcies can't use all the
available transaction translator bandwidth" than anything else.
As a rule high speed devices don't see such issues ... only the
needing more complex scheduling models than usb_check_bandwidth
supports, just to work -- in even simple scenarios. Which is why
EHCI never has/will use the code now protected by USB_BANDWIDTH.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
