Hi,
> You missed the real trick, extending the routing tables to
> do packet filter rule lookup. That's where the real
> performance gains can be found, ...
Yes, that's certainly true. But we have to take step by step.
We started our project in August 2001 and up to now almost all our work went
into developing and optimizing the algorithm and not into an optimal
integration into the linux kernel. We chose the netfilter integration as a
first step, because it was easy and fast to do. It doesn't break anything in
the kernel, no kernel patch is needed, it can be used together with other
existing netfilter/iptables modules and switching from the iptables filter
module to nf-hipac is really easy.
We have now basically finished the work on the algorithm itself. We can now
concentrate on porting the algorithm to other fields and on a better
integration into the kernel. We designed the algorithm code in a way that
allows to port it to other fields than packetfiltering without much work.
We were aware from the beginning that combining several fields (e.g. routing
and filtering) is THE way to go and it is no problem to support this with our
algorithm.
Our algorithm is already fast with a small number of rules, but what makes it
really interesting is, that it is possible to use huge rulesets/routing
tables/qos ... without much slowing down performance. In practical use people
won't notice much of a difference between using 25 or 25000 rules.
The nf-hipac team
Michael Bellion, Thomas Heinz
-
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/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:24 EST