From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] vhost: better detection of available buffers
Date: Tue, 15 Nov 2016 16:46:59 +0200 [thread overview]
Message-ID: <20161115164620-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <8bf86752-4dca-3ced-4641-efa7a4a1fc6e@redhat.com>
On Tue, Nov 15, 2016 at 04:00:21PM +0800, Jason Wang wrote:
>
>
> On 2016年11月15日 11:28, Michael S. Tsirkin wrote:
> > On Tue, Nov 15, 2016 at 11:16:59AM +0800, Jason Wang wrote:
> > >
> > > On 2016年11月12日 00:20, Michael S. Tsirkin wrote:
> > > > On Fri, Nov 11, 2016 at 12:18:50PM +0800, Jason Wang wrote:
> > > > > On 2016年11月11日 11:41, Michael S. Tsirkin wrote:
> > > > > > On Fri, Nov 11, 2016 at 10:18:37AM +0800, Jason Wang wrote:
> > > > > > > > On 2016年11月10日 03:57, Michael S. Tsirkin wrote:
> > > > > > > > > > On Wed, Nov 09, 2016 at 03:38:32PM +0800, Jason Wang wrote:
> > > > > > > > > > > > We should use vq->last_avail_idx instead of vq->avail_idx in the
> > > > > > > > > > > > checking of vhost_vq_avail_empty() since latter is the cached avail
> > > > > > > > > > > > index from guest but we want to know if there's pending available
> > > > > > > > > > > > buffers in the virtqueue.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > > > > > > > > > I'm not sure why is this patch here. Is it related to
> > > > > > > > > > batching somehow?
> > > > > > > > Yes, we need to know whether or not there's still buffers left in the
> > > > > > > > virtqueue, so need to check last_avail_idx. Otherwise, we're checking if
> > > > > > > > guest has submitted new buffers.
> > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > > drivers/vhost/vhost.c | 2 +-
> > > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > > > > > > > > index c6f2d89..fdf4cdf 100644
> > > > > > > > > > > > --- a/drivers/vhost/vhost.c
> > > > > > > > > > > > +++ b/drivers/vhost/vhost.c
> > > > > > > > > > > > @@ -2230,7 +2230,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> > > > > > > > > > > > if (r)
> > > > > > > > > > > > return false;
> > > > > > > > > > > > - return vhost16_to_cpu(vq, avail_idx) == vq->avail_idx;
> > > > > > > > > > > > + return vhost16_to_cpu(vq, avail_idx) == vq->last_avail_idx;
> > > > > > > > > > > > }
> > > > > > > > > > > > EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
> > > > > > > > > > That might be OK for TX but it's probably wrong for RX
> > > > > > > > > > where the fact that used != avail does not mean
> > > > > > > > > > we have enough space to store the packet.
> > > > > > > > Right, but it's no harm since it was just a hint, handle_rx() can handle
> > > > > > > > this situation.
> > > > > > Means busy polling will cause useless load on the CPU though.
> > > > > >
> > > > > Right, but,it's not easy to have 100% correct hint here. Needs more thought.
> > > > What's wrong with what we have? It polls until value changes.
> > > >
> > > But as you said, this does not mean (in mergeable cases) we have enough
> > > space to store the packet.
> > Absolutely but it checks once and then only re-checks after value
> > changes again.
> >
>
> Since get_rx_bufs() does not get enough buffers, we will wait for the kick
> in this case. For busy polling, we probably want to stay in the busy loop
> here.
That's what I'm saying. You don't want to re-poll the queue
if available idx was unchanged.
--
MST
next prev parent reply other threads:[~2016-11-15 14:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 7:38 [PATCH 1/3] tuntap: rx batching Jason Wang
2016-11-09 7:38 ` [PATCH 2/3] vhost: better detection of available buffers Jason Wang
2016-11-09 19:57 ` Michael S. Tsirkin
2016-11-11 2:18 ` Jason Wang
2016-11-11 3:41 ` Michael S. Tsirkin
2016-11-11 4:18 ` Jason Wang
2016-11-11 16:20 ` Michael S. Tsirkin
2016-11-15 3:16 ` Jason Wang
2016-11-15 3:28 ` Michael S. Tsirkin
2016-11-15 8:00 ` Jason Wang
2016-11-15 14:46 ` Michael S. Tsirkin [this message]
2016-11-09 7:38 ` [PATCH 3/3] vhost_net: tx support batching Jason Wang
2016-11-09 20:05 ` Michael S. Tsirkin
2016-11-11 2:27 ` Jason Wang
2016-11-09 16:38 ` [PATCH 1/3] tuntap: rx batching Michael S. Tsirkin
2016-11-11 2:07 ` Jason Wang
2016-11-11 3:31 ` Michael S. Tsirkin
2016-11-11 4:10 ` Jason Wang
2016-11-11 4:17 ` John Fastabend
2016-11-11 4:28 ` Jason Wang
2016-11-11 4:45 ` John Fastabend
2016-11-11 16:20 ` Michael S. Tsirkin
2016-11-15 3:14 ` Jason Wang
2016-11-15 3:41 ` Michael S. Tsirkin
2016-11-15 8:08 ` 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=20161115164620-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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.