My version - Re: Still working on a performance patch for conntrack, need some inp ut

[Daniel Stone]

Rusty,
Righty-ho. I'm still working on ip_conntrack_irc, it's not quite complete,
but I should bump out versions for 0.1.18 (which I use on my box most of
the time) and 0.90.2 sometime in the next week. In the meantime, here's
the patches you suggested to the includes - I added the in_range and the
ip_ct_manip_proto functions. I've attached patches for 0.1.18 and 0.90.2.

Enjoy!
=) d

On Sun, 27 Feb 2000, Rusty Russell wrote:

> In message <200002230803.CAA07578@ductape.net> you write:
> > Rusty, I need your input on this one. On IRC, multiple ports are used, the mo
> st 
> > general ones being 6660-7010. The ip_conntrack_helper structure only provides
>  
> > for monitoring one __constant_htons() port. How would I go about doing this 
> > without having 21 structs? I mean, I can do it with 21 if necessary, just it 
> > would get bloody messy.
> 
> Hmmm... good question.  It could also get pretty slow (running through
> the linked-list for every new connection).
> 
> You can make it a module parameter (range) and do each one for now.
> 
> Otherwise, turn it into a range (protocol_min, protocol_max).  There's
> a reason I never did this...
> 
> There's no generic way to have a protocol tell you whether it's within
> a range or not (we never needed it), so you need to move the
> `in_range' function from ip_nat_protocol.h to ip_conntrack_protocol.h.
> This needs enum ip_nat_manip_type, so move that as well, and rename it
> to:
> 
> 	enum ip_ct_manipproto_type
> 	{
> 		IP_CT_SOURCE,
> 		IP_CT_DESTINATION
> 	};
> 
> That's 11 points.  The irc stuff gets you 15 points (7, doubled for
> 0.90, plus 1 for good form), meaning you'd be well on top of the
> scoreboard 8)
> 
> Rusty.
> --
> Hacking time.
>