From: Eric Dumazet <eric.dumazet@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Li_Xin2@emc.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: TCP keepalive timer problem
Date: Thu, 27 Aug 2009 16:17:10 +0200 [thread overview]
Message-ID: <4A969566.3070606@gmail.com> (raw)
In-Reply-To: <87skfdl6qt.fsf@basil.nowhere.org>
Andi Kleen a écrit :
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>> Now, 7200 seconds might be inappropriate for special needs, and considering
>> there is no way to change tcp_retries2 for a given socket (only choice being the global
>> tcp_retries2 setting), I would vote for a change in our stack, to *relax* RFC,
>> and get smaller keepalive timers if possible.
>
> I think the better fix would be to just to only do that when
> tcp_retries2 > keep alive time. So keep the existing behaviour
> with default keep alive, but switch when the user defined
> a very short keep alive.
>
tcp_retries2 is a number of retries, its difficult to derive a time from it.
Also, it's not clear what behavior you are refering to.
Imagine we can be smart and compute tcp_retries2_time (in jiffies) from tcp_retries2
If keepalive_timer fires and we have packets in flight, what heuristic do you suggest ?
if (tp->packets_out || tcp_send_head(sk))
if (tcp_retries2_time < keepalive_time_when(tp))
goto resched;
elapsed = tcp_time_stamp - tp->rcv_tstamp;
...
What would be the gain ?
Arming timer exactly every keepalive_time_when(tp)
instead of keepalive_time_when(tp) - (tcp_time_stamp - tp->rcv_tstamp) ?
next prev parent reply other threads:[~2009-08-27 14:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-25 8:32 TCP keepalive timer problem Li_Xin2
2009-08-25 13:13 ` Eric Dumazet
2009-08-25 14:05 ` Li_Xin2
2009-08-27 12:45 ` Eric Dumazet
2009-08-27 13:35 ` Andi Kleen
2009-08-27 14:17 ` Eric Dumazet [this message]
2009-08-27 14:29 ` Andi Kleen
2009-08-27 14:49 ` Eric Dumazet
2009-08-28 1:55 ` Li_Xin2
2009-08-28 7:05 ` Damian Lukowski
2009-08-25 14:04 ` Andi Kleen
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=4A969566.3070606@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=Li_Xin2@emc.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--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.