On Sun, 7 Oct 2007, TAKANO Ryousei wrote: > From: "Ilpo Järvinen" <[EMAIL PROTECTED]> > > 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.
