Re: [PATCH] socket: increase default maximum listen queue length

[Eric Dumazet <eric.dumazet@gmail.com>]

Le dimanche 20 mars 2011 à 12:39 +0100, Hagen Paul Pfeifer a écrit :
> * Eric Dumazet | 2011-03-20 09:30:17 [+0100]:
> 
> >Hmm, real problem is not the 'maximum queue value', but the minimum one.
> >
> >If application says : listen(fd, 10), you are stuck.
> >
> >128 or 256 is way too small on some servers, where admin can tune
> >in /etc/sysctl.conf :
> >
> >net.core.somaxconn = 8192
> >net.ipv4.tcp_max_syn_backlog = 8192
> >
> >But application also needs to use : listen(fd, 8192)
> 
> I know Eric, I wrote the patch. ;-) The used naming goes like this:
> 
> The system limits (somaxconn & tcp_max_syn_backlog) specify a _maximum_, the
> user cannot exceed this limit with listen(2). The backlog argument for listen
> on the other hand specify a _minimum_. But the patch increased the default
> maximum, therefore I named it in this way.


I am not sure you understood what I said.

Even if you change kernel limits, many applications still use low
limits : listen(fd, 8)

I remember some other OS (was it HPUX or Solaris...) had a minimum
limit : Even if application said 8, an admin could impose a 256 value
for example.

Frankly, I believe somaxconn should be a default enforcement, that a
particular protocol could override.

TCP sockets for example should only enforce tcp_max_syn_backlog limit,
not the somaxconn & tcp_max_syn_backlog.