lkml.org 
[lkml]   [2000]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Gigabit Linux Server Bottlenecks
-----BEGIN PGP SIGNED MESSAGE-----

[snip]

>
>>> 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

Most cards have rudimentary IP stack functions on them as well. At least
PacketEngines and methings Intel should be able to do the checksumming and a
few other rudimentary ops.

These are not implemented in the Linux driver (maybe for better ;-).

> 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.

True. I was simply making a point that the workload to handle GigE is not the
IRQ workload. IRQ workload is handled by design at the hardware level.

>
> 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.

Agreed ;-)

There is still a few things that it makes sense for: 802.1Q being the most
noteable example. Overcoming the machine port number limitations and having more
than 10 Ethernet interfaces does make sense. Any chance for it making
mainstream?

>
> 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.

;-)

- ----------------------------------
Anton R. Ivanov
IP Engineer Level3 Communications
RIPE: ARI2-RIPE E-Mail: Anton Ivanov <aivanov@eu.level3.net>
@*** Les Miserables Metalaw ***
All laws, whether good, bad, or indifferent,
must be obeyed to the letter.

- ----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQEVAwUBOKAFbClWAw/bM84zAQGO2Af9H3VrtyTVh+QEEmrLP8AlwGFO2B0MyuVW
QgH97eX4WH/A5Ulr5Zb9oVKV+woialSxzbTUFLSfj1Kk49SieGnbLBf7kM42BQ4Z
Zp5SLdvUvNRsMoTWKjpPU9TJ7/FVq5wGnprWqUSJJLSMQfrIQiKkhcRJVxT8hruH
EcQbFOLozSttVEGHES0aL0k0atiBcFXzIMrbEsRpJG3aJEJ7vPUnCJxdxhQdN+qp
Xf9b0/bO1j6/0/u6uCl7LCe92XWMKUgCqbkgW/PB7BG9cTQsmSJlNgvQk7EGcvmY
/e5JYm/fD47cQbm2quen0Hus1HlClj8eTO/YxpvDPJ2dCcF1GZAOtQ==
=M3Cz
-----END PGP SIGNATURE-----

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.079 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site