All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH 2/2] socket: add minimum listen queue length sysctl
Date: Fri, 25 Mar 2011 13:24:37 -0700	[thread overview]
Message-ID: <1301084677.13505.26.camel@tardy> (raw)
In-Reply-To: <1301077899-16482-2-git-send-email-hagen@jauu.net>

On Fri, 2011-03-25 at 19:31 +0100, Hagen Paul Pfeifer wrote:
> In the case that a server programmer misjudge network characteristic the
> backlog parameter for listen(2) may not adequate to utilize hosts
> capabilities and lead to unrequired SYN retransmission - thus a
> underestimated backlog value can form an artificial limitation.
> 
> A listen queue length of 8 is often a way to small, but several
> server authors does not about know this limitation (from Erics server
> setup):
> 
> ss -a | head
> State      Recv-Q Send-Q      Local Address:Port          Peer
> Address:Port
> LISTEN     0      8                       *:imaps                    *:*
> LISTEN     0      8                       *:pop3s                    *:*
> LISTEN     0      50                      *:mysql                    *:*
> LISTEN     0      8                       *:pop3                     *:*
> LISTEN     0      8                       *:imap2                    *:*
> LISTEN     0      511                     *:www                      *:*
> 
> Until now it was not possible for the system (network) administrator to
> increase this value. A bug report must be filled, the backlog increased,
> a new version released or even worse: if using closed source software
> you cannot make anything.

Well, one could LD_PRELOAD something that intercepted listen() calls no?

> sysctl_min_syn_backlog provides the ability to increase the minimum
> queue length.

Is there already a similar minimum the admin can configure when the
applications makes "too small" an explicit setsockopt() call against
SO_SNDBUF or SO_RCVBUF?

rick jones


  reply	other threads:[~2011-03-25 20:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 18:31 [PATCH 1/2] socket: increase default maximum listen queue length Hagen Paul Pfeifer
2011-03-25 18:31 ` [PATCH 2/2] socket: add minimum listen queue length sysctl Hagen Paul Pfeifer
2011-03-25 20:24   ` Rick Jones [this message]
2011-03-25 23:51     ` Hagen Paul Pfeifer
2011-03-26  0:21       ` Rick Jones
2011-03-26  7:06       ` Eric Dumazet
2011-03-31  5:52 ` [PATCH 1/2] socket: increase default maximum listen queue length David Miller
  -- strict thread matches above, loose matches on Subject: below --
2011-03-20 12:14 [PATCH] " Hagen Paul Pfeifer
2011-03-20 23:04 ` [PATCH 1/2] " Hagen Paul Pfeifer
2011-03-20 23:04   ` [PATCH 2/2] socket: add minimum listen queue length sysctl Hagen Paul Pfeifer
2011-03-21  7:36     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1301084677.13505.26.camel@tardy \
    --to=rick.jones2@hp.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hagen@jauu.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.