From: Andi Kleen <ak@suse.de>
To: "Jeff V. Merkey" <jmerkey@devicelogics.com>
Cc: ltd@cisco.com, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6.9 pktgen module causes INIT process respawning and sickness
Date: 23 Nov 2004 21:40:41 +0100 [thread overview]
Message-ID: <p73k6sc1epi.fsf@bragg.suse.de> (raw)
In-Reply-To: <41A2862A.2000602@devicelogics.com.suse.lists.linux.kernel>
"Jeff V. Merkey" <jmerkey@devicelogics.com> writes:
> I can sustain full line rate gigabit on two adapters at the tsame time
> with a 12 CLK interpacket gap time and 0 dropped packets at 64
> byte sizes from a Smartbits to Linux provided the adapter ring buffer
> is loaded with static addresses. This demonstrates that it is
> possible to sustain 64 byte packet rates at full line rate with
> current DMA architectures on 400 Mhz buses with Linux.
> (which means it will handle any network loading scenario). The
> bottleneck from my measurements appears to be the
> overhead of serializing writes to the adapter ring buffer IO
> memory. The current drivers also perform interrupt
> coalescing very well with Linux. What's needed is a method for
> submission of ring buffer entries that can be sent in large
> scatter gather listings rather than one at a time. Ring buffers
Batching would also decrease locking overhead on the Linux side (less
spinlocks taken)
We do it already for TCP using TSO for upto 64K packets when
the hardware supports it. There were some ideas some time back
to do it also for routing and other protocols - basically passing
lists of skbs to hard_start_xmit instead of always single ones -
but nobody implemented it so far.
It was one entry in the "ideas to speed up the network stack"
list i posted some time back.
With TSO working fine it doesn't seem to be that pressing.
One problem with the TSO implementation is that TSO only works for a
single connection. If you have hundreds that chatter in small packets
it won't help batching that up. Problem is that batching data from
separate sockets up would need more global lists and add possible SMP
scalability problems from more locks and more shared state. This
is a real concern on Linux now - 512 CPU machines are really unforgiving.
However in practice it doesn't seem to be that big a problem because
it's extremly unlikely that you'll sustain even a gigabit ethernet
with such a multi process load. It has far more non network CPU
overhead than a simple packet generator or pktgen.
So overall I agree with Lincoln that the small packet case is not
that interesting except perhaps for DOS testing.
-Andi
next parent reply other threads:[~2004-11-23 20:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <419E6B44.8050505@devicelogics.com.suse.lists.linux.kernel>
[not found] ` <5.1.0.14.2.20041122144144.04e3d9f0@171.71.163.14.suse.lists.linux.kernel>
[not found] ` <5.1.0.14.2.20041123094109.04003720@171.71.163.14.suse.lists.linux.kernel>
[not found] ` <41A2862A.2000602@devicelogics.com.suse.lists.linux.kernel>
2004-11-23 20:40 ` Andi Kleen [this message]
2004-11-23 21:57 ` Linux 2.6.9 pktgen module causes INIT process respawning and sickness Jeff V. Merkey
2004-11-23 22:27 ` Andi Kleen
2004-11-23 22:54 ` Jeff V. Merkey
2004-11-25 2:17 ` Lincoln Dale
2004-11-22 18:30 Jeff V. Merkey
-- strict thread matches above, loose matches on Subject: below --
2004-11-19 21:53 Jeff V. Merkey
2004-11-19 22:06 ` Jeff V. Merkey
2004-11-22 3:44 ` Lincoln Dale
2004-11-22 17:06 ` Jeff V. Merkey
2004-11-22 22:50 ` Lincoln Dale
2004-11-23 0:36 ` Jeff V. Merkey
2004-11-23 1:06 ` Jeff V. Merkey
2004-11-23 1:25 ` Lincoln Dale
2004-11-23 1:23 ` Lincoln Dale
2004-11-22 17:19 ` Martin Josefsson
2004-11-22 18:33 ` Jeff V. Merkey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p73k6sc1epi.fsf@bragg.suse.de \
--to=ak@suse.de \
--cc=jmerkey@devicelogics.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltd@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox