From: Eric Dumazet <eric.dumazet@gmail.com>
To: Vijay Subramanian <subramanian.vijay@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>,
Elliot Hughes <enh@google.com>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next 1/1] tcp: Prevent needless syn-ack rexmt during TWHS
Date: Fri, 26 Oct 2012 07:06:11 +0200 [thread overview]
Message-ID: <1351227971.6537.278.camel@edumazet-glaptop> (raw)
In-Reply-To: <1351212356-11964-1-git-send-email-subramanian.vijay@gmail.com>
On Thu, 2012-10-25 at 17:45 -0700, Vijay Subramanian wrote:
> If server socket is slow to accept() connections, request_socks can represent
> connections for which the three-way handshake is already done. From client's
> point of view, the connection is in ESTABLISHED state but on server side, socket
> is not in accept_queue or ESTABLISHED state. When the syn-ack timer expires,
> because of the order in which tests are performed, server can retransmit the
> synack repeatedly. Following patch prevents the server from retransmitting the
> synack needlessly (and prevents client from replying with ack). This reduces
> traffic when server is slow to accept() connections.
>
> If the server socket has received the third ack during connection establishment,
> this is remembered in inet_rsk(req)->acked. The request_sock will expire in
> around 30 seconds and will be dropped if it does not move into accept_queue.
>
> With help from Eric Dumazet.
>
> Reported-by: Elliot Hughes <enh@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> Ignoring "WARNING: line over 80 characters" in the interest of readability.
>
> Eric,
> What about your earlier patch that modified sk_acceptq_is_full()?
Acked-by: Eric Dumazet <edumazet@google.com>
Please note Elliott Hughes takes two t, and by the way didnt reported
this particular problem. but the fact that client got the SYNACK message
while socket was not yet available to the server side.
About earlier patch, this would break :
tcp_abort_on_overflow - BOOLEAN
If listening service is too slow to accept new connections,
reset them. Default state is FALSE. It means that if overflow
occurred due to a burst, connection will recover. Enable this
option _only_ if you are really sure that listening daemon
cannot be tuned to accept connections faster. Enabling this
option can harm clients of your server.
And even if tcp_abort_on_overflow is TRUE, earlier patch would break
some ability to have a momentary burst of SYN packets above the listen()
backlog.
next prev parent reply other threads:[~2012-10-26 5:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 0:45 [PATCH net-next 1/1] tcp: Prevent needless syn-ack rexmt during TWHS Vijay Subramanian
2012-10-26 3:31 ` Neal Cardwell
2012-10-26 5:06 ` Eric Dumazet [this message]
2012-10-26 5:32 ` 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=1351227971.6537.278.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=enh@google.com \
--cc=netdev@vger.kernel.org \
--cc=subramanian.vijay@gmail.com \
--cc=venkat.x.venkatsubra@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox