1. 05 9月, 2009 3 次提交
    • V
      sctp: Nagle delay should be based on path mtu · b29e7907
      Vlad Yasevich 提交于
      The decision to delay due to Nagle should be based on the path mtu
      and future packet size.  We currently incorrectly base it on
      'frag_point' which is the SCTP DATA segment size, and also we do
      not count DATA chunk header overhead in the computation.  This
      actuall allows situations where a user can set low 'frag_point',
      and then send small messages without delay.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      b29e7907
    • V
      sctp: Generate SACKs when actually sending outbound DATA · e83963b7
      Vlad Yasevich 提交于
      We are now trying to bundle SACKs when we have outbound
      DATA to send.  However, there are situations where this
      outbound DATA will not be sent (due to congestion or 
      available window).  In such cases it's ok to wait for the
      timer to expire.  This patch refactors the sending code
      so that betfore attempting to bundle the SACK we check
      to see if the DATA will actually be transmitted.
      
      Based on eirlier works for Doug Graham <dgraham@nortel.com> and
      Wei Youngjun <yjwei@cn.fujitsu.com>.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      e83963b7
    • D
      sctp: Fix piggybacked ACKs · af87b823
      Doug Graham 提交于
      This patch corrects the conditions under which a SACK will be piggybacked
      on a DATA packet.  The previous condition was incorrect due to a
      misinterpretation of RFC 4960 and/or RFC 2960.  Specifically, the
      following paragraph from section 6.2 had not been implemented correctly:
      
         Before an endpoint transmits a DATA chunk, if any received DATA
         chunks have not been acknowledged (e.g., due to delayed ack), the
         sender should create a SACK and bundle it with the outbound DATA
         chunk, as long as the size of the final SCTP packet does not exceed
         the current MTU.  See Section 6.2.
      
      When about to send a DATA chunk, the code now checks to see if the SACK
      timer is running.  If it is, we know we have a SACK to send to the
      peer, so we append the SACK (assuming available space in the packet)
      and turn off the timer.  For a simple request-response scenario, this
      will result in the SACK being bundled with the response, meaning the
      the SACK is received quickly by the client, and also meaning that no
      separate SACK packet needs to be sent by the server to acknowledge the
      request.  Prior to this patch, a separate SACK packet would have been
      sent by the server SCTP only after its delayed-ACK timer had expired
      (usually 200ms).  This is wasteful of bandwidth, and can also have a
      major negative impact on performance due the interaction of delayed ACKs
      with the Nagle algorithm.
      Signed-off-by: NDoug Graham <dgraham@nortel.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      af87b823
  2. 30 6月, 2009 1 次提交
  3. 03 6月, 2009 1 次提交
  4. 28 4月, 2009 1 次提交
  5. 22 3月, 2009 1 次提交
  6. 16 2月, 2009 2 次提交
  7. 01 2月, 2009 1 次提交
  8. 23 1月, 2009 1 次提交
    • V
      sctp: Properly timestamp outgoing data chunks for rtx purposes · 759af00e
      Vlad Yasevich 提交于
      Recent changes to the retransmit code exposed a long standing
      bug where it was possible for a chunk to be time stamped
      after the retransmit timer was reset.  This caused a rare
      situation where the retrnamist timer has expired, but
      nothing was marked for retrnasmission because all of
      timesamps on data were less then 1 rto ago.  As result,
      the timer was never restarted since nothing was retransmitted,
      and this resulted in a hung association that did couldn't
      complete the data transfer.  The solution is to timestamp
      the chunk when it's added to the packet for transmission
      purposes.  After the packet is trsnmitted the rtx timer
      is restarted.  This guarantees that when the timer expires,
      there will be data to retransmit.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      759af00e
  9. 01 10月, 2008 1 次提交
  10. 18 9月, 2008 1 次提交
  11. 04 8月, 2008 1 次提交
    • H
      sctp: Drop ipfargok in sctp_xmit function · f880374c
      Herbert Xu 提交于
      The ipfragok flag controls whether the packet may be fragmented
      either on the local host on beyond.  The latter is only valid on
      IPv4.
      
      In fact, we never want to do the latter even on IPv4 when PMTU is
      enabled.  This is because even though we can't fragment packets
      within SCTP due to the prtocol's inherent faults, we can still
      fragment it at IP layer.  By setting the DF bit we will improve
      the PMTU process.
      
      RFC 2960 only says that we SHOULD clear the DF bit in this case,
      so we're compliant even if we set the DF bit.  In fact RFC 4960
      no longer has this statement.
      
      Once we make this change, we only need to control the local
      fragmentation.  There is already a bit in the skb which controls
      that, local_df.  So this patch sets that instead of using the
      ipfragok argument.
      
      The only complication is that there isn't a struct sock object
      per transport, so for IPv4 we have to resort to changing the
      pmtudisc field for every packet.  This should be safe though
      as the protocol is single-threaded.
      
      Note that after this patch we can remove ipfragok from the rest
      of the stack too.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f880374c
  12. 19 7月, 2008 1 次提交
  13. 17 7月, 2008 1 次提交
  14. 20 6月, 2008 1 次提交
    • V
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich 提交于
      RFC 4960, Section 11.4. Protection of Non-SCTP-Capable Hosts
      
      When an SCTP stack receives a packet containing multiple control or
      DATA chunks and the processing of the packet requires the sending of
      multiple chunks in response, the sender of the response chunk(s) MUST
      NOT send more than one packet.  If bundling is supported, multiple
      response chunks that fit into a single packet MAY be bundled together
      into one single response packet.  If bundling is not supported, then
      the sender MUST NOT send more than one response chunk and MUST
      discard all other responses.  Note that this rule does NOT apply to a
      SACK chunk, since a SACK chunk is, in itself, a response to DATA and
      a SACK does not require a response of more DATA.
      
      We implement this by not servicing our outqueue until we reach the end
      of the packet.  This enables maximum bundling.  We also identify
      'response' chunks and make sure that we only send 1 packet when sending
      such chunks.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3216cd
  15. 05 6月, 2008 1 次提交
  16. 06 3月, 2008 1 次提交
  17. 05 2月, 2008 1 次提交
  18. 29 1月, 2008 1 次提交
  19. 11 10月, 2007 2 次提交
  20. 26 4月, 2007 1 次提交
  21. 11 2月, 2007 1 次提交
  22. 30 9月, 2006 1 次提交
  23. 18 6月, 2006 1 次提交
  24. 03 2月, 2006 1 次提交
  25. 04 1月, 2006 1 次提交
  26. 09 7月, 2005 1 次提交
  27. 29 4月, 2005 1 次提交
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4