Le mardi 11 octobre 2011 à 13:58 +0200, Steinar H. Gunderson a écrit : > On Tue, Oct 11, 2011 at 12:27:17PM +0200, David Täht wrote: > > On my list already would be "an analysis of the effects of broken sack > > processing on linux 2.4.24-3.1", of which I *think* I've captured > > multiple examples of in the raw traces I've been collecting for > > months... (so if anyone is interested in the raw data, I can provide) > > Do you have any more information? The only thing I could find online was that > there were SACK issues that were supposed to be fixed by 2.6.16; nothing > about a fix in 3.1 or post-3.1. >
Of course, instead of discussing all linux stuff privately, it would be good to discuss with linux network maintainers. Or is the goal is to provide nice papers only ? commit f779b2d60ab95c17f1e025778ed0df3ec2f05d75 Author: Zheng Yan <[email protected]> Date: Sun Sep 18 22:37:34 2011 -0400 tcp: fix validation of D-SACK D-SACK is allowed to reside below snd_una. But the corresponding check in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo. Signed-off-by: Zheng Yan <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index ea0d218..21fab3e 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack, return 0; /* ...Then it's D-SACK, and must reside below snd_una completely */ - if (!after(end_seq, tp->snd_una)) + if (after(end_seq, tp->snd_una)) return 0; if (!before(start_seq, tp->undo_marker)) _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
