On Mon, May 21, 2001 at 06:24:11PM -0700, David Brownell wrote:
> I can see why multi-buffering might be useful to handle scheduling overruns
> in controlled-bandwidth i/o (periodic transfers otherwise require real-time
> scheduling) but that reasoning doesn't apply to bulk or control transfers.
Well, where I sit, there is a large gain from multi-buffering for bulk
transfers.
The issue people see is that it takes a long time (relatively) to go from
one scatter-gather segment to the next. As USB 2.0 deploys, the amount of
bandwidth wasted from this increases dramatically.
This is why I would like to be able to, at least, submit multiple bulk
URBs. Heck, I'd also like to put the status transfer on the end of that
chain, so the CPU doesn't have to pay so much attention to the whole
affair. I could also build chains of frequently used sequences to send on
demand, without lots of processing (yes, this does happen -- see the CB
transport mechanism). Note that I have indications that both Apple and M$
are moving in this direction with their storage driver.
It also seems silly to me to limit the ->next system to only ISO URBs. The
functionality is useful for a variety of applications.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
PGP signature
