Re: [linux-usb-devel] Re: [PATCH] USB_BANDWIDTH documentation change

[David Brownell <david-b@pacbell.net>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/