similar to: [PATCH net-next] virtio-net: drop rq->max and rq->num

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a

Rusty Russell <rusty at rustcorp.com.au> writes: > Jason Wang <jasowang at redhat.com> writes: >> It looks like there's no need for those two fields: >> >> - Unless there's a failure for the first refill try, rq->max should be always >> equal to the vring size. >> - rq->num is only used to determine the condition that we need to do the

Rusty Russell <rusty at rustcorp.com.au> writes: > Jason Wang <jasowang at redhat.com> writes: >> It looks like there's no need for those two fields: >> >> - Unless there's a failure for the first refill try, rq->max should be always >> equal to the vring size. >> - rq->num is only used to determine the condition that we need to do the

Jason Wang <jasowang at redhat.com> writes: > It looks like there's no need for those two fields: > > - Unless there's a failure for the first refill try, rq->max should be always > equal to the vring size. > - rq->num is only used to determine the condition that we need to do the refill, > we could check vq->num_free instead. > - rq->num was

On Wed, Nov 20, 2013 at 07:08:50AM -0500, Jason Wang wrote: > > > ----- ???? ----- > > On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote: > > > We need decrease the rq->num after we can get a buf through > > > virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the > > > refill routine won't be triggered under heavy

On Wed, Nov 20, 2013 at 07:08:50AM -0500, Jason Wang wrote: > > > ----- ???? ----- > > On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote: > > > We need decrease the rq->num after we can get a buf through > > > virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the > > > refill routine won't be triggered under heavy

On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote: > We need decrease the rq->num after we can get a buf through > virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the > refill routine won't be triggered under heavy memory stress since the driver may > still think there's enough room. > > This bug was introduced by commit

On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote: > We need decrease the rq->num after we can get a buf through > virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the > refill routine won't be triggered under heavy memory stress since the driver may > still think there's enough room. > > This bug was introduced by commit

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

On 01/07/2014 01:25 PM, Michael Dalton wrote: > 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

On 01/07/2014 01:25 PM, Michael Dalton wrote: > 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

This change makes ring buffer reclaim threshold num_free configurable for better performance, while it's hard coded as 1/2 * queue now. According to our test with qemu + dpdk, packet dropping happens when the guest is not able to provide free buffer in avail ring timely. Smaller value of num_free does decrease the number of packet dropping during our test as it makes virtio_net reclaim buffer

This change makes ring buffer reclaim threshold num_free configurable for better performance, while it's hard coded as 1/2 * queue now. According to our test with qemu + dpdk, packet dropping happens when the guest is not able to provide free buffer in avail ring timely. Smaller value of num_free does decrease the number of packet dropping during our test as it makes virtio_net reclaim buffer

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

The virtio_net driver's mergeable receive buffer allocator uses 4KB packet buffers. For MTU-sized traffic, SKB truesize is > 4KB but only ~1500 bytes of the buffer is used to store packet data, reducing the effective TCP window size substantially. This patch addresses the performance concerns with mergeable receive buffers by allocating MTU-sized packet buffers using page frag allocators.