All of lore.kernel.org
 help / color / mirror / Atom feed
* ctnetlink delete conntrack performance
@ 2005-03-07 11:25 Marcus Sundberg
  2005-03-07 13:13 ` Patrick McHardy
  0 siblings, 1 reply; 5+ messages in thread
From: Marcus Sundberg @ 2005-03-07 11:25 UTC (permalink / raw)
  To: netfilter-devel

Hi,

When the CTNL_MSG_DELCONNTRACK function of the ctnetlink patch is
used it calls ip_ct_selective_cleanup() to remove the conntrack.

This is highly ineffective (depending on how many hash buckets you
have ofcourse - I had 131007 of them when performing the test :-)

Is there any reason I'm missing (except that maybe the code should
go into it's own function) for not simply doing it this way:

--- nfnetlink_conntrack.c	2005/03/05 21:17:43	1.1
+++ nfnetlink_conntrack.c	2005/03/06 21:49:34
@@ -366,9 +366,11 @@
  		DUMP_TUPLE(tuple);
  		return -ENOENT;
  	}
-
-	ct_debug(0, "calling selective_cleanup\n");
-	ip_ct_selective_cleanup(ctnetlink_kill, h->ctrack);
+	
+	ct_debug(0, "deleting conntrack\n");
+	ip_conntrack_put(h->ctrack);
+	if (del_timer(&h->ctrack->timeout))
+		ip_ct_death_by_timeout((unsigned long)h->ctrack);

  	return 0;
  }

//Marcus
-- 
---------------------------------------+--------------------------
   Marcus Sundberg <marcus@ingate.com>  | Firewalls with SIP & NAT
  Software Developer, Ingate Systems AB |  http://www.ingate.com/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ctnetlink delete conntrack performance
  2005-03-07 11:25 ctnetlink delete conntrack performance Marcus Sundberg
@ 2005-03-07 13:13 ` Patrick McHardy
  2005-03-15 18:29   ` Marcus Sundberg
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick McHardy @ 2005-03-07 13:13 UTC (permalink / raw)
  To: Marcus Sundberg; +Cc: netfilter-devel

Marcus Sundberg wrote:
> When the CTNL_MSG_DELCONNTRACK function of the ctnetlink patch is
> used it calls ip_ct_selective_cleanup() to remove the conntrack.
> 
> This is highly ineffective (depending on how many hash buckets you
> have ofcourse - I had 131007 of them when performing the test :-)
> 
> Is there any reason I'm missing (except that maybe the code should
> go into it's own function) for not simply doing it this way:

You can't drop the reference before calling the timeout function.
BTW: There is no ip_ct_death_by_timeout() AFAICT. Can you send a
new patch ?

Regards
Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ctnetlink delete conntrack performance
  2005-03-07 13:13 ` Patrick McHardy
@ 2005-03-15 18:29   ` Marcus Sundberg
  2005-03-15 18:57     ` Patrick McHardy
  0 siblings, 1 reply; 5+ messages in thread
From: Marcus Sundberg @ 2005-03-15 18:29 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel

Patrick McHardy wrote:
> Marcus Sundberg wrote:
> 
>> When the CTNL_MSG_DELCONNTRACK function of the ctnetlink patch is
>> used it calls ip_ct_selective_cleanup() to remove the conntrack.
>>
>> This is highly ineffective (depending on how many hash buckets you
>> have ofcourse - I had 131007 of them when performing the test :-)
>>
>> Is there any reason I'm missing (except that maybe the code should
>> go into it's own function) for not simply doing it this way:
> 
> 
> You can't drop the reference before calling the timeout function.

Makes sense ofcourse, so just reversing the calls should be fine?

> BTW: There is no ip_ct_death_by_timeout() AFAICT. Can you send a
> new patch ?

Sure, what is the prefered form? There are currently two versions of the
original patch in netfilter SVN: netfilter-ha/patches/nfnetlink-ctnetlink.patch
and patch-o-matic-ng/nfnetlink-ctnetlink-0.13. Do you prefer a patch against
any of the patches, a patch replacing any of them, or a patch against the
patched code? :-)

Also, is there anyone else working on ctnetlink currently, or planning
to work on it? Is the goal to get it into the standard kernel, and if
so what must be done before that?

//Marcus
-- 
---------------------------------------+--------------------------
   Marcus Sundberg <marcus@ingate.com>  | Firewalls with SIP & NAT
  Software Developer, Ingate Systems AB |  http://www.ingate.com/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ctnetlink delete conntrack performance
  2005-03-15 18:29   ` Marcus Sundberg
@ 2005-03-15 18:57     ` Patrick McHardy
  2005-03-15 22:47       ` Pablo Neira
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick McHardy @ 2005-03-15 18:57 UTC (permalink / raw)
  To: Marcus Sundberg; +Cc: netfilter-devel, KOVACS Krisztian

Marcus Sundberg wrote:
> Patrick McHardy wrote:
>>
>> You can't drop the reference before calling the timeout function.
> 
> Makes sense ofcourse, so just reversing the calls should be fine?

Yes.

>> BTW: There is no ip_ct_death_by_timeout() AFAICT. Can you send a
>> new patch ?
> 
> Sure, what is the prefered form? There are currently two versions of the
> original patch in netfilter SVN: 
> netfilter-ha/patches/nfnetlink-ctnetlink.patch
> and patch-o-matic-ng/nfnetlink-ctnetlink-0.13. Do you prefer a patch 
> against
> any of the patches, a patch replacing any of them, or a patch against the
> patched code? :-)

I prefer a patch against patch-o-matic, changing just this part.
Not sure if it is also needed for the netfilter-ha patch, Krisztian ?

> Also, is there anyone else working on ctnetlink currently, or planning
> to work on it? Is the goal to get it into the standard kernel, and if
> so what must be done before that?

No, we won't try to get it into the kernel. If someone ports it over
to nf_conntrack we will think about it.

Regards
Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ctnetlink delete conntrack performance
  2005-03-15 18:57     ` Patrick McHardy
@ 2005-03-15 22:47       ` Pablo Neira
  0 siblings, 0 replies; 5+ messages in thread
From: Pablo Neira @ 2005-03-15 22:47 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, Marcus Sundberg, KOVACS Krisztian

Patrick McHardy wrote:
>> Also, is there anyone else working on ctnetlink currently, or planning
>> to work on it? Is the goal to get it into the standard kernel, and if
>> so what must be done before that?
> 
> 
> No, we won't try to get it into the kernel. If someone ports it over
> to nf_conntrack we will think about it.

I'm working on porting it to 2.6 following Patrick advices. Now I got 
working fine table dumping. My efforts are currently based on 
ip_conntrack and the conntrack-event-API patch but just to make the 
transition to nf_conntrack easier. I'll be on holidays in one week so 
hope to finish with this soon.

Marcus, could you send me your modification? I'll merge it to my port.

--
Pablo

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-03-15 22:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-07 11:25 ctnetlink delete conntrack performance Marcus Sundberg
2005-03-07 13:13 ` Patrick McHardy
2005-03-15 18:29   ` Marcus Sundberg
2005-03-15 18:57     ` Patrick McHardy
2005-03-15 22:47       ` Pablo Neira

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.