lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 8 May 2020 10:05:46 +0800
From:   Jason Wang <>
To:     "Michael S. Tsirkin" <>,
        Jesper Dangaard Brouer <>
        Toke Høiland-Jørgensen <>,
        Daniel Borkmann <>,
        Alexei Starovoitov <>,
        John Fastabend <>,
        Alexander Duyck <>,
        Jeff Kirsher <>,
        David Ahern <>,
        Willem de Bruijn <>,
        Ilias Apalodimas <>,
        Lorenzo Bianconi <>,
        Saeed Mahameed <>,
Subject: Re: [PATCH net-next v2 21/33] virtio_net: add XDP frame size in two
 code paths

On 2020/5/7 上午4:34, Michael S. Tsirkin wrote:
> On Thu, Apr 30, 2020 at 01:22:08PM +0200, Jesper Dangaard Brouer wrote:
>> The virtio_net driver is running inside the guest-OS. There are two
>> XDP receive code-paths in virtio_net, namely receive_small() and
>> receive_mergeable(). The receive_big() function does not support XDP.
>> In receive_small() the frame size is available in buflen. The buffer
>> backing these frames are allocated in add_recvbuf_small() with same
>> size, except for the headroom, but tailroom have reserved room for
>> skb_shared_info. The headroom is encoded in ctx pointer as a value.
>> In receive_mergeable() the frame size is more dynamic. There are two
>> basic cases: (1) buffer size is based on a exponentially weighted
>> moving average (see DECLARE_EWMA) of packet length. Or (2) in case
>> virtnet_get_headroom() have any headroom then buffer size is
>> PAGE_SIZE. The ctx pointer is this time used for encoding two values;
>> the buffer len "truesize" and headroom. In case (1) if the rx buffer
>> size is underestimated, the packet will have been split over more
>> buffers (num_buf info in virtio_net_hdr_mrg_rxbuf placed in top of
>> buffer area). If that happens the XDP path does a xdp_linearize_page
>> operation.
>> Cc: Jason Wang<>
>> Signed-off-by: Jesper Dangaard Brouer<>
> Acked-by: Michael S. Tsirkin<>

Note that we do:

         xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;

So using PAGE_SIZE here is probably not correct.



Powered by blists - more mailing lists