[Bloat] a flood of Bufferbloat-related papers

[Eric Dumazet]

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 <zheng.z.yan at intel.com>
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 <zheng.z.yan at intel.com>
    Acked-by: Eric Dumazet <eric.dumazet at gmail.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

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))