1. 09 Aug, 2013 2 commits
  2. 05 Aug, 2013 1 commit
    • fan.du's avatar
      sctp: Pack dst_cookie into 1st cacheline hole for 64bit host · 5a139296
      fan.du authored
      
      
      As dst_cookie is used in fast path sctp_transport_dst_check.
      
      Before:
      struct sctp_transport {
      	struct list_head           transports;           /*     0    16 */
      	atomic_t                   refcnt;               /*    16     4 */
      	__u32                      dead:1;               /*    20:31  4 */
      	__u32                      rto_pending:1;        /*    20:30  4 */
      	__u32                      hb_sent:1;            /*    20:29  4 */
      	__u32                      pmtu_pending:1;       /*    20:28  4 */
      
      	/* XXX 28 bits hole, try to pack */
      
      	__u32                      sack_generation;      /*    24     4 */
      
      	/* XXX 4 bytes hole, try to pack */
      
      	struct flowi               fl;                   /*    32    64 */
      	/* --- cacheline 1 boundary (64 bytes) was 32 bytes ago --- */
      	union sctp_addr            ipaddr;               /*    96    28 */
      
      After:
      struct sctp_transport {
      	struct list_head           transports;           /*     0    16 */
      	atomic_t                   refcnt;               /*    16     4 */
      	__u32                      dead:1;               /*    20:31  4 */
      	__u32                      rto_pending:1;        /*    20:30  4 */
      	__u32                      hb_sent:1;            /*    20:29  4 */
      	__u32                      pmtu_pending:1;       /*    20:28  4 */
      
      	/* XXX 28 bits hole, try to pack */
      
      	__u32                      sack_generation;      /*    24     4 */
      	u32                        dst_cookie;           /*    28     4 */
      	struct flowi               fl;                   /*    32    64 */
      	/* --- cacheline 1 boundary (64 bytes) was 32 bytes ago --- */
      	union sctp_addr            ipaddr;               /*    96    28 */
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a139296
  3. 02 Aug, 2013 1 commit
  4. 25 Jul, 2013 1 commit
  5. 25 Jun, 2013 1 commit
    • Daniel Borkmann's avatar
      net: sctp: migrate cookie life from timeval to ktime · 52db882f
      Daniel Borkmann authored
      
      
      Currently, SCTP code defines its own timeval functions (since timeval
      is rarely used inside the kernel by others), namely tv_lt() and
      TIMEVAL_ADD() macros, that operate on SCTP cookie expiration.
      
      We might as well remove all those, and operate directly on ktime
      structures for a couple of reasons: ktime is available on all archs;
      complexity of ktime calculations depending on the arch is less than
      (reduces to a simple arithmetic operations on archs with
      BITS_PER_LONG == 64 or CONFIG_KTIME_SCALAR) or equal to timeval
      functions (other archs); code becomes more readable; macros can be
      thrown out.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52db882f
  6. 22 Apr, 2013 1 commit
  7. 17 Apr, 2013 5 commits
  8. 15 Apr, 2013 2 commits
  9. 12 Feb, 2013 1 commit
  10. 07 Dec, 2012 1 commit
  11. 03 Dec, 2012 1 commit
    • Michele Baldessari's avatar
      sctp: Add support to per-association statistics via a new SCTP_GET_ASSOC_STATS call · 196d6759
      Michele Baldessari authored
      
      
      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: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      196d6759
  12. 26 Oct, 2012 1 commit
    • Neil Horman's avatar
      sctp: Make hmac algorithm selection for cookie generation dynamic · 3c68198e
      Neil Horman authored
      
      
      Currently sctp allows for the optional use of md5 of sha1 hmac algorithms to
      generate cookie values when establishing new connections via two build time
      config options.  Theres no real reason to make this a static selection.  We can
      add a sysctl that allows for the dynamic selection of these algorithms at run
      time, with the default value determined by the corresponding crypto library
      availability.
      This comes in handy when, for example running a system in FIPS mode, where use
      of md5 is disallowed, but SHA1 is permitted.
      
      Note: This new sysctl has no corresponding socket option to select the cookie
      hmac algorithm.  I chose not to implement that intentionally, as RFC 6458
      contains no option for this value, and I opted not to pollute the socket option
      namespace.
      
      Change notes:
      v2)
      	* Updated subject to have the proper sctp prefix as per Dave M.
      	* Replaced deafult selection options with new options that allow
      	  developers to explicitly select available hmac algs at build time
      	  as per suggestion by Vlad Y.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c68198e
  13. 04 Oct, 2012 1 commit
  14. 15 Aug, 2012 8 commits
  15. 22 Jul, 2012 1 commit
    • Neil Horman's avatar
      sctp: Implement quick failover draft from tsvwg · 5aa93bcf
      Neil Horman authored
      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: default avatarNeil 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: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5aa93bcf
  16. 16 Jul, 2012 1 commit
  17. 01 Jul, 2012 1 commit
    • Neil Horman's avatar
      sctp: be more restrictive in transport selection on bundled sacks · 4244854d
      Neil Horman authored
      
      
      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: default avatarNeil 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: default avatarMichele Baldessari <michele@redhat.com>
      Reported-by: default avatarsorin serban <sserban@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4244854d
  18. 15 Apr, 2012 1 commit
  19. 20 Dec, 2011 1 commit
  20. 19 Dec, 2011 1 commit
  21. 11 Dec, 2011 1 commit
  22. 08 Nov, 2011 1 commit
  23. 25 Aug, 2011 1 commit
  24. 26 Jul, 2011 1 commit
  25. 02 Jun, 2011 2 commits
  26. 31 May, 2011 1 commit