>Um, avoiding at least one of the copies from mbuf to clist to output
>silo on the way out?

Speaking utterly without numbers: if the copies are done in large
chunks (an mbuf at a time) the effect is going to very small.  Down
there in the noise, on machines with ~70Mbyte/sec write bandwidth.

Getting rid of it would be nice, but it's just not going to have a
large effect on either latency or throughput -- unless you have so
many serial lines that aggregate memory bandwidth becomes an issue.

>And maybe the necessity of copying data out of
>software silos with a character-by-character upcall on the way in?

Yes, this one is going to be a noticeable per-byte cost, because it
forces traversing a chunk of the networking stack for each character,
rather than for each block.

But if you read to the end of my earlier message, you'd notice that I
too think this should be fixed, _and_ suggested an obvious method for
bounding the latency that may be introduced in deferring the upcalls
long enough to accumulate a large chunk of characters.

I've had some experience with other systems that use 100Hz clocks, and
which also defer the upcalls from the serial pdma routine to the next
clock tick. 10ms is a long time for a 115k link; and if other delays
are just right, the additional round-trip latency from 100Hz upcall
polling at each end can be perceptible.  Hence the 'stop list' proposal.