On Tue, Apr 1, 2008 at 8:57 AM, Leo <neleo@xxxxxxx> wrote: > I think the problem mentioned in your link is already fixed in the > 2.6.24 kernel (but this kernel has the same problems with 3 second > timeouts): > > -- > commit f785a8e28b9d103c7473655743b6ac1bc3cd3a58 > Author: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxx> > Date: Thu Oct 11 17:35:41 2007 -0700 > > [TCP]: Fix lost_retrans loop vs fastpath problems > > Detection implemented with lost_retrans must work also when > fastpath is taken, yet most of the queue is skipped including > (very likely) those retransmitted skb's we're interested in. > This problem appeared when the hints got added, which removed > a need to always walk over the whole write queue head. > Therefore decicion for the lost_retrans worker loop entry must > be separated from the sacktag processing more than it was > necessary before. > > It turns out to be problematic to optimize the worker loop > very heavily because ack_seqs of skb may have a number of > discontinuity points. Maybe similar approach as currently is > implemented could be attempted but that's becoming more and > more complex because the trend is towards less skb walking > in sacktag marker. Trying a simple work until all rexmitted > skbs heve been processed approach. > > Maybe after(highest_sack_end_seq, tp->high_seq) checking is not > sufficiently accurate and causes entry too often in no-work-to-do > cases. Since that's not known, I've separated solution to that > from this patch. > > Noticed because of report against a related problem from TAKANO > Ryousei <takano@xxxxxxxxxxxxx>. He also provided a patch to > that part of the problem. This patch includes solution to it > (though this patch has to use somewhat different placement). > TAKANO's description and patch is available here: > > http://marc.info/?l=linux-netdev&m=119149311913288&w=2 > > ...In short, TAKANO's problem is that end_seq the loop is using > not necessarily the largest SACK block's end_seq because the > current ACK may still have higher SACK blocks which are later > by the loop. > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxx> > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> > -- > > I don't know exactly what they have done but if I'm right they didn't > use the original patch. Instead they fixed the problem on a different > place in the code but this doesn't matter ... Perhaps we should try the > patch anyway. > If I'm right Brett's problem relays in the test client (provided in the first mail). This has probably to do with the number of ports opened and closed during a short time period. Leo, your issue with the faulty SYN/ACK is different, I can't reproduce it. Br H.Willstrand > Kind regards, > Leo > > > Brett Paden wrote: > > I don't completely understand what this proposed patch does, but the > > symptoms it addresses look familiar: > > > > http://projects.gtrc.aist.go.jp/gnet/sack-bug.html > > > > We're going to give it a whirl here ... > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-net" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
