From: Eric Dumazet <eric.dumazet@gmail.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Willy Tarreau <w@1wt.eu>, David Miller <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: TCP_DEFER_ACCEPT is missing counter update
Date: Sat, 17 Oct 2009 14:07:22 +0200 [thread overview]
Message-ID: <4AD9B37A.3090606@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0910171417260.7818@u.domain.uli>
Julian Anastasov a écrit :
>
> I tested both patches. It seems the current algorithm to
> convert seconds to retransmissions does not match well the TCP
> SYN-ACK timer and sometimes can convert the seconds to
> retransmissions which are 1 above the expected. For example,
> you set 9 seconds (expecting 2 retrans) but you get 3 retrans,
> visible with TCP_SYNCNT=1.
>
> Also, it is limited to period of 32 retransmissions.
>
> The following patch changes the TCP_DEFER_ACCEPT
> period calculation to match TCP SYN-ACK retransmissions and to
> help those folks who select the seconds with TCP SYN-ACK
> timing in mind. It also allows the retransmission threshold
> to be up to 255.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
>
> diff -urp v2.6.31/linux/net/ipv4/tcp.c linux/net/ipv4/tcp.c
> --- v2.6.31/linux/net/ipv4/tcp.c 2009-09-11 10:27:17.000000000 +0300
> +++ linux/net/ipv4/tcp.c 2009-10-17 12:34:38.000000000 +0300
> @@ -2165,13 +2165,20 @@ static int do_tcp_setsockopt(struct sock
> case TCP_DEFER_ACCEPT:
> icsk->icsk_accept_queue.rskq_defer_accept = 0;
> if (val > 0) {
> + int timeout = TCP_TIMEOUT_INIT / HZ;
> + int period = timeout;
> +
> /* Translate value in seconds to number of
> * retransmits */
> - while (icsk->icsk_accept_queue.rskq_defer_accept < 32 &&
> - val > ((TCP_TIMEOUT_INIT / HZ) <<
> - icsk->icsk_accept_queue.rskq_defer_accept))
> + icsk->icsk_accept_queue.rskq_defer_accept = 1;
> + while (icsk->icsk_accept_queue.rskq_defer_accept < 255 &&
> + val > period) {
> icsk->icsk_accept_queue.rskq_defer_accept++;
> - icsk->icsk_accept_queue.rskq_defer_accept++;
> + timeout <<= 1;
> + if (timeout > TCP_RTO_MAX / HZ)
> + timeout = TCP_RTO_MAX / HZ;
> + period += timeout;
> + }
> }
> break;
>
>
> FYI, the old algorithm selects the following retransmissions
> for the configured seconds:
>
> defer_accept=1 retrans for 1-3 secs
> defer_accept=2 retrans for 4-6 secs
> defer_accept=3 retrans for 7-12 secs
> defer_accept=4 retrans for 13-24 secs
> defer_accept=5 retrans for 25-48 secs
> defer_accept=6 retrans for 49-96 secs
> defer_accept=7 retrans for 97-192 secs
> defer_accept=8 retrans for 193-384 secs
>
> While the new algorithm is as follows:
>
> defer_accept=1 retrans for 1-3 secs
> defer_accept=2 retrans for 4-9 secs
> defer_accept=3 retrans for 10-21 secs
> defer_accept=4 retrans for 22-45 secs
> defer_accept=5 retrans for 46-93 secs
> defer_accept=6 retrans for 94-189 secs
> defer_accept=7 retrans for 190-309 secs
> defer_accept=8 retrans for 310-429 secs
>
> Comments? Next step is to post the 3 patches separately
> for final review and applying.
>
I really like this, but please define helper functions out of do_tcp_setsockopt()
/* Translate value in seconds to number of SYN-ACK retransmits */
static u8 secs_to_retrans(int seconds)
{
u8 res = 0;
if (seconds > 0) {
int timeout = TCP_TIMEOUT_INIT / HZ;
int period = timeout;
res = 1;
while (res < 255 && seconds > period) {
res++;
timeout <<= 1;
if (timeout > TCP_RTO_MAX / HZ)
timeout = TCP_RTO_MAX / HZ;
period += timeout;
}
}
return res;
}
You also need the reverse function for getsockopt()...
next prev parent reply other threads:[~2009-10-17 12:08 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-13 5:07 TCP_DEFER_ACCEPT is missing counter update Willy Tarreau
2009-10-13 7:11 ` David Miller
2009-10-13 7:19 ` Willy Tarreau
2009-10-13 7:27 ` David Miller
2009-10-13 21:27 ` Julian Anastasov
2009-10-14 4:52 ` Willy Tarreau
2009-10-14 7:27 ` Julian Anastasov
2009-10-14 20:17 ` Willy Tarreau
2009-10-14 21:12 ` Olaf van der Spek
2009-10-14 22:43 ` David Miller
2009-10-15 6:08 ` Willy Tarreau
2009-10-15 8:47 ` Julian Anastasov
2009-10-15 12:41 ` Willy Tarreau
2009-10-15 22:44 ` Julian Anastasov
2009-10-16 3:51 ` Eric Dumazet
2009-10-16 5:00 ` Eric Dumazet
2009-10-16 5:29 ` Willy Tarreau
2009-10-16 6:05 ` Eric Dumazet
2009-10-16 6:18 ` Willy Tarreau
2009-10-16 7:08 ` Eric Dumazet
2009-10-16 7:19 ` Willy Tarreau
2009-10-16 5:03 ` Willy Tarreau
2009-10-16 8:49 ` Julian Anastasov
2009-10-16 10:40 ` Eric Dumazet
2009-10-16 19:27 ` Willy Tarreau
2009-10-17 11:48 ` Julian Anastasov
2009-10-17 12:07 ` Eric Dumazet [this message]
2009-10-17 14:20 ` Julian Anastasov
2009-10-19 20:01 ` Eric Dumazet
2009-10-19 20:11 ` Willy Tarreau
2009-10-19 20:17 ` Eric Dumazet
2009-10-20 2:23 ` David Miller
2009-10-15 7:59 ` Julian Anastasov
2009-10-16 10:08 ` Ilpo Järvinen
2009-10-13 7:23 ` Eric Dumazet
2009-10-13 7:34 ` Willy Tarreau
2009-10-13 8:08 ` Olaf van der Spek
2009-10-13 8:29 ` Eric Dumazet
2009-10-13 8:35 ` David Miller
2009-10-13 7:35 ` David Miller
2009-10-13 8:12 ` Willy Tarreau
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=4AD9B37A.3090606@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=ja@ssi.bg \
--cc=netdev@vger.kernel.org \
--cc=w@1wt.eu \
/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;
as well as URLs for NNTP newsgroup(s).