On Wednesday 05 July 2006 6:14 pm, Christopher Montgomery wrote:
>
> > And as a simplification: to date there's been only one data
> > structure, which encodes both the schedule and all allocations.
> > This is a Good Thing (tm) because it's less error prone ... and
> > it's also a useful simplification.
>
> ? There are QHs, iso streams, sits, itds and fstns in the hardware
> schedule, and a rolled up pointer union [shadow schedule] that points
> to the same physical thing that may be one of many types... that may
> be one data structure, but it's certainly not one type and traversing
> it is not simple.
Blame it on the hardware design, if you want; C doesn't address
hardware pointer types, but the EHCI controller hardware does encode
type in otherwise-unused pointer bits. That is, there isn't any
choice about those parts of the data structure ... the C union in
the "shadow" view of the tree (different roots, same contents) is
the virtual address version of the hardware dma "next" pointer.
Attempting to have a different data structure would have made it
a lot easier to create bugs where the HCD view (virtual addresses
and C data structures) was incompatible with the controller view
(dma addresses with embedded typing information).
> Ive implemented a parallel 'shadow budget' in response to your concern
> that true periodic scheduling in the 1024 frame hardware schedule
> would use too much kernel memory (I don't mean to sound contrary
> there, I agree with you else I'd not have done it this way). The
> shadow budget is #defineable, currently 32 frames, and consists of
> only budgeting information (which is now moved out of the private
> sections of the hardware schedule structures).
I'll be interested to see the details there. Various ideas have
been circulated about how to do fancier scheduling over a narrower
scope, like the 32 frames used by OHCI. It's mostly hubs that use
longer periods. I figured none of those ideas were worth looking
at until the schedule tree had a decent representation of both types
of ISO stream (e.g. stick a fake "ISO QH" in the shadow tree), and
that there wasn't a clear need to shrink the scheduling horizon.
Of course, OHCI has real "ISO QH" data structures, which makes it
really easy and efficient to schedule ISO ... it's actually not
in the least bit different from interrupt scheduling. EHCI has a
few hardware-imposed differences, but most of the rest _could_ be
shared. (Although there would be nasty TT-related special cases
to handle through FSTN or other backlinks.)
> > Only ISO endpoints ever had a sliding window... and I'm not sure what
> > you mean about this being a new layer, considering that the scheduling
> > decisions are already separated from the actual data structure updates.
>
> New data layer, not a new logic layer.
I hope that by "layer" you mean more like an auxiliary data structure
used only when certain operations are needed ... not a "layer" of code
that must be traversed for each urb enqueue/dequeue operation!
> Because the decision data is a
> fundamentally different thing than the schedule entries themselves, I
> implemented a seperated layer to handle and store it. It is also less
> expensive to inspect than the full schedule and there's no need for
> continuous type-punning using unions. Decision data for a given
> endpoint is 'owned' by either a specific QH or a specific ISO stream.
There's a one-to-one association between endpoint and (QH-or-ISOstream),
of course ... seen by usbcore as a usb_host_endpoint. Active endpoints
also have a one-to-one assocation to some schedule entry ("active" means
"scheduled").
For interrupt transfers, the QH is easy; it just sits in the schedule
tree. The problem has always been that there's no QH for ISO, hence
only an incomplete representation of the ISO
> ISO streams are no longer freed and rebuilt between each transfer
> (that they were before was accidental?), but that's a straight-up
> bugfix the new layer needs, not a feature of the new layer.
ISO streams weren't fully implemented before, and one of the main goals
was just keeping (s)ITD allocation costs pretty much at zero for normal
steady state "queue always full" usage. There seemed to be no point in
keeping inactive ISO streams around, except to cost memory ... and on
the contrary, starting a new stream is the natural moment to incur any
such allocation costs (along with the budgeting costs).
That change would not be a bug fix.
> > > budgeting is done for the lifetime of an endpoint's activity).
> >
> > I'm not clear what you mean here either. An endpoint is active if
> > it has URBs queued. By that definition, this is again a description
> > of the current driver behavior. (Modulo the glitches noted for ISO.)
>
> That's a huge problem for the iso streams I've seen where a new
> transfer is not initiated until the old one is finished-- the iso
> stream is fully destroyed and then rebuilt for every transfer.
This is bad ISO-using device driver behavior then. What software
works like that? Fix that driver!!
The way USB drivers should handle ISO stream hasn't changed since
the beginning of the Linux-USB stack: always have at least one URB
queued, and have that URB keep the bus busy for more than the worst
case system IRQ latency. Otherwise, you're all but guaranteed to
have problems maintaining isochrony.
> [the problem and fix here are both simple; now, [s]itd_complete frees
> the ehci_iso_stream when the last urb is complete, but there's usually
> only ever one at a time in audio streams, especially capture streams.
Bad design. All iso streams should have at last two URBs queued, see
above. The only time a single URB should be queued is briefly when
completing the other one (or when shutting the stream down).
> The iso stream should be freed as a result of last urb completion
> followed by ehci_endpoint_disable, not just as a result of last urb
> completion.]
That's a different valid implementation, but in this case it'd
just be covering up for a buggy driver.
> It was easier to debug
> the new budgeter when the new budgeter was fully seperated from the
> scheduling machinery.
Makes sense.
> Rather, this argument should probably happen later, incrementally ;-)
And as part of a series of incremental driver improvements. :)
> > Again, you must be focussing on ISO here, because the problem can't
> > appear for interrupt endpoints. Interrupt transfers sit cleanly in
> > a schedule tree, so those slots can't be invalidated.
>
> Fine, point granted.
Replacing the ISO scheduler -- or providing an alternate "new" one, to
be converted to over time -- sounds like a more focussed goal than what
I've heard you talking about so far, too. Less likely to break the
rest of that relatively hairy code.
> > That is, better ISO budgeting -- e.g. by sticking an dummy "ISO QH"
> > in the schedule tree instead of using the window thing -- would fully
> > resolve this issue.
>
> I suggested that and one point and you complained it would take too
> much memory ;-)
What I recall you suggesting was having ITDs through the whole schedule,
which is a different thing! My suggestion was to do the OHCI-like thing
in software (the shadow schedule's one deviation from the hardware view)
and keep the current model (shared by all HCDs!) that ITDs are put into
the schedule only on-demand.
> > "isochronous budgeting" ... was simplistic, and aimed at typical
> > light duty loads.
>
> I've never seen a isoch endpoint that counts as 'light duty', but I
> understand what you mean.
All USB speakers I've seen. They rarely need even 180 bytes/frame.
Webcams seem to have annoying proprietariness problems.
- Dave
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
