From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 6/6] vhost_net: remove the max pending check
Date: Fri, 23 Aug 2013 16:55:49 +0800 [thread overview]
Message-ID: <52172395.9000400@redhat.com> (raw)
In-Reply-To: <5212D8F2.10307@redhat.com>
On 08/20/2013 10:48 AM, Jason Wang wrote:
> On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote:
>> > On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote:
>>> >> We used to limit the max pending DMAs to prevent guest from pinning too many
>>> >> pages. But this could be removed since:
>>> >>
>>> >> - We have the sk_wmem_alloc check in both tun/macvtap to do the same work
>>> >> - This max pending check were almost useless since it was one done when there's
>>> >> no new buffers coming from guest. Guest can easily exceeds the limitation.
>>> >> - We've already check upend_idx != done_idx and switch to non zerocopy then. So
>>> >> even if all vq->heads were used, we can still does the packet transmission.
>> > We can but performance will suffer.
> The check were in fact only done when no new buffers submitted from
> guest. So if guest keep sending, the check won't be done.
>
> If we really want to do this, we should do it unconditionally. Anyway, I
> will do test to see the result.
There's a bug in PATCH 5/6, the check:
nvq->upend_idx != nvq->done_idx
makes the zerocopy always been disabled since we initialize both
upend_idx and done_idx to zero. So I change it to:
(nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx.
With this change on top, I didn't see performance difference w/ and w/o
this patch.
next prev parent reply other threads:[~2013-08-23 8:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 5:16 [PATCH 0/6] vhost code cleanup and minor enhancement Jason Wang
2013-08-16 5:16 ` [PATCH 1/6] vhost_net: make vhost_zerocopy_signal_used() returns void Jason Wang
2013-08-16 5:16 ` [PATCH 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used() Jason Wang
2013-08-16 9:54 ` Michael S. Tsirkin
2013-08-20 2:33 ` Jason Wang
2013-08-23 8:50 ` Jason Wang
2013-08-25 11:48 ` Michael S. Tsirkin
2013-08-16 5:16 ` [PATCH 3/6] vhost: switch to use vhost_add_used_n() Jason Wang
2013-08-16 9:56 ` Michael S. Tsirkin
2013-08-20 2:36 ` Jason Wang
2013-08-16 5:16 ` [PATCH 4/6] vhost_net: determine whether or not to use zerocopy at one time Jason Wang
2013-08-16 5:16 ` [PATCH 5/6] vhost_net: poll vhost queue after marking DMA is done Jason Wang
2013-08-16 10:00 ` Michael S. Tsirkin
2013-08-20 2:44 ` Jason Wang
2013-08-16 5:16 ` [PATCH 6/6] vhost_net: remove the max pending check Jason Wang
2013-08-16 10:02 ` Michael S. Tsirkin
2013-08-20 2:48 ` Jason Wang
2013-08-23 8:55 ` Jason Wang [this message]
2013-08-25 11:53 ` Michael S. Tsirkin
2013-08-26 7:00 ` Jason Wang
2013-08-30 3:23 ` Jason Wang
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=52172395.9000400@redhat.com \
--to=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.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).