• N
    [SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer. · d5b9f4c0
    Neil Horman 提交于
    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: NNeil Horman <nhorman@tuxdriver.com>
    Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    d5b9f4c0
sm_statefuns.c 167.6 KB