From: "Yan, Zheng" <zheng.z.yan@intel.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Nandita Dukkipati <nanditad@google.com>
Subject: Re: [PATCH] tcp: properly update lost_cnt_hint during shifting
Date: Wed, 28 Sep 2011 16:55:10 +0800 [thread overview]
Message-ID: <4E82E0EE.1050600@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1109281103410.21709@wel-95.cs.helsinki.fi>
On 09/28/2011 04:17 PM, Ilpo Järvinen wrote:
> On Wed, 28 Sep 2011, Yan, Zheng wrote:
>
>> lost_skb_hint is used by tcp_mark_head_lost() to mark the first
>> unhandled skb. lost_cnt_hint is the number of sacked packets before
>> the lost_skb_hint. tcp_shifted_skb() shouldn't increase lost_cnt_hint
>> when shifting a sacked skb that is before the lost_skb_hint, because
>> packets in it are already counted.
>>
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
>> ---
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 21fab3e..f712ace 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -1390,9 +1390,14 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
>> BUG_ON(!pcount);
>>
>> /* Tweak before seqno plays */
>> - if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
>> - !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
>> - tp->lost_cnt_hint += pcount;
>> + if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint) {
>> + if (skb == tp->lost_skb_hint)
>> + tp->lost_cnt_hint += pcount;
>> + else if (!(TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED) &&
>> + before(TCP_SKB_CB(skb)->seq,
>> + TCP_SKB_CB(tp->lost_skb_hint)->seq))
>> + tp->lost_cnt_hint += pcount;
>> + }
>
> Ah right, the hole filled case which shifts not only the newly SACKed
> skb but also the next, already SACKed skb?
>
> I fail to see why you needed to change !before into two checks though:
> skb == tp->lost_skb_hint and before(params reversed) ? Shouldn't the
> equality that is provided by the negation cover for the == check (and the
> params reversion isn't necessary in any case)? In fact, isn't the skb ==
> tp->lost_skb_hint check strictly wrong without the same TCPCB_SACKED_ACKED
> guard (though I'm not sure, I didn't check, if the hint can ever point to
> such a segment in the first place)?
Thanks you for your reply.
skb == tp->lost_skb_hint is special.
If the skb is sacked and we shift 'pcount' packets to previous skb,
these packets will not be counted by future tcp_mark_head_lost() call.
So we should increase lost_cnt_hint.
If the skb is not sacked, the skb will be sacked soon by tcp_sacktag_one(),
So we should not increase lost_cnt_hint.
I didn't think out the second case. I think the correct patch should be:
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21fab3e..dcc2411 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1390,9 +1390,15 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
BUG_ON(!pcount);
/* Tweak before seqno plays */
- if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
- !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
- tp->lost_cnt_hint += pcount;
+ if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint) {
+ if ((TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED) &&
+ skb == tp->lost_skb_hint)
+ tp->lost_cnt_hint += pcount;
+ else if (!(TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED) &&
+ before(TCP_SKB_CB(skb)->seq,
+ TCP_SKB_CB(tp->lost_skb_hint)->seq))
+ tp->lost_cnt_hint += pcount;
+ }
TCP_SKB_CB(prev)->end_seq += shifted;
TCP_SKB_CB(skb)->seq += shifted;
---
>
> Added Cc to Nandita as they're hunting (possibly other) bug in
> tcp_mark_head_lost.
>
next prev parent reply other threads:[~2011-09-28 8:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 6:38 [PATCH] tcp: properly update lost_cnt_hint during shifting Yan, Zheng
2011-09-28 8:17 ` Ilpo Järvinen
2011-09-28 8:55 ` Yan, Zheng [this message]
2011-09-28 9:15 ` Yan, Zheng
2011-09-28 9:50 ` Ilpo Järvinen
2011-09-28 10:45 ` Yan, Zheng
2011-09-28 11:29 ` Ilpo Järvinen
2011-09-29 0:06 ` Nandita Dukkipati
2011-09-29 0:12 ` Nandita Dukkipati
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=4E82E0EE.1050600@intel.com \
--to=zheng.z.yan@intel.com \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=nanditad@google.com \
--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 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).