> Hello,
>
> [Maybe we should discuss this in private, it doesn't have a lot to do
> with kernel development anymore.]
To be honest: I think this _is_ indeed a kernel development issue. We are
somehow talking of a performance lack that can be overcome by a simple patch
(call it hack) and some brain.
> > Because when you have to deal with thousands of session per second, NAT is
> > really a pain in the ass. When you have to consider security, NAT is a pain
>
> Not with a HW LB, and with a SW LB (LVS-NAT) you can very well sustain
> 20000 NAT'd load balanced connections with 5 minutes of stickyness
> (persistency) with 1GB RAM and a PIII Tualatin with 512 kb L2 cache. I'm
> not sure if you meant this when mentioning pain.
I guess he probably meant a _bit_ more. I may add some zeros to your 20000 to
give you a glimpse of a _standard_ load we are talking about. And you can
easily do this with the hardware you mentioned _not_ using NAT (of course ;-).
I guess it would really be a great help if someone did tests like Cons'
"overall performance" ones for network performance explicitly. Like e.g.
performance for various packet-sizes of all available protocol types, possibly
including NAT connections. We have no comparable figures at hand right now, I
guess.
-- Regards, Stephan- 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/