1. 03 12月, 2006 9 次提交
  2. 31 10月, 2006 3 次提交
  3. 19 10月, 2006 2 次提交
  4. 12 10月, 2006 2 次提交
  5. 30 9月, 2006 4 次提交
  6. 23 9月, 2006 9 次提交
  7. 21 9月, 2006 1 次提交
  8. 30 8月, 2006 1 次提交
  9. 23 8月, 2006 1 次提交
  10. 22 7月, 2006 5 次提交
  11. 01 7月, 2006 1 次提交
  12. 20 6月, 2006 1 次提交
  13. 18 6月, 2006 1 次提交
    • 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