[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVnQyn4X57Tz8GxJRU84=Jr2x1j29ZK8xJfdLjnb2a2g45S0A@mail.gmail.com>
Date: Thu, 10 Dec 2015 10:37:32 -0500
From: Neal Cardwell <ncardwell@...gle.com>
To: Per Hurtig <per.hurtig@....se>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Nandita Dukkipati <nanditad@...gle.com>,
Tom Herbert <tom@...bertland.com>,
Yuchung Cheng <ycheng@...gle.com>,
Al Viro <viro@...iv.linux.org.uk>,
Florian Westphal <fw@...len.de>,
Marcelo Ricardo Leitner <mleitner@...hat.com>,
Daniel Borkmann <daniel@...earbox.net>,
Willem de Bruijn <willemb@...gle.com>,
Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
Pasi Sarolahti <pasi.sarolahti@....fi>,
Stephen Hemminger <stephen@...workplumber.org>,
Netdev <netdev@...r.kernel.org>,
Anna Brunström <anna.brunstrom@....se>,
Andreas Petlund <apetlund@...ula.no>,
Michael Welzl <michawe@....uio.no>,
Mohammad Rajiullah <mohammad.rajiullah@....se>
Subject: Re: [RFC PATCHv2 net-next 1/2] tcp: RTO Restart (RTOR)
On Thu, Dec 10, 2015 at 1:51 AM, Per Hurtig <per.hurtig@....se> wrote:
>
>> On 08 Dec 2015, at 14:47, Eric Dumazet <eric.dumazet@...il.com> wrote:
>>
>> On Tue, 2015-12-08 at 10:19 +0100, Per Hurtig wrote:
>>
>>> +static u32 tcp_unsent_pkts(const struct sock *sk, u32 ulimit)
>>> +{
>>> + struct sk_buff *skb = tcp_send_head(sk);
>>> + u32 pkts = 0;
>>> +
>>> + if (skb)
>>> + tcp_for_write_queue_from(skb, sk) {
>>> + pkts += tcp_skb_pcount(skb);
>>> +
>>> + if (ulimit && pkts >= ulimit)
>>> + return ulimit;
>>> + }
>>> +
>>> + return pkts;
>>> +}
>>
>>
>> Considering Yuchung feedback, have you looked at using an approximation
>> instead ?
>>
>> (ie using tp->write_seq - tp->snd_nxt)
>>
>>
>
> Well, an approximation is rather “dangerous” as missing a single packet
> could inhibit the desired behaviour. If looping is undesired, I think a
> better solution is to actually *not* do this check at all and instead rely
> solely on the
>
> tp->packets_out < TCP_RTORESTART_THRESH
Yes, this simpler version seems very much preferable, IMHO. I agree
that it does not seem worth the complexity to try to cover the kind of
corner cases you outline.
I would also suggest a TCP_RTORESTART_THRESH value higher than 4.
In the ID at https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-10 it says:
The RECOMMENDED value of rrthresh is four, as this value will ensure
that RTOR is only used when fast retransmit cannot be triggered.
But my sense is that fast retransmit is often not triggered at
in-flight counts of much higher than 4, due to drop-tail queues, TSO
bursts, the initial IW10 being unpaced, etc. It would be interesting
to see A/B experiments for a few TCP_RTORESTART_THRESH values, say, 4
vs 10.
neal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists