From: Yi Li <lovelylich@gmail.com>
To: ilpo.jarvinen@helsinki.fi
Cc: netdev@vger.kernel.org
Subject: Why tcp_sacktag_walk specially process next_dup?
Date: Tue, 25 Dec 2012 18:35:41 +0800 [thread overview]
Message-ID: <50D9817D.2010206@gmail.com> (raw)
Hi Ilpo,
I am a kernel newbie, maybe this question is simple.
If you have some free time, could you help me ?
I am reading your commit
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=68f8353b480e5f2e136c38a511abdbb88eaa8ce2,
through this code path:
tcp_sacktag_write_queue() {
if (tcp_sack_cache_ok(tp, cache) && !dup_sack &&
after(end_seq, cache->start_seq)) {
/* Head todo? */
if (before(start_seq, cache->start_seq)) {
skb = tcp_sacktag_skip(skb, sk, &state,
start_seq);
skb = tcp_sacktag_walk(skb, sk, next_dup,
&state,
start_seq,
cache->start_seq,
dup_sack);
}
}
and when we come to tcp_sacktag_walk(), comparing the current processing
sack block
with cache, we have: start_seq < cache->start_seq, and we now need to
process the
bytes between (start_seq, cache->start_seq) in tcp_write_queue.
But in tcp_sacktag_walk(), why we first check the seqence space in
next_dup ?
I know this is about D-SACK, and I have read the rfc2883, but I am still
confused.
I have some questions:
1. Why we introduce a next_dup variable in SACK processing, is it better
for performance optimization?
As there is dup_sack variable, will this pre-processing of sack
block be mixed with dup_sack ?
2. What does this test statement means in tcp_sacktag_walk:
if ((next_dup != NULL) &&
before(TCP_SKB_CB(skb)->seq, next_dup->end_seq)) {
---------------------> A
in_sack = tcp_match_skb_to_sack(sk, skb,
next_dup->start_seq,
next_dup->end_seq);
if (in_sack > 0)
dup_sack = true;
}
as far as i know, if tcp_skb_pcout(skb)>1, this condition maybe exist:
skb->seq < current_sack_block.start_seq <
current_sack_block.end_seq < next_dup->start_seq < next_dup->end_seq.
So, I do not understand what the code A really does.
next reply other threads:[~2012-12-25 10:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-25 10:35 Yi Li [this message]
2012-12-25 20:57 ` Why tcp_sacktag_walk specially process next_dup? Ilpo Järvinen
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=50D9817D.2010206@gmail.com \
--to=lovelylich@gmail.com \
--cc=ilpo.jarvinen@helsinki.fi \
--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).