|
On Mon, Nov 07, 2005 at 05:47:37PM +0900, Horms wrote:
> On Mon, Nov 07, 2005 at 09:24:07AM +0200, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Mon, 7 Nov 2005, Horms wrote:
> >
> > > I'm a bit worried about that too. Although the template has to have
> > > actually timed out for this to occur. In any case, perhaps a patch that
> > > doesn't change the timeout would be better. Something like the
> >
> > The problem is that we invalidate templates breaking sessions,
> > in such case we don't care much when template expires.
> >
> > > following, though I'm not sure why cp->timeout is set at the top
> > > of ip_vs_conn_expire(), it would seem cleaner if it was set below
> > > expire_later. Actually, I'm not really sure why the timeout is altered
> > > at all.
> >
> > Agreed, ip_vs_conn_expire_now() already does not set cp->timeout
> > to 0, so there is no good reason to modify it in ip_vs_conn_expire.
> > May be the code should look in this way:
> >
> > if (cp->flags & IP_VS_CONN_F_TEMPLATE)
> > cp->timeout = 10*HZ;
> >
> > Then the timeout for normal connections will not be modified
> > while templates will change from 360 to 10 if waiting all its normal
> > connections to expire.
>
> That seems like a good work around to me, though perhaps HZ would
> be better than 10*HZ.
>
> Here is a patch to formalise it slightly. This is for 2.6, i'll send a
> version for 2.5 shortly.
2.4 still sets cp->timeout = 0; in ip_vs_conn_expire_now, so this
is probably a good fix.
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index 015c819..eb3c29b 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -1221,10 +1221,10 @@ static void ip_vs_conn_expire(unsigned l
{
struct ip_vs_conn *cp = (struct ip_vs_conn *)data;
- if (cp->timeout_table)
- cp->timeout = cp->timeout_table->timeout[IP_VS_S_TIME_WAIT];
+ if (cp->flags & IP_VS_CONN_F_TEMPLATE)
+ cp->timeout = 10*HZ;
else
- cp->timeout = vs_timeout_table.timeout[IP_VS_S_TIME_WAIT];
+ cp->timeout = 60*HZ;
/*
* hey, I'm using it
|
