|
Roberto Nibali wrote:
> [Ben North wrote:]
> > As the original author of the patch, it saddens me to say this, but
> > Vinnie is absolutely correct. I never received a satisfactory answer to
> > why the patch was never incorporated into the main LVS code.
>
> I have posted several reasons for this in the past, some of which I can
> list again here:
Thanks for explaining the reasoning behind your reservations.
> b) If we start using the crappy netfilter state table we end up being
> unnecessary slow for absolutely _no_ added value whatsoever. I have
> shown that it is possible to fill up the conntrack table with bogus
> packets in the current implementation. This is the biggest show
> stopper and I would never accept it to be part of LVS.
> [...]
> I've asked a person in the past if he'd done tests regarding speed and
> conntrack table fill-ups. The person said that they never had planned
> for such a high throughput. I, however, do load balance 50-70 Mbit/s on
> each of the 12-16 interfaces of my load balancer in different zones.
> Ever saw the connection tracking table search crawl with such numbers?
> It's simply not acceptable.
The last time I looked at this was a good while ago, so things might
have got better, but we did notice what you're describing, yes. It was
entirely possible to use up 100% of the CPU. But maybe for a situation
where the expected throughput is lower, it would be acceptable to use up
more CPU to gain (some kind of) stateful firewalling. Julian has
mentioned that he's making progress on updating the patch, so if it can
be brought in as a compile-time option, that would be great. It does
seem that there are people who would use it.
Ben.
|
