IPVS: use proper timeout instead of fixed value

IPVS: use proper timeout instead of fixed value

[Simon Horman]

From: Andy Gospodarek <andy@greyhouse.net>

Instead of using the default timeout of 3 minutes, this uses the timeout
specific to the protocol used for the connection. The 3 minute timeout
seems somewhat arbitrary (though I know it is used other places in the
ipvs code) and when failing over it would be much nicer to use one of
the configured timeout values.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Acked-by: Simon Horman <horms@verge.net.au>

---

Hi,

I'd like to revisit this patch which was originally posted
to netdev in May 2006.

Looking through the archives as far as I can see there was
some discussion as to whether it would be good to send timeout
information in the synchronisation packet, and some discussion
as to whether it would be good to make the timeout configurable
on the slave side, and then the ball was dropped.

It seems to me that regardless of whether or not the syncronisation
protocol should be expanded to include timeout information,
and wheather or not it should be configurable on the slave side,
this patch is a good idea as the default that it provides seems
to be much more sensible than the current arrangement.

Andreas Lundqvist provided me with an example where his
cluser has long often idle connections and that in this case
the short, 3 minute default timeout, really is quite useless.

 ip_vs_sync.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -67,7 +67,6 @@ struct ip_vs_sync_conn_options {
 	struct ip_vs_seq        out_seq;        /* outgoing seq. struct */
 };
 
-#define IP_VS_SYNC_CONN_TIMEOUT (3*60*HZ)
 #define SIMPLE_CONN_SIZE  (sizeof(struct ip_vs_sync_conn))
 #define FULL_CONN_SIZE  \
 (sizeof(struct ip_vs_sync_conn) + sizeof(struct ip_vs_sync_conn_options))
@@ -279,6 +278,7 @@ static void ip_vs_process_message(const 
 	struct ip_vs_sync_conn *s;
 	struct ip_vs_sync_conn_options *opt;
 	struct ip_vs_conn *cp;
+	struct ip_vs_protocol *pp;
 	char *p;
 	int i;
 
@@ -337,7 +337,8 @@ static void ip_vs_process_message(const 
 			p += SIMPLE_CONN_SIZE;
 
 		atomic_set(&cp->in_pkts, sysctl_ip_vs_sync_threshold[0]);
-		cp->timeout = IP_VS_SYNC_CONN_TIMEOUT;
+		pp = ip_vs_proto_get(s->protocol);
+		cp->timeout = pp->timeout_table[cp->state];
 		ip_vs_conn_put(cp);
 
 		if (p > buffer+buflen) {

Re: IPVS: use proper timeout instead of fixed value

[David Miller]

From: Simon Horman <horms@verge.net.au>
Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)

> From: Andy Gospodarek <andy@greyhouse.net>
> 
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
> 
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Simon Horman <horms@verge.net.au>

I would apply this but it does not apply to current 2.6.x,
please resubmit.

Thanks.

Re: IPVS: use proper timeout instead of fixed value

[Simon Horman]

On Mon, Oct 29, 2007 at 01:35:15AM -0700, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)
> 
> > From: Andy Gospodarek <andy@greyhouse.net>
> > 
> > Instead of using the default timeout of 3 minutes, this uses the timeout
> > specific to the protocol used for the connection. The 3 minute timeout
> > seems somewhat arbitrary (though I know it is used other places in the
> > ipvs code) and when failing over it would be much nicer to use one of
> > the configured timeout values.
> > 
> > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > Acked-by: Simon Horman <horms@verge.net.au>
> 
> I would apply this but it does not apply to current 2.6.x,
> please resubmit.

I tried against net-2.6 and it seemed to work.
Was I mistaken or should I be using a different tree?

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Re: IPVS: use proper timeout instead of fixed value

[David Miller]

From: Simon Horman <horms@verge.net.au>
Date: Mon, 29 Oct 2007 17:59:23 +0900

> On Mon, Oct 29, 2007 at 01:35:15AM -0700, David Miller wrote:
> > From: Simon Horman <horms@verge.net.au>
> > Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)
> > 
> > > From: Andy Gospodarek <andy@greyhouse.net>
> > > 
> > > Instead of using the default timeout of 3 minutes, this uses the timeout
> > > specific to the protocol used for the connection. The 3 minute timeout
> > > seems somewhat arbitrary (though I know it is used other places in the
> > > ipvs code) and when failing over it would be much nicer to use one of
> > > the configured timeout values.
> > > 
> > > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > > Acked-by: Simon Horman <horms@verge.net.au>
> > 
> > I would apply this but it does not apply to current 2.6.x,
> > please resubmit.
> 
> I tried against net-2.6 and it seemed to work.
> Was I mistaken or should I be using a different tree?

Nope, that should be good.

Maybe I did something stupid or it got clobbered in transit somehow.

Please resend it privately to me under seperate cover and we'll sort
it out.

Thanks Simon!

Re: IPVS: use proper timeout instead of fixed value

[Andy Gospodarek]

On Mon, Oct 29, 2007 at 04:05:55PM +0900, Simon Horman wrote:
> From: Andy Gospodarek <andy@greyhouse.net>
> 
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
> 
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Simon Horman <horms@verge.net.au>
> 

Thanks for re-visiting this, Simon!  It's too bad that the other work
never got done, but I'm glad to see this will get included.