From: David Miller <davem@davemloft.net>
To: eric.dumazet@gmail.com
Cc: mwdalton@google.com, mst@redhat.com, netdev@vger.kernel.org,
dborkman@redhat.com, virtualization@lists.linux-foundation.org,
edumazet@google.com
Subject: Re: [PATCH] virtio-net: mergeable buffer size should include virtio-net header
Date: Thu, 14 Nov 2013 17:23:08 -0500 (EST) [thread overview]
Message-ID: <20131114.172308.1881893130228720832.davem@davemloft.net> (raw)
In-Reply-To: <1384455552.28716.28.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 10:59:12 -0800
> On Thu, 2013-11-14 at 10:41 -0800, 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. However, the merge buffer size does not take into account the
>> size of the virtio-net header. Consequently, packets that are MTU-size
>> will take two buffers intead of one (to store the virtio-net header),
>> substantially decreasing the throughput of MTU-size traffic due to TCP
>> window / SKB truesize effects.
>>
>> This commit changes the mergeable buffer size to include the virtio-net
>> header. The buffer size is cacheline-aligned because skb_page_frag_refill
>> will not automatically align the requested size.
>>
>> Benchmarks taken from an average of 5 netperf 30-second TCP_STREAM runs
>> between two QEMU VMs on a single physical machine. Each VM has two VCPUs and
>> vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup
>> cpuset, using cgroups to ensure that other processes in the system will not
>> be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive
>> buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to
>> force MTU-sized packets on the receiver.
>>
>> next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s
>> net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s
>> net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s
>> net-next trunk w/ size fix (MTU 1500 - packet fits in one buf): 6445.44Gb/s
>>
>> Suggested-by: Eric Northup <digitaleric@google.com>
>> Signed-off-by: Michael Dalton <mwdalton@google.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
prev parent reply other threads:[~2013-11-14 22:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 18:41 [PATCH] virtio-net: mergeable buffer size should include virtio-net header Michael Dalton
2013-11-14 18:59 ` Eric Dumazet
2013-11-14 22:23 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131114.172308.1881893130228720832.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=mst@redhat.com \
--cc=mwdalton@google.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).