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 http://vger.kernel.org/majordomo-info.html
