From: Jason Wang <jasowang@redhat.com>
To: Michael Dalton <mwdalton@google.com>,
Eric Northup <digitaleric@google.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
lf-virt <virtualization@lists.linux-foundation.org>,
Daniel Borkmann <dborkman@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
Date: Wed, 30 Oct 2013 12:41:46 +0800 [thread overview]
Message-ID: <52708E0A.80904@redhat.com> (raw)
In-Reply-To: <CANJ5vP+=wCrzJ3Fdg0_5ZTTT-V-fw2AXUG=EgwsUcxXO=UpMgw@mail.gmail.com>
On 10/30/2013 03:05 AM, Michael Dalton wrote:
> Agreed Eric, the buffer size should be increased so that we can accommodate a
> MTU-sized packet + mergeable virtio net header in a single buffer. I will send
> a patch to fix shortly cleaning up the #define headers as Rusty indicated and
> increasing the buffer size slightly by VirtioNet header size bytes per Eric.
>
> Jason, I'll followup with you directly - I'd like to know your exact workload
> (single steam or multi-stream netperf?), VM configuration, etc, and also see if
> the nit that Erichas pointed out affects your results.
It's just a single TCP_STREAM from local host to guest with vhost_net
enabled. The host and guest were connected with bridge.
> It is also
> worth noting that
> we may want to tune the queue sizes for your benchmarks, e.g, by reducing
> buffer size from 4KB to MTU-sized but keeping queue length constant, we're
> implicitly decreasing the number of bytes stored in the VirtioQueue for the
> VirtioNet device, so increasing the queue size may help.
The problem is the overhead of introduced by the frag refill and frag
list. Looking at tg3 and bnx2x, the frag were only used for small
packets not for jumbo frame which does not need a frag list. But your
patch tires to use it for GSO packets. So we'd better to solve it in
device level (e.g multiple rings with different size of buffers).
I try to change the queue size from 256 to 1024. Unfortunately, I didn't
see improvement. As a workaround, If you care only the MTU size packet
and do not want GSO packet to be received, you can just disable it by
specifying gso_tso{4|6}=off in qemu command line or let's make it
configurable through ethtool.
>
> Best,
>
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-10-30 4:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-28 22:44 [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators Michael Dalton
2013-10-28 23:19 ` Eric Dumazet
2013-10-29 3:57 ` David Miller
2013-10-29 19:12 ` Michael S. Tsirkin
2013-10-29 7:30 ` Daniel Borkmann
2013-10-29 1:51 ` Rusty Russell
2013-10-29 6:27 ` Jason Wang
2013-10-29 18:44 ` Eric Northup
2013-10-29 19:05 ` Michael Dalton
2013-10-29 19:17 ` Michael S. Tsirkin
2013-10-30 4:41 ` Jason Wang [this message]
2013-10-29 19:05 ` Michael S. Tsirkin
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=52708E0A.80904@redhat.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=digitaleric@google.com \
--cc=edumazet@google.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).