similar to: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k

I don't have any guests with PAGE_SIZE > 64k but the code seems to be clearly broken in that case as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need more than 8 bit and so the code in mergeable_ctx_to_buf_address does not give us the actual true size. Cc: John Fastabend <john.fastabend at gmail.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Lightly tested on x86

I don't have any guests with PAGE_SIZE > 64k but the code seems to be clearly broken in that case as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need more than 8 bit and so the code in mergeable_ctx_to_buf_address does not give us the actual true size. Cc: John Fastabend <john.fastabend at gmail.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Lightly tested on x86

On Tue, Jan 24, 2017 at 02:42:27PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" <mst at redhat.com> > Date: Mon, 23 Jan 2017 21:37:52 +0200 > > > I don't have any guests with PAGE_SIZE > 64k but the > > code seems to be clearly broken in that case > > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > > more than 8 bit and so the

On Tue, Jan 24, 2017 at 02:42:27PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" <mst at redhat.com> > Date: Mon, 23 Jan 2017 21:37:52 +0200 > > > I don't have any guests with PAGE_SIZE > 64k but the > > code seems to be clearly broken in that case > > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > > more than 8 bit and so the

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 23 Jan 2017 21:37:52 +0200 > I don't have any guests with PAGE_SIZE > 64k but the > code seems to be clearly broken in that case > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > more than 8 bit and so the code in mergeable_ctx_to_buf_address > does not give us the actual true size. > > Cc:

We don't need to align length to any particular value anymore. Aligning to L1 cache size probably sill makes sense to reduce false sharing. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 94f94f3..824dd95 100644

We don't need to align length to any particular value anymore. Aligning to L1 cache size probably sill makes sense to reduce false sharing. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 94f94f3..824dd95 100644

Hi Michael, Here's a quick sketch of some code that enforces a minimum buffer alignment of only 64, and has a maximum theoretical buffer size of aligned GOOD_PACKET_LEN + (BUF_ALIGN - 1) * BUF_ALIGN, which is at least 1536 + 63 * 64 = 5568. On x86, we already use a 64 byte alignment, and this code supports all current buffer sizes, from 1536 to PAGE_SIZE. #if L1_CACHE_BYTES < 64 #define

Hi Michael, Here's a quick sketch of some code that enforces a minimum buffer alignment of only 64, and has a maximum theoretical buffer size of aligned GOOD_PACKET_LEN + (BUF_ALIGN - 1) * BUF_ALIGN, which is at least 1536 + 63 * 64 = 5568. On x86, we already use a 64 byte alignment, and this code supports all current buffer sizes, from 1536 to PAGE_SIZE. #if L1_CACHE_BYTES < 64 #define

Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") changed the mergeable receive buffer size from PAGE_SIZE to MTU-size, introducing a single-stream regression for benchmarks with large average packet size. There is no single optimal buffer size for all workloads. For workloads with packet size <= MTU bytes, MTU + virtio-net header-sized buffers

Add support for XDP adjust head by allocating a 256B header region that XDP programs can grow into. This is only enabled when a XDP program is loaded. In order to ensure that we do not have to unwind queue headroom push queue setup below bpf_prog_add. It reads better to do a prog ref unwind vs another queue setup call. TBD merge with Jason Wang's fixes, do a bit more testing, note

Add support for XDP adjust head by allocating a 256B header region that XDP programs can grow into. This is only enabled when a XDP program is loaded. In order to ensure that we do not have to unwind queue headroom push queue setup below bpf_prog_add. It reads better to do a prog ref unwind vs another queue setup call. TBD merge with Jason Wang's fixes, do a bit more testing, note

On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend <john.fastabend at gmail.com> wrote: > > It is a concern on my side. I want XDP and Linux stack to work > reasonably well together. btw the micro benchmarks showed that page per packet approach that xdp took in mlx4 should be 10% slower vs normal operation for tcp/ip stack. We thought that for our LB use case it will be an acceptable

On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend <john.fastabend at gmail.com> wrote: > > It is a concern on my side. I want XDP and Linux stack to work > reasonably well together. btw the micro benchmarks showed that page per packet approach that xdp took in mlx4 should be 10% slower vs normal operation for tcp/ip stack. We thought that for our LB use case it will be an acceptable

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This