[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.023 / U:4.080 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site