All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neal Cardwell <ncardwell@google.com>
To: ttttabcd@protonmail.com
Cc: Netdev <netdev@vger.kernel.org>
Subject: Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions.
Date: Sat, 8 Sep 2018 14:24:25 -0400	[thread overview]
Message-ID: <CADVnQymHJ5VGpawQMWtcvO6YUTC-tV9bWcb0meu=c0MKmQdyhQ@mail.gmail.com> (raw)
In-Reply-To: <xtLQxGmTfE30khT4_p5QLLMtYtEMDzpenHusMD3NTAS3ikmWwsrKBHLsYdn1dYOp1na5jnapsUyxENcGDTbKbcgYHwYLYe7QBXeFLXGJznk=@protonmail.com>

On Sat, Sep 8, 2018 at 11:23 AM Ttttabcd <ttttabcd@protonmail.com> wrote:
>
> Thank you very much for your previous answer, sorry for the inconvenience.
>
> But now I want to ask you one more question.
>
> The question is why we need two variables to control the syn queue?
>
> The first is the "backlog" parameter of the "listen" system call that controls the maximum length limit of the syn queue, it also controls the accept queue.

By default, and essentially always in practice (AFAIK), Linux
installations enable syncookies. With syncookies, there is essentially
no limit on the syn queue, or number of incomplete passive connections
(as the man page you quoted notes). So in practice the listen()
parameter usually controls only the accept queue.

> The second is /proc/sys/net/ipv4/tcp_max_syn_backlog, which also controls the maximum length limit of the syn queue.
>
> So simply changing one of them and wanting to increase the syn queue is not working.
>
> In our last discussion, I understood tcp_max_syn_backlog will retain the last quarter to the IP that has been proven to be alive

That discussion pertains to a code path that is relevant if syncookies
are disabled, which is very uncommon (see above).

> But if tcp_max_syn_backlog is very large, the syn queue will be filled as well.
>
> So I don't understand why not just use a variable to control the syn queue.
>
> For example, just use tcp_max_syn_backlog, which is the maximum length limit for the syn queue, and it can also be retained to prove that the IP remains the last quarter.
>
> The backlog parameter of the listen system call only controls the accpet queue.
>
> I feel this is more reasonable. If I don't look at the source code, I really can't guess the backlog parameter actually controls the syn queue.
>
> I always thought that it only controlled the accept queue before I looked at the source code, because the man page is written like this.

Keep in mind that the semantics of the listen() argument and the
/proc/sys/net/ipv4/tcp_max_syn_backlog sysctl knob, as described in
the man page, are part of the Linux kernel's user-visible API. So, in
essence, they cannot be changed. Changing the semantics of system
calls and sysctl knobs breaks applications and system configuration
scripts. :-)

neal

  reply	other threads:[~2018-09-08 23:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04  5:31 Why not use all the syn queues? in the function "tcp_conn_request", I have some questions Ttttabcd
2018-09-04  7:23 ` Eric Dumazet
2018-09-04 13:06 ` Neal Cardwell
2018-09-05  0:20   ` Ttttabcd
2018-09-08 15:23     ` Ttttabcd
2018-09-08 18:24       ` Neal Cardwell [this message]
2018-09-09  1:14         ` Ttttabcd

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='CADVnQymHJ5VGpawQMWtcvO6YUTC-tV9bWcb0meu=c0MKmQdyhQ@mail.gmail.com' \
    --to=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=ttttabcd@protonmail.com \
    /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.