nf_conntrack [was Re: [PATCH 1/4] RFC: fast string matching
infrastrure for netfilter]
rusty at rustcorp.com.au
Fri Jan 14 11:22:45 CET 2005
On Fri, 2005-01-14 at 09:37 +0100, Harald Welte wrote:
> On Fri, Jan 14, 2005 at 06:01:42PM +1100, Rusty Russell wrote:
> > It was IRC, and for IPv6 I agree with Harald that it's probably not the
> > right mechanism. I prefer a simple discriminated union and two slab
> > caches (IPv4 and IPv6), which is hardcoded, but still fairly easy to
> > read.
> so what about the nat_info ? If you load iptable_nat, it will be needed
> for all connections...
My current patches reduce the nat_info to one list_head. If we were to
use a hash tree as per Gandalf's recent work, it'd be 0. IMHO it's not
worth the pain even if it's still a list_head.
> > Does that mean I should *not* send the expectation and NAT patches to
> > DaveM now? (Posted before the ct_extend patches):
> I was wondering all the time why we keep talking about maintainance mode
> for ip_conntrack and the coincidential spike in new development for
That's why I asked. Unfortunately, I only just found time to do some
netfilter work 8(
I definitely think ct_extend should wait for nf_conntrack (but I wanted
the patches out there, since I think they're complimentary). For the
others, I think it's better to merge them now so nf_conntrack only has
to sync once (presumably it will have to sync with some of the existing
changes already), and plan nf_conntrack for 2.6.11.
A bad analogy is like a leaky screwdriver -- Richard Braakman
More information about the netfilter-devel