aboutsummaryrefslogtreecommitdiffstats
path: root/net/decnet
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2006-06-17 22:59:03 -0700
committerDavid S. Miller <davem@davemloft.net>2006-06-17 22:59:03 -0700
commitd5b9f4c083b0e3102f3101545279f623680cb3a0 (patch)
tree86d5f77d14a8ae687e585ec4535ca8038e450ab9 /net/decnet
parent[SCTP]: Send only 1 window update SACK per message. (diff)
downloadlinux-dev-d5b9f4c083b0e3102f3101545279f623680cb3a0.tar.xz
linux-dev-d5b9f4c083b0e3102f3101545279f623680cb3a0.zip
[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>
Diffstat (limited to 'net/decnet')
0 files changed, 0 insertions, 0 deletions