> >     Also, I'd like
> > to see this reduce the IRQ rate more than it does.
>
> Why does this reduce the IRQ rate at all?  Doesn't an IRQ fire at every URB
> completion in the queued chain?

With EHCI (plus patch I've not yet posted, more testing yet :)
this more than halves the IRQ rate on larger transfers.  I suspect
that with OHCI or UHCI (much slower) it won't have much of
an effect as-is.

As to why it does so, remember that a given IRQ may indicate
completion of any number of transfers.  IRQs don't fire at the
very instant transfers complete, they wait till some upcoming
microframe (or frame) boundary.  And the hardware doesn't
even know about URBs.  (In the case of EHCI, there's even the
option to say which transfers should generate an interrupt on
completion.)

Scenario (won't happen this fast with the NEC EHCI):

    uframe N
        - queue a bunch of 4KByte transfers, 8 packets each
        - some packets get out in that uframe

    uframe N + 1
        - first transfer finishes, interrupt scheduled for N+3
        - second transfer executes entirely
        - third transfer starts

    uframe N + 2
        - third transfer finishes
        - fourth transfer executes
        - fifth transfer starts
    
    uframe N + 3 ... triggers IRQ>
        - ... etc

And depending on when the driver tasklet scans the schedules,
it may also detect completed transfers that haven't yet triggered
an interrupt... :)

With EHCI the latency is tunable so interrupts can happen after
2^N (0<=N<=6) uframe delays.  The current driver defaults to lowest
latency, but that's settable as a module parameter and the default
can of course be changed.

I seem to recall OHCI also has some tunability in that respect
(maybe that's wrong), but don't know about UHCI.

What I want to do is have a robust way to tell EHCI not to interrupt
for most of the queued transfers. It's not as simple as I'd hoped, since
there's a common case where the HC has cached some transfer
data that the queue append must update.  If it's done that, it needs
to be corrected asynchronously.  (Interrupt or timer.)

- Dave



_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to