Messages in this thread | | | From | Jes.Sorensen@cern ... | Date | Thu, 10 Feb 2000 12:55:15 +0100 |
| |
>>>>> "Ingo" == Ingo Molnar <mingo@chiara.csoma.elte.hu> writes:
Ingo> On Tue, 8 Feb 2000, Anton Ivanov wrote:
>> Wrong. All GigE cards I have checked so far have interrupt >> mitigation. At init you program them to delay IRQ until that many >> packets are in the queue or a timer expires and the timer >> value. The only problem is that these are usually not passed as >> module params. So you have to recompile if you find your current >> mitigation params bad.
Ingo> yep, also with jumbo frames (mtu 9000) there is no problem at Ingo> all. Eg. the SysKonnect cards i use do just over 20k IRQs/sec Ingo> when i'm saturating 107MB/sec TCP bandwith - this IRQ load is Ingo> simply not a problem at all for an APIC controller. I've seen Ingo> IRQ rates of 80k/sec as well.
Sorry but thats *BAD* performance by the SK card. I do around 2.5K ints/sec with the Alteon when doing 65MB/sec traffic in one direction with regular sized frames. The load is maybe not a problem for the APIC, but 80k/sec truly sucks for the CPUs considering the number of context saves/restores they have to do.
>> See above. If you program a sane GigE NIC correctly you actually >> transfer more than 8K at a time. Donald Becker's hamachi driver is >> a good example.
Ingo> also other cards are using jumbo frames as well (and it actually Ingo> makes sense to increase packet size).
It's the switch vendors who are causing the problems.
Jes - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
- 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/
| |