From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Wei Xu <wexu@redhat.com>,
Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Subject: Re: [PATCH net-next] vhost_net: conditionally enable tx polling
Date: Tue, 31 Oct 2017 18:36:00 +0200 [thread overview]
Message-ID: <20171031182637-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1509445640-4085-1-git-send-email-jasowang@redhat.com>
On Tue, Oct 31, 2017 at 06:27:20PM +0800, Jason Wang wrote:
> We always poll tx for socket, this is sub optimal since:
>
> - we only want to be notified when sndbuf is available
> - this will slightly increase the waitqueue traversing time and more
> important, vhost could not benefit from commit
> commit 9e641bdcfa4e
> ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency")
> even if we've stopped rx polling during handle_rx() since tx poll
> were still left in the waitqueue.
>
> Pktgen from a remote host to VM over mlx4 shows 5.5% improvements on
> rx PPS. (from 1.27Mpps to 1.34Mpps)
>
> Cc: Wei Xu <wexu@redhat.com>
> Cc: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
Now that vhost_poll_stop happens on data path
a lot, I'd say
if (poll->wqh)
there should be unlikely().
> drivers/vhost/net.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 68677d9..286c3e4 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -471,6 +471,7 @@ static void handle_tx(struct vhost_net *net)
> goto out;
>
> vhost_disable_notify(&net->dev, vq);
> + vhost_net_disable_vq(net, vq);
>
> hdr_size = nvq->vhost_hlen;
> zcopy = nvq->ubufs;
> @@ -556,6 +557,8 @@ static void handle_tx(struct vhost_net *net)
> % UIO_MAXIOV;
> }
> vhost_discard_vq_desc(vq, 1);
> + if (err == -EAGAIN)
> + vhost_net_enable_vq(net, vq);
> break;
> }
> if (err != len)
I would probably just enable it unconditionally here. Why not?
> @@ -1145,9 +1148,11 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
> r = vhost_vq_init_access(vq);
> if (r)
> goto err_used;
> - r = vhost_net_enable_vq(n, vq);
> - if (r)
> - goto err_used;
> + if (index == VHOST_NET_VQ_RX) {
> + r = vhost_net_enable_vq(n, vq);
> + if (r)
> + goto err_used;
> + }
>
> oldubufs = nvq->ubufs;
> nvq->ubufs = ubufs;
This last chunk seems questionable. If queue has stuff in it
when we connect the backend, we'll miss a wakeup.
I suspect this can happen during migration.
> --
> 2.7.4
next prev parent reply other threads:[~2017-10-31 16:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 10:27 [PATCH net-next] vhost_net: conditionally enable tx polling Jason Wang
2017-10-31 16:36 ` Michael S. Tsirkin [this message]
2017-11-01 12:51 ` Jason Wang
2017-11-01 12:51 ` Jason Wang
2017-11-01 15:03 ` Michael S. Tsirkin
2017-11-01 15:03 ` Michael S. Tsirkin
2017-11-02 3:16 ` Jason Wang
2017-11-02 3:16 ` Jason Wang
2017-10-31 16:36 ` Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2017-10-31 10:27 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=20171031182637-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjrosato@linux.vnet.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wexu@redhat.com \
/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.