• Thomas Graf's avatar
    sctp: Do not account for sizeof(struct sk_buff) in estimated rwnd · a76c0adf
    Thomas Graf authored
    When checking whether a DATA chunk fits into the estimated rwnd a
    full sizeof(struct sk_buff) is added to the needed chunk size. This
    quickly exhausts the available rwnd space and leads to packets being
    sent which are much below the PMTU limit. This can lead to much worse
    performance.
    
    The reason for this behaviour was to avoid putting too much memory
    pressure on the receiver. The concept is not completely irational
    because a Linux receiver does in fact clone an skb for each DATA chunk
    delivered. However, Linux also reserves half the available socket
    buffer space for data structures therefore usage of it is already
    accounted for.
    
    When proposing to change this the last time it was noted that this
    behaviour was introduced to solve a performance issue caused by rwnd
    overusage in combination with small DATA chunks.
    
    Trying to reproduce this I found that with the sk_buff overhead removed,
    the performance would improve significantly unless socket buffer limits
    are increased.
    
    The following numbers have been gathered using a patched iperf
    supporting SCTP over a live 1 Gbit ethernet network. The -l option
    was used to limit DATA chunk sizes. The numbers listed are based on
    the average of 3 test runs each. Default values have been used for
    sk_(r|w)mem.
    
    Chunk
    Size    Unpatched     No Overhead
    -------------------------------------
       4    15.2 Kbit [!]   12.2 Mbit [!]
       8    35.8 Kbit [!]   26.0 Mbit [!]
      16    95.5 Kbit [!]   54.4 Mbit [!]
      32   106.7 Mbit      102.3 Mbit
      64   189.2 Mbit      188.3 Mbit
     128   331.2 Mbit      334.8 Mbit
     256   537.7 Mbit      536.0 Mbit
     512   766.9 Mbit      766.6 Mbit
    1024   810.1 Mbit      808.6 Mbit
    Signed-off-by: default avatarThomas Graf <tgraf@redhat.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    a76c0adf
output.c 21.8 KB