1. 05 2月, 2013 1 次提交
  2. 08 12月, 2012 1 次提交
  3. 04 12月, 2012 1 次提交
    • M
      sctp: Add support to per-association statistics via a new SCTP_GET_ASSOC_STATS call · 196d6759
      Michele Baldessari 提交于
      The current SCTP stack is lacking a mechanism to have per association
      statistics. This is an implementation modeled after OpenSolaris'
      SCTP_GET_ASSOC_STATS.
      
      Userspace part will follow on lksctp if/when there is a general ACK on
      this.
      V4:
      - Move ipackets++ before q->immediate.func() for consistency reasons
      - Move sctp_max_rto() at the end of sctp_transport_update_rto() to avoid
        returning bogus RTO values
      - return asoc->rto_min when max_obs_rto value has not changed
      
      V3:
      - Increase ictrlchunks in sctp_assoc_bh_rcv() as well
      - Move ipackets++ to sctp_inq_push()
      - return 0 when no rto updates took place since the last call
      
      V2:
      - Implement partial retrieval of stat struct to cope for future expansion
      - Kill the rtxpackets counter as it cannot be precise anyway
      - Rename outseqtsns to outofseqtsns to make it clearer that these are out
        of sequence unexpected TSNs
      - Move asoc->ipackets++ under a lock to avoid potential miscounts
      - Fold asoc->opackets++ into the already existing asoc check
      - Kill unneeded (q->asoc) test when increasing rtxchunks
      - Do not count octrlchunks if sending failed (SCTP_XMIT_OK != 0)
      - Don't count SHUTDOWNs as SACKs
      - Move SCTP_GET_ASSOC_STATS to the private space API
      - Adjust the len check in sctp_getsockopt_assoc_stats() to allow for
        future struct growth
      - Move association statistics in their own struct
      - Update idupchunks when we send a SACK with dup TSNs
      - return min_rto in max_rto when RTO has not changed. Also return the
        transport when max_rto last changed.
      
      Signed-off: Michele Baldessari <michele@acksyn.org>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      196d6759
  4. 15 8月, 2012 6 次提交
  5. 23 7月, 2012 1 次提交
    • N
      sctp: Implement quick failover draft from tsvwg · 5aa93bcf
      Neil Horman 提交于
      I've seen several attempts recently made to do quick failover of sctp transports
      by reducing various retransmit timers and counters.  While its possible to
      implement a faster failover on multihomed sctp associations, its not
      particularly robust, in that it can lead to unneeded retransmits, as well as
      false connection failures due to intermittent latency on a network.
      
      Instead, lets implement the new ietf quick failover draft found here:
      http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
      
      This will let the sctp stack identify transports that have had a small number of
      errors, and avoid using them quickly until their reliability can be
      re-established.  I've tested this out on two virt guests connected via multiple
      isolated virt networks and believe its in compliance with the above draft and
      works well.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: Sridhar Samudrala <sri@us.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: linux-sctp@vger.kernel.org
      CC: joe@perches.com
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5aa93bcf
  6. 16 7月, 2012 1 次提交
  7. 01 7月, 2012 1 次提交
    • N
      sctp: be more restrictive in transport selection on bundled sacks · 4244854d
      Neil Horman 提交于
      It was noticed recently that when we send data on a transport, its possible that
      we might bundle a sack that arrived on a different transport.  While this isn't
      a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
      2960:
      
       An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
         etc.) to the same destination transport address from which it
         received the DATA or control chunk to which it is replying.  This
         rule should also be followed if the endpoint is bundling DATA chunks
         together with the reply chunk.
      
      This patch seeks to correct that.  It restricts the bundling of sack operations
      to only those transports which have moved the ctsn of the association forward
      since the last sack.  By doing this we guarantee that we only bundle outbound
      saks on a transport that has received a chunk since the last sack.  This brings
      us into stricter compliance with the RFC.
      
      Vlad had initially suggested that we strictly allow only sack bundling on the
      transport that last moved the ctsn forward.  While this makes sense, I was
      concerned that doing so prevented us from bundling in the case where we had
      received chunks that moved the ctsn on multiple transports.  In those cases, the
      RFC allows us to select any of the transports having received chunks to bundle
      the sack on.  so I've modified the approach to allow for that, by adding a state
      variable to each transport that tracks weather it has moved the ctsn since the
      last sack.  This I think keeps our behavior (and performance), close enough to
      our current profile that I think we can do this without a sysctl knob to
      enable/disable it.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yaseivch <vyasevich@gmail.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: linux-sctp@vger.kernel.org
      Reported-by: NMichele Baldessari <michele@redhat.com>
      Reported-by: Nsorin serban <sserban@redhat.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4244854d
  8. 16 4月, 2012 1 次提交
  9. 20 12月, 2011 1 次提交
  10. 25 8月, 2011 1 次提交
  11. 02 6月, 2011 1 次提交
  12. 01 6月, 2011 1 次提交
  13. 26 5月, 2011 1 次提交
  14. 13 4月, 2011 2 次提交
  15. 31 3月, 2011 1 次提交
  16. 08 3月, 2011 1 次提交
  17. 27 8月, 2010 1 次提交
  18. 17 6月, 2010 1 次提交
  19. 18 5月, 2010 1 次提交
  20. 01 5月, 2010 4 次提交
  21. 29 4月, 2010 1 次提交
  22. 24 11月, 2009 5 次提交
  23. 14 11月, 2009 1 次提交
    • V
      sctp: Set source addresses on the association before adding transports · 409b95af
      Vlad Yasevich 提交于
      Recent commit 8da645e1
      	sctp: Get rid of an extra routing lookup when adding a transport
      introduced a regression in the connection setup.  The behavior was
      
      different between IPv4 and IPv6.  IPv4 case ended up working because the
      route lookup routing returned a NULL route, which triggered another
      route lookup later in the output patch that succeeded.  In the IPv6 case,
      a valid route was returned for first call, but we could not find a valid
      source address at the time since the source addresses were not set on the
      association yet.  Thus resulted in a hung connection.
      
      The solution is to set the source addresses on the association prior to
      adding peers.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      409b95af
  24. 05 9月, 2009 4 次提交
    • V
      sctp: Get rid of an extra routing lookup when adding a transport. · 8da645e1
      Vlad Yasevich 提交于
      We used to perform 2 routing lookups for a new transport: one
      just for path mtu detection, and one to actually route to destination
      and path mtu update when sending a packet.  There is no point in doing
      both of them, especially since the first one just for path mtu doesn't
      take into account source address and sometimes gives the wrong route,
      causing path mtu updates anyway.
      
      We now do just the one call to do both route to destination and get
      path mtu updates.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      8da645e1
    • V
      sctp: Failover transmitted list on transport delete · 31b02e15
      Vlad Yasevich 提交于
      Add-IP feature allows users to delete an active transport.  If that
      transport has chunks in flight, those chunks need to be moved to another
      transport or association may get into unrecoverable state.
      Reported-by: NRafael Laufer <rlaufer@cisco.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      31b02e15
    • V
      sctp: Fix SCTP_MAXSEG socket option to comply to spec. · f68b2e05
      Vlad Yasevich 提交于
      We had a bug that we never stored the user-defined value for
      MAXSEG when setting the value on an association.  Thus future
      PMTU events ended up re-writing the frag point and increasing
      it past user limit.  Additionally, when setting the option on
      the socket/endpoint, we effect all current associations, which
      is against spec.
      
      Now, we store the user 'maxseg' value along with the computed
      'frag_point'.  We inherit 'maxseg' from the socket at association
      creation and use it as an upper limit for 'frag_point' when its
      set.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      f68b2e05
    • V
      sctp: drop a_rwnd to 0 when receive buffer overflows. · 4d3c46e6
      Vlad Yasevich 提交于
      SCTP has a problem that when small chunks are used, it is possible
      to exhaust the receiver buffer without fully closing receive window.
      This happens due to all overhead that we have account for with small
      messages.  To fix this, when receive buffer is exceeded, we'll drop
      the window to 0 and save the 'drop' portion.  When application starts
      reading data and freeing up recevie buffer space, we'll wait until
      we've reached the 'drop' window and then add back this 'drop' one
      mtu at a time.  This worked well in testing and under stress produced
      rather even recovery.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      4d3c46e6