Re: [RFC] ipvs: Keep track of backlog connections

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [RFC] ipvs: Keep track of backlog connections
Cc: Sven Wegener <sven.wegener@xxxxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, Wensong Zhang <wensong@xxxxxxxxxxxx>
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 1 Sep 2010 22:28:35 +0900
On Wed, Sep 01, 2010 at 11:32:39AM +0300, Julian Anastasov wrote:
>       Hello,
> On Tue, 31 Aug 2010, Sven Wegener wrote:
> > Hi all,
> > 
> > this patch has been sitting in my local repository for quite some time 
> > now. The number of backlog connections helps diagnosing realserver related 
> > overload and configuration problems. Is it worth merging? If yes, I'm 
> > going to tidy it up and prepare the userspace portion for ipvsadm.
> > 
> > Sven
> > 
> > 
> > From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
> > Subject: [PATCH] ipvs: Keep track of backlog connections
> > 
> > A backlog connection is a connection that is on its way from inactive to
> > active. Speaking in TCP language, a connection from which we've seen the
> > initial SYN packet, but the three-way handshake hasn't finished yet.
> > These connections are expected to move to active soon. When a
> > destination is overloaded or isn't able to successfully establish
> > connections for various reasons, this count increases quickly and is an
> > indication for a problem.
>       Looks good but should not be applied now because
> we should first put some changes for cp->flags, we are
> reaching the limit of 16 bits for cp->flags. Your
> intention is IP_VS_CONN_F_BACKLOG not to be sync-ed and
> I agree. So, your patch will be applied after other
> changes. I think, Simon will fix it later.

Hi Julian,

thanks for spotting this bits issue.

On the kernel-side of things, internally it should be easy
enough to either expand flags or add a new element to the structure.
So it seems to me that the problem is the kernel/user-space interface.
And if that is the case, I think the best idea is to just use
the netlink interface for all new configuration options and have
new features unsupported through the old, legacy, ioctl interface.

To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>