[PATCH] ip_ct_refresh_optimization.patch

[PATCH] ip_ct_refresh_optimization.patch

[Marcus Sundberg]

Hi,

The ip_ct_refresh_optimization.patch in p-o-m is completely broken,
as it doesn't handle when the timeout is decreased. This results
in TCP-connections in CLOSE and TIME_WAIT states still having the
5 day timeout they had when they were in ESTABLISHED state.

This patch always updates the timeout if the difference is >= HZ.

diff -u -r1.1 ip_ct_refresh_optimization.patch
--- patch-o-matic/optimizations/ip_ct_refresh_optimization.patch	11 Jun 2002 08:02:57 -0000	1.1
+++ patch-o-matic/optimizations/ip_ct_refresh_optimization.patch	12 Sep 2002 08:11:52 -0000
@@ -69,7 +69,7 @@
 +		/* Don't update timer for each packet, only if it's been >HZ
 +		 * ticks since last update.
 +		 * Need del_timer for race avoidance (may already be dying). */
-+		if (time_after(jiffies, ct->timeout.expires - extra_jiffies + HZ) && del_timer(&ct->timeout)) {
++		if (abs(jiffies + extra_jiffies - ct->timeout.expires) >= HZ && del_timer(&ct->timeout)) {
  			ct->timeout.expires = jiffies + extra_jiffies;
  			add_timer(&ct->timeout);
  		}

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

Re: [PATCH] ip_ct_refresh_optimization.patch

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Thu, 2002-09-12 at 10:41, Marcus Sundberg wrote:
> Hi,
> 
> The ip_ct_refresh_optimization.patch in p-o-m is completely broken,
> as it doesn't handle when the timeout is decreased. This results
> in TCP-connections in CLOSE and TIME_WAIT states still having the
> 5 day timeout they had when they were in ESTABLISHED state.
> 
> This patch always updates the timeout if the difference is >= HZ.
> 
> diff -u -r1.1 ip_ct_refresh_optimization.patch
> --- patch-o-matic/optimizations/ip_ct_refresh_optimization.patch	11 Jun 2002 08:02:57 -0000	1.1
> +++ patch-o-matic/optimizations/ip_ct_refresh_optimization.patch	12 Sep 2002 08:11:52 -0000
> @@ -69,7 +69,7 @@
>  +		/* Don't update timer for each packet, only if it's been >HZ
>  +		 * ticks since last update.
>  +		 * Need del_timer for race avoidance (may already be dying). */
> -+		if (time_after(jiffies, ct->timeout.expires - extra_jiffies + HZ) && del_timer(&ct->timeout)) {
> ++		if (abs(jiffies + extra_jiffies - ct->timeout.expires) >= HZ && del_timer(&ct->timeout)) {
>   			ct->timeout.expires = jiffies + extra_jiffies;
>   			add_timer(&ct->timeout);
>   		}

Yes I know it's broken, I do have a newer version but I havn't committed
it to cvs. I think Patrick Shaaf's solution is a better one and we
should probably go with something like that.

you can find a few optimisation and other patches over at
http://www.netfilter.org/~gandalf/

timer-update2-inc.diff is almost like your patch. I'm using it right now
and it seems to be working fine.

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] ip_ct_refresh_optimization.patch

[Marcus Sundberg]

Martin Josefsson <gandalf@wlug.westbo.se> writes:

> Yes I know it's broken, I do have a newer version but I havn't committed
> it to cvs. I think Patrick Shaaf's solution is a better one and we
> should probably go with something like that.

Probably yes, but that's no reason to have a completely broken patch
which can be fixed by a one-liner in CVS. It should IMHO either be
fixed or removed asap.

> you can find a few optimisation and other patches over at
> http://www.netfilter.org/~gandalf/
> 
> timer-update2-inc.diff is almost like your patch. I'm using it right now
> and it seems to be working fine.

That patch is also incorrect, but it works because it updates to
often, not to seldom. If the new timeout is one jiffie earlier than
the previous timeout your expression will evaluate to 0xffffffff
and thus update the timer even though there's no need. The cast
is useless btw, because all operands, and thus the result also, are
already unsigned long.

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

Re: [PATCH] ip_ct_refresh_optimization.patch

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Sat, 2002-09-14 at 14:52, Marcus Sundberg wrote:
> Martin Josefsson <gandalf@wlug.westbo.se> writes:
> 
> > Yes I know it's broken, I do have a newer version but I havn't committed
> > it to cvs. I think Patrick Shaaf's solution is a better one and we
> > should probably go with something like that.
> 
> Probably yes, but that's no reason to have a completely broken patch
> which can be fixed by a one-liner in CVS. It should IMHO either be
> fixed or removed asap.

I agree, honestly I had almost forgotten that these patches were in cvs
until I read your mail :)
I've committed your patch now. Thanks.

> That patch is also incorrect, but it works because it updates to
> often, not to seldom. If the new timeout is one jiffie earlier than
> the previous timeout your expression will evaluate to 0xffffffff
> and thus update the timer even though there's no need. The cast
> is useless btw, because all operands, and thus the result also, are
> already unsigned long.

I know it will update too often. And about the "bogus" cast, I usually
like explicit casts like that when I think it helps codereadabilty.

As a fun thing you can add a printk() in ip_ct_refesh() and compare the
results without this timer-optimization and with it. I did that when I
first looked at this, it was quite horrible to see a timer get deleted
and a new added with the exact same timeout over and over again.

Have you performed any benchmarks/profiles with and without this
optimization?

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]