From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: TAKANO Ryousei <takano@axe-inc.co.jp>
Cc: Netdev <netdev@vger.kernel.org>, y-kodama@aist.go.jp
Subject: Re: [RFC][PATCH 2/2] TCP: skip processing cached SACK blocks
Date: Mon, 8 Oct 2007 14:20:47 +0300 (EEST) [thread overview]
Message-ID: <Pine.LNX.4.64.0710081415020.31129@kivilampi-30.cs.helsinki.fi> (raw)
In-Reply-To: <20071007.151145.32909699.takano@axe-inc.co.jp>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1177 bytes --]
On Sun, 7 Oct 2007, TAKANO Ryousei wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> > On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
> >
> > > @@ -1083,6 +1104,9 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
> > > int fack_count;
> > > int dup_sack = (found_dup_sack && (i == first_sack_index));
> > >
> > > + if (sack_block_skip[i])
> > > + continue;
> >
> > By doing this skipping here, you actually end up crippling lost_retrans
> > detection even more than it was broken before. ...You probably didn't just
> > notice that during tests because of unrelated suboptimal behavior (in
> > fastpath_skb_hint handling). ...Anyway, correctness of this should be
> > evaluated against the fixed lost_retrans, rather than the already
> > broken one.
>
> You can find the result that the average goodput slightly improves
> against the only PATCH #1 (fixed lost_retrans) applied kernel.
...Yeah, sorry, I was mistaken when the slow-path is taken and when it's
not, thought that the old (current) fastpath_skb_hint code was more
intelligent than it currently is... :-) That continue should not be
a problem.
--
i.
prev parent reply other threads:[~2007-10-08 11:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 9:44 [RFC][PATCH 2/2] TCP: skip processing cached SACK blocks TAKANO Ryousei
2007-10-05 10:37 ` Ilpo Järvinen
2007-10-07 6:11 ` TAKANO Ryousei
2007-10-08 11:20 ` Ilpo Järvinen [this message]
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=Pine.LNX.4.64.0710081415020.31129@kivilampi-30.cs.helsinki.fi \
--to=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.org \
--cc=takano@axe-inc.co.jp \
--cc=y-kodama@aist.go.jp \
/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).