From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Alan Stern <stern@rowland.harvard.edu>,
Bodo Eggert <7eggert@gmx.de>, Lee Revell <rlrevell@joe-job.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [linux-usb-devel] Re: [PATCH] USB_BANDWIDTH documentation change
Date: Tue, 27 Dec 2005 08:57:34 -0800 [thread overview]
Message-ID: <200512270857.35505.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0512261731001.10595-100000@netrider.rowland.org>
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.
next prev parent reply other threads:[~2005-12-27 17:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-26 10:25 [PATCH] USB_BANDWIDTH documentation change Bodo Eggert
2005-12-26 15:06 ` Lee Revell
2005-12-26 21:49 ` Bodo Eggert
2005-12-26 22:35 ` Alan Stern
2005-12-27 4:17 ` Greg KH
2005-12-27 17:02 ` [linux-usb-devel] " David Brownell
2005-12-27 16:57 ` David Brownell [this message]
2005-12-29 19:41 ` EHCI TT bandwidth (was Re: [PATCH] USB_BANDWIDTH documentation change) Dan Streetman
2005-12-29 20:05 ` Lee Revell
2005-12-30 19:13 ` [linux-usb-devel] " Dan Streetman
2005-12-30 19:16 ` Lee Revell
2005-12-29 20:12 ` David Brownell
2005-12-30 0:56 ` Dan Streetman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200512270857.35505.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=7eggert@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=rlrevell@joe-job.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.