Skip to content
  • Willem de Bruijn's avatar
    udp: generate gso with UDP_SEGMENT · bec1f6f6
    Willem de Bruijn authored
    Support generic segmentation offload for udp datagrams. Callers can
    concatenate and send at once the payload of multiple datagrams with
    the same destination.
    
    To set segment size, the caller sets socket option UDP_SEGMENT to the
    length of each discrete payload. This value must be smaller than or
    equal to the relevant MTU.
    
    A follow-up patch adds cmsg UDP_SEGMENT to specify segment size on a
    per send call basis.
    
    Total byte length may then exceed MTU. If not an exact multiple of
    segment size, the last segment will be shorter.
    
    The implementation adds a gso_size field to the udp socket, ip(v6)
    cmsg cookie and inet_cork structure to be able to set the value at
    setsockopt or cmsg time and to work with both lockless and corked
    paths.
    
    Initial benchmark numbers show UDP GSO about as expensive as TCP GSO.
    
        tcp tso
         3197 MB/s 54232 msg/s 54232 calls/s
             6,457,754,262      cycles
    
        tcp gso
         1765 MB/s 29939 msg/s 29939 calls/s
            11,203,021,806      cycles
    
        tcp without tso/gso *
          739 MB/s 12548 msg/s 12548 calls/s
            11,205,483,630      cycles
    
        udp
          876 MB/s 14873 msg/s 624666 calls/s
            11,205,777,429      cycles
    
        udp gso
         2139 MB/s 36282 msg/s 36282 calls/s
            11,204,374,561      cycles
    
       [*] after reverting commit 0a6b2a1d
    
    
           ("tcp: switch to GSO being always on")
    
    Measured total system cycles ('-a') for one core while pinning both
    the network receive path and benchmark process to that core:
    
      perf stat -a -C 12 -e cycles \
        ./udpgso_bench_tx -C 12 -4 -D "$DST" -l 4
    
    Note the reduction in calls/s with GSO. Bytes per syscall drops
    increases from 1470 to 61818.
    
    Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    bec1f6f6