-stable review patch. If anyone has any objections, please let us know.
------------------
Handle better the case where the sender sends full sized
frames initially, then moves to a mode where it trickles
out small amounts of data at a time.
This known problem is even mentioned in the comments
above tcp_grow_window() in tcp_input.c, specifically:
..
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
..
When the sender gives full sized frames, the "struct sk_buff" overhead
from each packet is small. So we'll advertize a larger window.
If the sender moves to a mode where small segments are sent, this
ratio becomes tilted to the other extreme and we start overrunning
the socket buffer space.
tcp_clamp_window() tries to address this, but it's clamping of
tp->window_clamp is a wee bit too aggressive for this particular case.
Fix confirmed by Ion Badulescu.
Signed-off-by: "David S. Miller" <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
net/ipv4/tcp_input.c | 2 --
1 files changed, 2 deletions(-)
Index: linux-2.6.13.y/net/ipv4/tcp_input.c
===================================================================
--- linux-2.6.13.y.orig/net/ipv4/tcp_input.c
+++ linux-2.6.13.y/net/ipv4/tcp_input.c
@@ -350,8 +350,6 @@ static void tcp_clamp_window(struct sock
app_win -= tp->ack.rcv_mss;
app_win = max(app_win, 2U*tp->advmss);
- if (!ofo_win)
- tp->window_clamp = min(tp->window_clamp, app_win);
tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
}
}
--