Re: Linux 2.4.32-rc2

[Roberto Nibali <ratz@drugphish.ch>]

>>CONFIG_ACPI=y
>>CONFIG_ACPI_BOOT=y
>>CONFIG_ACPI_BUS=y
>>CONFIG_ACPI_INTERPRETER=y
>>CONFIG_ACPI_EC=y
>>CONFIG_ACPI_POWER=y
>>CONFIG_ACPI_PCI=y
>>CONFIG_ACPI_MMCONFIG=y
>>CONFIG_ACPI_SLEEP=y
>>CONFIG_ACPI_SYSTEM=y
> 
> But this is purely x86-related, I won't have it on sparc.

Indeed ;).

>>CONFIG_IP_VS=m
>>CONFIG_IP_VS_DEBUG=y
>>CONFIG_IP_VS_TAB_BITS=12
>>CONFIG_IP_VS_RR=m
>>CONFIG_IP_VS_WRR=m
>>CONFIG_IP_VS_LC=m
>>CONFIG_IP_VS_WLC=m
>>CONFIG_IP_VS_LBLC=m
>>CONFIG_IP_VS_LBLCR=m
>>CONFIG_IP_VS_DH=m
>>CONFIG_IP_VS_SH=m
>>CONFIG_IP_VS_SED=m
>>CONFIG_IP_VS_NQ=m
>>CONFIG_IP_VS_HPRIO=m
>>CONFIG_IP_VS_FTP=m
>>
>>One issue is a possible C99'ism in the last IPVS patch. If you find
>>time, please have a 2.95.x compiler installed.
>  
> You mean that it's a build issue ? I first thought that you got erroneous
> behaviour.

Yes, the erroneous stuff I'm tracking down and it looks like I've found
it (actually, Julian Anastasov fixed it):

diff -ur v2.4.32-rc2/linux/net/ipv4/ipvs/ip_vs_core.c
linux/net/ipv4/ipvs/ip_vs_core.c
--- v2.4.32-rc2/linux/net/ipv4/ipvs/ip_vs_core.c	2005-11-03
01:20:02.000000000 +0200
+++ linux/net/ipv4/ipvs/ip_vs_core.c	2005-11-03 01:22:36.347895544 +0200
@@ -1111,11 +1111,10 @@
 		if (sysctl_ip_vs_expire_nodest_conn) {
 			/* try to expire the connection immediately */
 			ip_vs_conn_expire_now(cp);
-		} else {
-			/* don't restart its timer, and silently
-			   drop the packet. */
-			__ip_vs_conn_put(cp);
 		}
+		/* don't restart its timer, and silently
+		   drop the packet. */
+		__ip_vs_conn_put(cp);
 		return NF_DROP;
 	}

I will send a proper signed-off and acked-by patch against rc2 after
some more stress testing. So, please hold off releasing until then. I'm
done testing this piece of code by tomorrow noon (GMT+1).

What I wasn't sure is if the latest patches still compiled on 2.95.x
gcc. That's the only thing I wanted you to test. I cannot ask you to run
fully fledged LVS tests, as this requires quite some setup time.

> How could I stress it ? what ipvs config, what type of traffic ? I'm used
> to stress-test firewalls and load-balancers, but there is a wide choice of
> possibilities, and all cannot be explored in a short timeframe.

You would need to test IPVS on a SMP box using persistent setup and 0
port feature and the expire_nodest_conn proc-fs entry set to 1. Hit the
LB with 100Mbit/s traffic balancing it on 2-3 RS and reload the
configuration using ipvsadm, _but_ without rmmod'ing the ip_vs_* kernel
modules. Set the persistency timeout low (60 secs) and the
timeout_finwait to 10*HZ. You need 2 clients which connect over a Linux
router to a LVS_DR setup, one needs to be router through and the other
should be NAT'd on the Linux router using a NAT pool to simulate 100's
of clients. This way you have the slashdot-hype and the AOL proxy boost
hitting your LB and generating loaded persistency templates which will
then hit the code in question, wenn the internal timer expires. You need
to grep for NONE in ipvsadm -L -n -c to get the template entries. You
must stop the client connecting directly through the Linux router after
you reloaded the LB setup and then you observe the persistent template
created for this client until the timer expires. Then you start it again
and with luck you should see the abberant behaviour of a missed
__ip_vs_conn_put(cp) :). I am pretty sure you do not want to go through
this setup. I have it here and I'm stress testing all possible
combinations of this szenario.

Thanks for your help, Willy.

A bientôt,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/