Re: Linux 2.6.9 pktgen module causes INIT process respawning andsickness
From: Jeff V. Merkey
Date: Mon Nov 22 2004 - 19:35:09 EST
Lincoln Dale wrote:
Jeff,
At 04:06 AM 23/11/2004, Jeff V. Merkey wrote:
I've studied these types of problems for years, and I think it's
possible even for Linux.
so you have the source code --if its such a big deal for you, how
about you contribute the work to make this possible ?
Bryan Sparks says no to open sourcing this code in Linux. Sorry -- I
asked. I am allowed to open source any modifications
to public kernel sources like dev.c since we have an obligation to do
so. I will provide source code enhancements for the kernel
for anyone who purchases our Linux based appliances and asks for the
source code (so says Bryan Sparks). You can issue a purchase
request to Bryan Sparks (bryan@xxxxxxxxxxxxxxxx) if you want any source
code changes for the Linux kernel.
the fact is, large-packet-per-second generation fits into two categories:
(a) script kiddies / haxors who are interested in building DoS tools
(b) folks that spend too much time benchmarking.
for the (b) case, typically the PPS-generation is only part of it.
getting meaningful statistics on reordering (if any) as well as
accurate latency and ideally real-world traffic flows is important.
there are specialized tools out there to do this: Spirent, Ixia,
Agilent et al make them.
There are about four pages of listings of open source tools and scripts
that do this -- we support all of them.
[..]
I see no other way for OS to sustain high packet loading about
500,000 packets per second on Linux
or even come close to dealing with small packets or full 10 gigabite
ethernet without such a model.
10GbE NICs are an entirely different beast from 1GbE.
as you pointed out, with real-world packet sizes today, one can
sustain wire-rate 1GbE today (same holds true for 2Gbps Fibre Channel
also).
i wouldn't call pushing minimum-packet-size @ 1GbE (which is 46
payload, 72 bytes on the wire btw) "real world". and its 1.488M
packets/second.
I agree. I have also noticed that CISCO routers are not even able to
withstand these rates with 64 byte packets without dropping them,
so I agree this is not real world. It is useful testing howevr, to
determine the limits and bottlenecks of where things break.
The bus speeds are actually fine for dealing with this on current
hardware.
its fine when you have meaningful interrupt coalescing going on &
large packets to DMA.
it fails when you have inefficient DMA (small) with the overhead of
setting up & tearing down the DMA and associated arbitration overhead.
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 exhibit
sequential behavior so this method should work well
to support 1Gbe and 10Gbe at full line rate with small packet sizes.
Jeff
cheers,
lincoln.
-
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/