Skip to content
  • Mark McLoughlin's avatar
    virtio_net: VIRTIO_NET_F_MSG_RXBUF (imprive rcv buffer allocation) · 3f2c31d9
    Mark McLoughlin authored
    
    
    If segmentation offload is enabled by the host, we currently allocate
    maximum sized packet buffers and pass them to the host. This uses up
    20 ring entries, allowing us to supply only 20 packet buffers to the
    host with a 256 entry ring. This is a huge overhead when receiving
    small packets, and is most keenly felt when receiving MTU sized
    packets from off-host.
    
    The VIRTIO_NET_F_MRG_RXBUF feature flag is set by hosts which support
    using receive buffers which are smaller than the maximum packet size.
    In order to transfer large packets to the guest, the host merges
    together multiple receive buffers to form a larger logical buffer.
    The number of merged buffers is returned to the guest via a field in
    the virtio_net_hdr.
    
    Make use of this support by supplying single page receive buffers to
    the host. On receive, we extract the virtio_net_hdr, copy 128 bytes of
    the payload to the skb's linear data buffer and adjust the fragment
    offset to point to the remaining data. This ensures proper alignment
    and allows us to not use any paged data for small packets. If the
    payload occupies multiple pages, we simply append those pages as
    fragments and free the associated skbs.
    
    This scheme allows us to be efficient in our use of ring entries
    while still supporting large packets. Benchmarking using netperf from
    an external machine to a guest over a 10Gb/s network shows a 100%
    improvement from ~1Gb/s to ~2Gb/s. With a local host->guest benchmark
    with GSO disabled on the host side, throughput was seen to increase
    from 700Mb/s to 1.7Gb/s.
    
    Based on a patch from Herbert Xu.
    
    Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use netdev_priv)
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    3f2c31d9