H. Willstrand wrote:
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.
Sorry, but we do have the same problem! In my opinion the RST packet in
the lo test is a different issue (and not important for us; we only used
lo for excluding any faulty cables and switches). Our problem are the 3
second timeouts on client side during the connection attempt to the
server. According to the tcpdump the client never receives the SYN/ACK
packet from the server and after 3 seconds (=retransmit timeout) he
resends the SYN. Brett is talking about the absolutely same thing (and
he can reproduce "his" problem with my script) ...
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
