Messages in this thread | | | Subject | Re: Gigabit Linux Server Bottlenecks | From | Jes Sorensen <> | Date | 08 Feb 2000 12:24:10 +0100 |
| |
>>>>> "Anton" == Anton Ivanov <aivanov@eu.level3.net> writes:
Anton> On 08-Feb-2000 John LeMay wrote: >> Craig, >> >> You have pointed out, very delicately, a major limitation of >> Ethernet as it is implemented today. I find myself constantly >> arguing against implementation of gig Ethernet due to the high CPU >> cost on the host system. Trying to fill a gig pipe with 1,514 byte >> packets is, IMHO, maddening to the CPU. As I recall, the host must >> be able to process around 82,000 packets (read "CPU interrupts") >> per second to fill the
Anton> Wrong. All GigE cards I have checked so far have interrupt Anton> mitigation. At init you program them to delay IRQ until that Anton> many packets are in the queue or a timer expires and the timer Anton> value. The only problem is that these are usually not passed as Anton> module params. So you have to recompile if you find your Anton> current mitigation params bad.
The AceNIC driver takes the coalescing values as module parameters.
>> Since no one seems to want to jump on the 8K jumbo frames >> bandwagon
Anton> See above. If you program a sane GigE NIC correctly you Anton> actually transfer more than 8K at a time. Donald Becker's Anton> hamachi driver is a good example.
This is correct, but it doesn't change the fact that you still need to go through the number of IP and TCP headers, having larger packets reduces the amount of work the host CPU has to do significantly. If you compare the amount of CPU overhead of two media which are almost the smae speed (HIPPI and GigE) you'll find that HIPPI beats the shit out of GigE on this point simply due to the packet size.
Conclusion, yes the Gigabit NIC vendors have tried to do some of the right things to solve the problems the best they could. And no, the best way to talk to the people who did the specification of Gigabit Ethernet is still by using words that are not suited to be put in print.
Second you should yell at your favorite switch vendor regularly for not supporting Jumbo frames. Most of the NIC vendors got the clue and understands why GigE is a problem, however the switch vendors meassure their performance in packet/sec of tiny little 64 byte (or around that size) packets and their fake performance numbers would go down the drain if they suddenly only have a 6th of the buffer space in their switches.
Jes
- 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/
| |