> I've done extensive testing in this field trying to achive fast packet
> filtering with a huge set of not ordered rules loaded into the kernel.
>
> According to my findings I had reason to believe that after around 1000
> rules for ipchains and around 4800 rules for iptables the L2 cache was
> the limiting factor (of course given the slowish iptables/conntrack
> table lookup).
>
> Those are rule thresholds I achieved with a PIII Tualatin and 512KB L2
> cache. With a sluggish Celeron with I think 128KB L2 cache I achieved
> about 1/8 of the above treshold. That's why I thought the L2 cache plays
> a bigger role in this than the CPU FSB clock.
>
> I concluded that if the ruleset to be matched would exceed the treshold
> of what can be loaded into the L2 cache we see cache trashing and that's
> why performance goes right to hell. I wanted to test this using oprofile
> but haven't found the correct cpu performance counter yet :).
>
> > Also not necessary, only the top level cache really needs to be
> > top performance.
>
> I will do a new round of testing this weekend for a speech I'll be
> giving. This time I will include ipchains, iptables (of course I am
> willing to apply every interesting patch regarding hash table
> optimisation and whatnot you want me to test), nf-hipac, the OpenBSD pf
> and of course the work done by Jamal.
Look forward to any info you can provide.
I particularly like that nf-hipac can be put in and tried in one-to-one
comparison, that leaves an easy route to testing and getting confidence in
the code.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/