All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Michael Dalton <mwdalton@google.com>
Cc: 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: Tue, 29 Oct 2013 21:17:34 +0200	[thread overview]
Message-ID: <20131029191734.GF20848@redhat.com> (raw)
In-Reply-To: <CANJ5vP+=wCrzJ3Fdg0_5ZTTT-V-fw2AXUG=EgwsUcxXO=UpMgw@mail.gmail.com>

On Tue, Oct 29, 2013 at 12:05:27PM -0700, 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 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.
> 
> Best,
> 
> Mike

Well we have 256 descriptors per queue, each descriptor is 16 bytes
already and they have to be physically contigious.
I don't think we can easily increase the queue size much more without
risking memory allocation failures on busy systems.

I guess one approach is to do something like:
	 if (queue size > 1024)
		 use small buffers
	 else
		 use 4K buffers.

That would reduce the risk of regressions for existing users.


-- 
MST

  reply	other threads:[~2013-10-29 19:17 UTC|newest]

Thread overview: 16+ 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  7:30   ` Daniel Borkmann
2013-10-29  1:51 ` Rusty Russell
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:05   ` Michael Dalton
2013-10-29 19:17     ` Michael S. Tsirkin [this message]
2013-10-30  4:41     ` Jason Wang
2013-10-29 19:05   ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2013-10-28 22:44 Michael Dalton

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=20131029191734.GF20848@redhat.com \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=edumazet@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.