Re: SOMAXCONN too low

["David S. Miller" <davem@redhat.com>]

On Wed, 29 Oct 2003 09:13:44 -0800
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> >>>>> On Wed, 29 Oct 2003 13:33:15 +0100, Andi Kleen <ak@suse.de> said:
> 
>   Andi> Another alternative would be to make it a fraction of the
>   Andi> listen() argument per socket
>   Andi> (e.g. min(tcp_max_syn_backlog,min(128,10%*listenarg))) to
>   Andi> allow the application to easily change it.
> 
> I don't understand what purpose this would serve.  Seems to me it
> would make life only more complicated for apps that know what they're
> doing.

Andi's saying the the max backlog should be a function of
the queue length the user asks for when he makes the listen()
system call.

Also note that we'll need to tweak the TCP listening socket SYNQ hash
table size if we modify these kinds of things.

> At the moment, in-kernel servers are at an unfair advantage over
> user-space servers for this reason.

I totally disagree, the only reason things like TuX perform better
than their userland counterparts and don't run into SOMAXCONN issues
is because it is threaded properly.  This is where all of the "jitter"
stuff you keep talking about really comes from.

When I've asked in the past to see code for userland servers that have
a problem wrt. SOMAXCONN, it's always the case that the userland
server only lets one of it's threads take new connections via
accept().  It's no wonder they have problems....

This is why I'm usually big time against changing this value, if we
change it we may be less likely to discover userland server stupidity
like that I mentioned above.