1. 16 Feb, 2009 1 commit
    • Lucas Nussbaum's avatar
      sctp: Allow to disable SCTP checksums via module parameter · 06e86806
      Lucas Nussbaum authored
      This is a new version of my patch, now using a module parameter instead
      of a sysctl, so that the option is harder to find. Please note that,
      once the module is loaded, it is still possible to change the value of
      the parameter in /sys/module/sctp/parameters/, which is useful if you
      want to do performance comparisons without rebooting.
      Computation of SCTP checksums significantly affects the performance of
      SCTP. For example, using two dual-Opteron 246 connected using a Gbe
      network, it was not possible to achieve more than ~730 Mbps, compared to
      941 Mbps after disabling SCTP checksums.
      Unfortunately, SCTP checksum offloading in NICs is not commonly
      available (yet).
      By default, checksums are still enabled, of course.
      Signed-off-by: default avatarLucas Nussbaum <lucas.nussbaum@ens-lyon.fr>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 08 Oct, 2008 1 commit
    • Vlad Yasevich's avatar
      sctp: Rework the tsn map to use generic bitmap. · 8e1ee18c
      Vlad Yasevich authored
      The tsn map currently use is 4K large and is stuck inside
      the sctp_association structure making memory references REALLY
      expensive.  What we really need is at most 4K worth of bits
      so the biggest map we would have is 512 bytes.   Also, the
      map is only really usefull when we have gaps to store and
      report.  As such, starting with minimal map of say 32 TSNs (bits)
      should be enough for normal low-loss operations.  We can grow
      the map by some multiple of 32 along with some extra room any
      time we receive the TSN which would put us outside of the map
      boundry.  As we close gaps, we can shift the map to rebase
      it on the latest TSN we've seen.  This saves 4088 bytes per
      association just in the map alone along savings from the now
      unnecessary structure members.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 01 Oct, 2008 2 commits
  4. 04 Aug, 2008 1 commit
    • Herbert Xu's avatar
      sctp: Drop ipfargok in sctp_xmit function · f880374c
      Herbert Xu authored
      The ipfragok flag controls whether the packet may be fragmented
      either on the local host on beyond.  The latter is only valid on
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 22 Jul, 2008 1 commit
  6. 19 Jul, 2008 1 commit
  7. 19 Jun, 2008 1 commit
    • Vlad Yasevich's avatar
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich authored
      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: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 04 Jun, 2008 4 commits
  9. 09 May, 2008 1 commit
  10. 24 Mar, 2008 1 commit
  11. 29 Feb, 2008 1 commit
  12. 05 Feb, 2008 1 commit
  13. 28 Jan, 2008 5 commits
  14. 20 Dec, 2007 1 commit
  15. 07 Dec, 2007 1 commit
  16. 09 Nov, 2007 1 commit
  17. 07 Nov, 2007 4 commits
  18. 11 Oct, 2007 1 commit
  19. 10 Oct, 2007 6 commits
  20. 26 Sep, 2007 2 commits
  21. 16 Sep, 2007 2 commits
  22. 30 Aug, 2007 1 commit
    • Wei Yongjun's avatar
      SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly · 00f1c2df
      Wei Yongjun authored
      PROTOCOL VIOLATION error cause in ABORT is bad encode when make abort
      chunk. When SCTP encode ABORT chunk with PROTOCOL VIOLATION error cause,
      it just add the error messages to PROTOCOL VIOLATION error cause, the
      rest four bytes(struct sctp_paramhdr) is just add to the chunk, not
      change the length of error cause. This cause the ABORT chunk to be a bad
      format. The chunk is like this:
      ABORT chunk
        Chunk type: ABORT (6)
        Chunk flags: 0x00
        Chunk length: 72 (*1)
        Protocol violation cause
          Cause code: Protocol violation (0x000d)
          Cause length: 62 (*2)
          Cause information: 5468652063756D756C61746976652074736E2061636B2062...
          Cause padding: 0000
      [Needless] 00030010
      Chunk Length(*1) = 72 but Cause length(*2) only 62, not include the
      extend 4 bytes.
      ((72 - sizeof(chunk_hdr)) = 68) != (62 +3) / 4 * 4
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>