[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1300622144.2831.287.camel@edumazet-laptop>
Date: Sun, 20 Mar 2011 12:55:44 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Hagen Paul Pfeifer <hagen@...u.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] socket: increase default maximum listen queue length
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists