On 10/7/06, David Brownell <[EMAIL PROTECTED]> wrote: > "Right now" == what's in 2.6.19-rc1, and that's like the jigsaw. > > > > The optimal situation is tetris with entirely square blocks. > > I'm not sure I'd agree; certainly I chose my analogy carefully too.
OK, so it's the time-pronouns we're being sloppy with... > Admittedly I wasn't aiming to capture the dynamic aspects of > bandwidth allocation, but just the reality that once you have a > schedule budgeted for all periodic endpoints, there's nothing to > keep you from taking those endpoints out and putting them back > any number of times without re-budgeting. Sure. The new budgeter, as I submitted it is currently both flexible and temporarily underpowered. It can't put things right back mainly because QH ordering involves some nasty constraints 1.6.19-rc1 ignores and I was hellbent on getting that right first. Putting the jigsaw piece back is not difficult... unless we lose more than one piece. > EHCI can't really do "square tetris". It's not a video game. ;) Very funny :-) What I meant was that the USB docs make it very clear (in examples and whitepapers, less so in the formal spec) that drivers are expected to rebuild schedules from scratch with every endpoint subtraction (or lazily at at addition time) such that all holes are compressed out of the schedule at every step. I've not yet read source for a driver that actually does this, but every presentation example I've seen from a USB committee member illustrates it that way. So, someone's drivers somewhere are doing it 'the right way'. Also, QHs will often need to be stuck into a slot that is already full, pushing other QHs out into earlier slots. I've also not seen any other drivers do that (they just say no bandwidth). It's needed for the case where, eg, uFrame 5 is full of QHs, there's a QH in uFrame 4, but a new FS QH *must* go into uFrame 5 because of its level in the intr tree (the complete splits must be processed in order of the original ssplits when the transactions overlap! So you end up constrained to scheduling the QHs into uFrames in the same order the QHs appear in the tree despite the apparently superflexible scheduling mechanisms). So... like square tetris with a little 'Dig Dug' thrown in. And alot less Q*bert. > How long it takes is orthogonal. So long as the "reactivate" can see > the old schedule position, and verify it, that's sufficient to make > sure the jigsaw puzzle goes back together in the same way. Not in the rebalancing case, because the old slot would be gone. Or if we're scheduling anew and need to move QH, the slot was previously not there. Because we need to *move* slots in rebalancing, there will be a time when the budget and schedule disagree. We can't just hold a spinlock the whole time, and we can't just blindly schedule on obsolete (or not-yet-valid) information. I'm not worried about timing in the jigsaw puzzle case if we stop at the jigsaw puzzle and don't do anything more aggressive. I'm only woried about active rebalancing. Monty ------------------------------------------------------------------------- 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
