[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.6.9 pktgen module causes INIT process respawning and sickness
At 11:36 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 ( if you want any source
>code changes for the Linux kernel.

LOL. in wonderland again?

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

so you're creating a packet-generation tool?
you mentioned already that you had to increase receive-buffers up to some
large number. doesn't sound like a very useful packet-generation tool if
you're internally having to buffer >60K packets . . .

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

Cisco software-based routers? sure ...
however, if you had an application which required wire-rate minimum-sized
frames, then a software-based router wouldn't really be your platform of

hint: go look at EANTC's testing of GbE and 10GbE L3 switches.

there's public test data of 10GbE with 10,000-line ACLs for both IPv4 &
IPv6-based L3 switching.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:08    [W:0.028 / U:23.408 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site