Messages in this thread | | | Date | Thu, 26 Sep 2002 14:04:30 +0200 | From | Andi Kleen <> | Subject | Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification |
| |
On Thu, Sep 26, 2002 at 11:00:53AM +0200, Roberto Nibali wrote: > o we can't filter more than 13Mbit/s anymore after loading around 3000 > rules into the kernel (problem is gone with nf-hipac for example).
For iptables/ipchain you need to write hierarchical/port range rules in this case and try to terminate searchs early.
But yes, we also found that the L2 cache is limiting here (ip_conntrack has the same problem)
> o we can't log all the messages we would like to because the user space > log daemon (syslog-ng in our case, but we've tried others too) doesn't > get enough CPU time anymore to read the buffer before it will be over- > written by the printk's again. This leads to an almost proportial to > N^2 log entry loss with increasing number of rules that do not match. > This is the worst thing that can happen to you working in the > security business: not having an appropriate log trace during a > possible incident.
At least that is easily fixed. Just increase the LOG_BUF_LEN parameter in kernel/printk.c
Alternatively don't use slow printk, but nfnetlink to report bad packets and print from user space. That should scale much better.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |