On Mon, 2010-12-20 at 15:45 +0100, Eric Dumazet wrote: ... > > There is no packet overruns/drops, iif I run "iptables -vnL > > > /dev/null" without tracing enabled and only 1Gbit/s pktgen at 512 > > bytes packets. If I enable tracing while calling iptables I see > > packet drops/overruns. So I guess this is caused by the tracing > > overhead. > > yes, probably :) > > > > > I'll try to rerun my test without all the lock debugging options > > enabled. Results are much better without the kernel debugging options enabled. I took the .config from production and enabled tracer "function_graph". And applied your patches (plus vzalloc) on top of 2.6.36-stable tree. I can now hit the system with a pktgen at 128 bytes, and see no drops/overruns while running iptables. (This packet load at 128bytes is 822 kpps and 840Mbit/s) (iptables ruleset is the big chains: 20929 rules: 81239). If I reduce the ftrace filter to only track get_counters, I can even run a trace without any drops. echo get_counters > /sys/kernel/debug/tracing/set_ftrace_filter Some trace funny stats on get_counters(), under the packet storm. When running iptables on a CPU not processing packets (via taskset), the execution time is increased to 124ms. If I force iptables to run on a CPU processing packets, the execution time is increased to 1308ms, which is large but the expected behavior. Acked-by: Jesper Dangaard Brouer <hawk@xxxxxxx> -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network Kernel Developer Cand. Scient Datalog / MSc.CS Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
