summaryrefslogtreecommitdiff
path: root/net/sctp
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2006-08-26 02:39:48 +0200
committerAdrian Bunk <bunk@stusta.de>2006-08-26 02:39:48 +0200
commitfe7e513c0b87b1b41f162eb6d5ee9d48cdaaf578 (patch)
tree18ab7c1ad713991f90aac73446804432cdb78ced /net/sctp
parentcf7260ee89f7b187304a35b188cc0c889f7bdd24 (diff)
SCTP: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.
In the event that our entire receive buffer is full with a series of chunks that represent a single gap-ack, and then we accept a chunk (or chunks) that fill in the gap between the ctsn and the first gap, we renege chunks from the end of the buffer, which effectively does nothing but move our gap to the end of our received tsn stream. This does little but move our missing tsns down stream a little, and, if the sender is sending sufficiently large retransmit frames, the result is a perpetual slowdown which can never be recovered from, since the only chunk that can be accepted to allow progress in the tsn stream necessitates that a new gap be created to make room for it. This leads to a constant need for retransmits, and subsequent receiver stalls. The fix I've come up with is to deliver the frame without reneging if we have a full receive buffer and the receiving sockets sk_receive_queue is empty(indicating that the receive buffer is being blocked by a missing tsn). Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Diffstat (limited to 'net/sctp')
-rw-r--r--net/sctp/sm_statefuns.c10
1 files changed, 9 insertions, 1 deletions
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 4af8b8699392..4e59a4e0ff78 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5262,10 +5262,18 @@ static int sctp_eat_data(const struct sctp_association *asoc,
* seems a bit troublesome in that frag_point varies based on
* PMTU. In cases, such as loopback, this might be a rather
* large spill over.
+ * NOTE: If we have a full receive buffer here, we only renege if
+ * our receiver can still make progress without the tsn being
+ * received. We do this because in the event that the associations
+ * receive queue is empty we are filling a leading gap, and since
+ * reneging moves the gap to the end of the tsn stream, we are likely
+ * to stall again very shortly. Avoiding the renege when we fill a
+ * leading gap is a good heuristic for avoiding such steady state
+ * stalls.
*/
if (!asoc->rwnd || asoc->rwnd_over ||
(datalen > asoc->rwnd + asoc->frag_point) ||
- rcvbuf_over) {
+ (rcvbuf_over && (!skb_queue_len(&sk->sk_receive_queue)))) {
/* If this is the next TSN, consider reneging to make
* room. Note: Playing nice with a confused sender. A