On Wed, May 04, 2011 at 11:00:23PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 04, 2011 at 05:50:19PM +0300, Michael S. Tsirkin wrote:
> > > @@ -185,11 +193,6 @@ int virtqueue_add_buf_gfp(struct virtque
> > > if (vq->num_free < out + in) {
> > > pr_debug("Can't add buf len %i - avail = %i\n",
> > > out + in, vq->num_free);
> > > - /* FIXME: for historical reasons, we force a notify here if
> > > - * there are outgoing parts to the buffer. Presumably the
> > > - * host should service the ring ASAP. */
> > > - if (out)
> > > - vq->notify(&vq->vq);
> > > END_USE(vq);
> > > return -ENOSPC;
> > > }
> >
> > This will break qemu versions 0.13 and back.
> > I'm adding some new virtio ring flags, we'll be
> > able to reuse one of these to mean 'no need for
> > work around', I think.
>
> Not really, it wont. We shall almost never get here at all.
> But then, why would this help performance?
I think I understand this finally.
By itself, this patch does not help performance and does not
hurt it. But later patch makes us try to xmit and fail there
instead of doing capacity checks. With *that* patch applied
on top of this one, and with qemu 0.13 and older, performance
will be hurt.
We need to either
- ignore these older hosts
- add a feature bit (or use one of the new ones I added: for example
with avail_event userspace never needs this behaviour as it can
ask to get events when ring gets full)
- keep doing capacity checks, which will make us almost never get here
> > --
> > MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
