2000-11-05 15:07:44

by Robert Morris

[permalink] [raw]
Subject: gigabit ethernet small-packet performance

I'm building Linux-based routers and need to be able to forward as
many packets per second as possible over gigabit ethernet. It turns
out that choice of network adaptor is critical, but very little
information is available from manufacturers or on the web about
packets-per-second performance of different cards. Here's a web page
summarizing what I've learned, mostly about the Intel Pro/1000
card:

http://www.pdos.lcs.mit.edu/~rtm/e1000/

The short version is that the Intel Pro/1000 seems to be a lot faster
than the Alteon Tigon-II or the SysKonnect card for small (60-byte)
packets. The Intel card can send or receive at least 500,000 60-byte
packets per second (about 1/3 of a gigabit/second). On the other hand,
the Intel Linux driver requires a lot of hacking to achieve that rate;
with the unmodified driver the board is about half that fast.


2000-11-05 18:32:53

by Mr. James W. Laferriere

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance



Hello Robert ,

Quote: You probably want to buy the 66-mHz version instead, model
PWLA8490SX, often called the "Pro/1000 F Server Adapter".

If memory serves me , this adapter has an on board processor with
no way to disable it nor to use it (at present) under linux .
If I am incorrect -please- correct me . Tia, JimL

+----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| [email protected] | DesMoines WA 98198 | only on AXP |
+----------------------------------------------------------------+

2000-11-05 18:45:47

by Gregory Maxwell

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance

On Sun, Nov 05, 2000 at 10:07:20AM -0500, Robert Morris wrote:
> I'm building Linux-based routers and need to be able to forward as
> many packets per second as possible over gigabit ethernet. It turns
[snip]

Hmm.. Kernel code written in C++..
Click is intesting.

You people are nuts. :)

2000-11-05 20:47:21

by bert hubert

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance

On Sun, Nov 05, 2000 at 01:45:18PM -0500, Gregory Maxwell wrote:

> Hmm.. Kernel code written in C++..
> You people are nuts. :)

Nobody benefits from having such a closed mind. While I don't wish to imply
that C++ is 'ready' for general use in the kernel, there is a useful subset
of C++ that might one day be.

See for example http://www.caravan.net/ec2plus/

Oh, and please let us not launch another huge discussion about this subject.
I just want to state that having a closed mind is not going to help us.

Regards,

bert hubert

--
PowerDNS Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

2000-11-05 21:18:18

by Gregory Maxwell

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance

On Sun, Nov 05, 2000 at 10:40:48PM +0100, bert hubert wrote:
> On Sun, Nov 05, 2000 at 01:45:18PM -0500, Gregory Maxwell wrote:
>
> > Hmm.. Kernel code written in C++..
> > You people are nuts. :)
>
> Nobody benefits from having such a closed mind. While I don't wish to imply
> that C++ is 'ready' for general use in the kernel, there is a useful subset
> of C++ that might one day be.

I didn't mean it that way. I though it was interesting in light of the
earlier flame war. Esp considering they appear to be using virtual
functions.

The 'you people are nuts. :)' was meant as a positive statement.
Don't you know? All breakthroughs come from crazy people. :)

> Oh, and please let us not launch another huge discussion about this subject.
> I just want to state that having a closed mind is not going to help us.

Their code speaks for itself. It outperforms the Linux code and is more
flexible.

Although, I tend to see that as a case for additional optimization of the
current Linux code... C++ can be a very useful development tool with the
potential to increase modularity and simplify development. However,
run-time abstraction will always be a performance loss.

I was happy to see the prior flame war end with 'Let the code speak', I only
brought this up here to draw some attention to Click from a C++ in the kernel
prospective, i.e. They are using C++ in the kernel (without extensive kernel

2000-11-07 19:44:34

by Jes Sorensen

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance

>>>>> "Robert" == Robert Morris <[email protected]> writes:

Robert> The short version is that the Intel Pro/1000 seems to be a lot
Robert> faster than the Alteon Tigon-II or the SysKonnect card for
Robert> small (60-byte) packets. The Intel card can send or receive at
Robert> least 500,000 60-byte packets per second (about 1/3 of a
Robert> gigabit/second). On the other hand, the Intel Linux driver
Robert> requires a lot of hacking to achieve that rate; with the
Robert> unmodified driver the board is about half that fast.

I can't comment on the SysKonnect hardware/driver. However as far as
the Alteon card is concerned I know there are issues with latency just
as it has a relatively high overhead for processing DMA descriptors
(as much as 5 micro seconds). The latter is definately going to hurt
you if your part of the pissing contest is about 60 byte packets. For
real data it is not as much of a problem.

Jes

2000-11-08 15:23:46

by Jamie Lokier

[permalink] [raw]
Subject: Re: gigabit ethernet small-packet performance

Robert Morris wrote:
> The short version is that the Intel Pro/1000 seems to be a lot faster
> than the Alteon Tigon-II or the SysKonnect card for small (60-byte)
> packets. The Intel card can send or receive at least 500,000 60-byte
> packets per second (about 1/3 of a gigabit/second). On the other hand,
> the Intel Linux driver requires a lot of hacking to achieve that rate;
> with the unmodified driver the board is about half that fast.

Fwiw, the Alteon Tigon-II can send & receive 60-byte packets at line
rate if you assemble them on the card, but I've not tried pushing that
over the PCI bus. As Jes said, that's the slow part. Special firmware
to use fewer DMAs than packets (i.e. grouping small packets) might do
the trick. The firmware kit is open source; enjoy :-)

-- Jamie