Re: Linux 2.6.9 pktgen module causes INIT process respawning and sickness

[Lincoln Dale]

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 (bryan@xxxxxxxxxxxxxxxx) 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 . . .
LOL.

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

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.



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/