>Actually, it's completely irrelevant.  The second-level processing is
>now done by a soft interrupt that's called ASAP.  There's never an
>additional delay (unless your machine is swamped with interrupts).

Charles,

I was explicltly suggesting an even more light-weight mechanism for
handling the interrupts and getting into the pDMA queue.  That is,
using a "fast" interrupt path for serial interrupts.  Interrupt cost
*is* a problem with FIFOless UARTs. The interrupt-handling code does a
lot of work, and that limits the maximum interrupt rate (and thus
character rate, for FIFOless UARTs) a machine can sustain.  One way to
fix that is to send and receive chars using cheaper interrupts that do
less work -- specifically, that don't either post, or check for, soft
interrupts, but send or receive one char from a pDMA queue, and
*nothing*  else.

My apologies if that wasn't clear.

One issue with doing this is: when and how to handle the received pDMA
data.  If you're already taking clock interrupts at faster than typing
or packet rate, then one way is to poll for received pDMA chars at
each clock interrupt. (The Tx side largely takes care of itself).

The polling adds latency. I was suggesting a simple fix that gets the
benefit of cheaper interrupts *and* avoids the latency: having a
"variable-weight" interrupt, where the work done at the tail of the
interrupt depends on whether the character is "urgent". Characters that
are "urgent" can

	a) post a soft interrupt;
	b) take a higher-weight interrupt-return path that processes
	   pending software interrupts.


>What gives you a performance benefit without FIFOs is just getting the
>bytes off the chip fast enough;

Yes.  I'm suggesting a faster way to do that.

> where they go after that is another
>issue entirely.

I don't entirely agree. if posting the event that gets chars "where
they go after that" is *also* tied to getting them off the chip,
and/or requires more work in the low-level interrupt handler than
would otherwise be desirable, then I dont think it *is* "another issue
entirely."

I have direct experience with 16450s. Using fast-path
interrupts does make a measurable difference to peak throughput,
or to dropping less chars when flow control isn't available.
I really *have* tried both.  Fast-path with receive polling *is* better.

But the extra latency from pDMA polling can be a problem for
interactive use, and the suggested fix *does* fix that, at least for
SLIP and PPP (and STRIP). Human typingis slow enough that it's not a problem.

Putting a fast-path interrupt mechanism back, and actually using it,
may well be outside the scope of the work you're already doing.
That's no reason to claim the possibility of doing so doesn't exist,
or doesn't have performance benefits; or that it doesn't have
potential performance problems.  But the obvious one (latency) is also
solvable,  for protocols commonly used over serial lines.

At least now we can hopefullytalk about the same thing, if this is
worth discussing further.