> >>>>> "Steve" == Steve Underwood <steveu@infowebtelecom.com> writes:
>
> Steve> Jes Sorensen wrote:
> Jamie> A card that can be told "don't interrupt me for N us after
> Jamie> receiving the next packet, unless you hit the high water mark"
> Jamie> would be even better.
> >> Thats exactly what some Gigabit Ethernet cards do.
>
> Steve> A number of newer devices do this. It has benefits, but it has
> Steve> a downside too. It imposes significant extra latency when there
> Steve> is just a light load, which can hurt performance on
> Steve> transactional traffic. A better scheme might be more like the
> Steve> 16550 UART. Interrupt if you hit the high tide point, or the
> Steve> wire goes quiet for a short while. Short here can mean very
> Steve> short. This gives more interrupts under light load, when you
> Steve> probably have plenty of spare CPU cycles to deal them. When the
> Steve> load increases the interrupt rate drops. I haven't seen an
> Steve> Ethernet chip which works in that way, but then I haven't
> Steve> studied them all.
>
> Thats exactly the situation Jamie explained, there is no difference.
There is an important difference. Jamie's words say you do this:
wait for a packet
start timer
while (below high tide)
{
wait for a packet, or timer expiration
if (timer expired)
interrupt
if (high tide reached)
interrupt
}
This seems to be how a number of controllers are designed. At least, from
reading some data sheets last year its how they appear to be designed.
You need a fairly long timeout to give high tide a fair chance of being
reached, hence significantly adding latency for low traffic transactions.
The alternative is like this:
wait for a packet
start timer
while (below high tide)
{
wait for a packet, or timer expiration
if (timer expired)
interrupt
if (high tide reached)
interrupt
restart timer
}
A much shorter timer works well with this scheme, as it is restarted
every time something significant happens. Even under flood conditions it
can't keep restarting forever, as you will hit high tide (which is
exactly what you want to do). This can be implemented with a shorter
timer, causing less low traffic latency. Under low traffic conditions you
may get somewhat more interrupts, but under those conditions who cares?
This is exactly what a 16550A UART does. There, the timer is actually 2
characters times of idling on the receive line (assuming all the clones
follow the original NS chip faithfully).
I'm not sure why anyone would implement the first strategy. The second
strategy is just as easy to implement in silicon, but will perform better
in almost every case. The first strategy offers little over using a timed
poll. The second strategy tunes things more closely to the traffic.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/