Messages in this thread | | | Date | Thu, 23 Sep 1999 08:26:37 +0000 | From | Steve Underwood <> | Subject | Re: [Q]: Linux and real device drivers |
| |
Jes Sorensen wrote:
> >>>>> "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/
| |