Hi Roberto,
On Thu, Nov 03, 2005 at 11:19:38AM +0100, Roberto Nibali wrote:
> >>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 ;).
No pb.
> >>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).
OK, fine. I'll merge it into next -hf (probably within a few days). Please
insist loudly if you consider it important to fix quickly because it's a
real regression, as I don't want to have people wait for long if one hotfix
causes trouble.
> 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.
OK, if it was your only concern, then I can say that it compiles and
runs on x86.
> I cannot ask you to run fully fledged LVS tests, as this requires
> quite some setup time.
I know this, that's why I asked about the setup, config files and
test scenario :-)
> > 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.
Of course this is not the easiest setup just to chase a bug down. But with
such an explanation, a good manual on IPVS, and a lot of spare time, it
could be done if it was the only solution. But I'm not willing to spend
so much time on this yet :-)
> Thanks for your help, Willy.
You're welcome.
> A bientôt,
> Roberto Nibali, ratz
Cheers,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]