Re: [PATCH v8 16/16] virtio_ring: introduce virtqueue_resize()

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Mar 24, 2022 at 04:34:56PM +0800, Xuan Zhuo wrote:
> On Tue, 22 Mar 2022 14:02:47 +0800, Jason Wang <jasowang@redhat.com> wrote:
> >
> > 在 2022/3/14 下午5:34, Xuan Zhuo 写道:
> > > Introduce virtqueue_resize() to implement the resize of vring.
> > > Based on these, the driver can dynamically adjust the size of the vring.
> > > For example: ethtool -G.
> > >
> > > virtqueue_resize() implements resize based on the vq reset function. In
> > > case of failure to allocate a new vring, it will give up resize and use
> > > the original vring.
> > >
> > > During this process, if the re-enable reset vq fails, the vq can no
> > > longer be used. Although the probability of this situation is not high.
> > >
> > > The parameter recycle is used to recycle the buffer that is no longer
> > > used.
> > >
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > ---
> > >   drivers/virtio/virtio_ring.c | 67 ++++++++++++++++++++++++++++++++++++
> > >   include/linux/virtio.h       |  3 ++
> > >   2 files changed, 70 insertions(+)
> > >
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index fb0abf9a2f57..b1dde086a8a4 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -2528,6 +2528,73 @@ struct virtqueue *vring_create_virtqueue(
> > >   }
> > >   EXPORT_SYMBOL_GPL(vring_create_virtqueue);
> > >
> > > +/**
> > > + * virtqueue_resize - resize the vring of vq
> > > + * @vq: the struct virtqueue we're talking about.
> > > + * @num: new ring num
> > > + * @recycle: callback for recycle the useless buffer
> > > + *
> > > + * When it is really necessary to create a new vring, it will set the current vq
> > > + * into the reset state. Then call the passed cb to recycle the buffer that is
> > > + * no longer used. Only after the new vring is successfully created, the old
> > > + * vring will be released.
> > > + *
> > > + * Caller must ensure we don't call this with other virtqueue operations
> > > + * at the same time (except where noted).
> > > + *
> > > + * Returns zero or a negative error.
> > > + * -ENOMEM: create new vring fail. But vq can still work
> > > + * -EBUSY:  reset/re-enable vq fail. vq may cannot work
> > > + * -ENOENT: not support resize
> > > + * -E2BIG/-EINVAL: param num error
> > > + */
> > > +int virtqueue_resize(struct virtqueue *vq, u32 num,
> > > +		     void (*recycle)(struct virtqueue *vq, void *buf))
> > > +{
> > > +	struct virtio_device *vdev = vq->vdev;
> > > +	void *buf;
> > > +	int err;
> > > +
> > > +	if (num > vq->num_max)
> > > +		return -E2BIG;
> > > +
> > > +	if (!num)
> > > +		return -EINVAL;
> > > +
> > > +	if (to_vvq(vq)->packed.vring.num == num)
> > > +		return 0;
> >
> >
> > Any reason we need to check a packed specific attribute here?
> 
> This is a mistake. Sorry for this.
> 
> >
> >
> > > +
> > > +	if (!vq->vdev->config->reset_vq)
> > > +		return -ENOENT;
> > > +
> > > +	if (!vq->vdev->config->enable_reset_vq)
> > > +		return -ENOENT;
> > > +
> > > +	err = vq->vdev->config->reset_vq(vq);
> > > +	if (err) {
> > > +		if (err != -ENOENT)
> > > +			err = -EBUSY;
> > > +		return err;
> > > +	}
> > > +
> > > +	while ((buf = virtqueue_detach_unused_buf(vq)) != NULL)
> > > +		recycle(vq, buf);
> > > +
> > > +	if (virtio_has_feature(vdev, VIRTIO_F_RING_PACKED))
> > > +		err = virtqueue_resize_packed(vq, num);
> > > +	else
> > > +		err = virtqueue_resize_split(vq, num);
> > > +
> > > +	if (err)
> > > +		err = -ENOMEM;
> >
> >
> > So this assumes that the -ENOMEM is the only possible error value for
> > virtqueue_resize_xxx(). Is this true? (E.g wrong size)
> 
> Yes, I want the user to know at which step the error is returned.
> 
> >
> >
> > > +
> > > +	if (vq->vdev->config->enable_reset_vq(vq))
> > > +		return -EBUSY;
> > > +
> > > +	return err;
> > > +}
> > > +EXPORT_SYMBOL_GPL(virtqueue_resize);
> > > +
> > >   /* Only available for split ring */
> > >   struct virtqueue *vring_new_virtqueue(unsigned int index,
> > >   				      unsigned int num,
> > > diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> > > index d59adc4be068..c86ff02e0ca0 100644
> > > --- a/include/linux/virtio.h
> > > +++ b/include/linux/virtio.h
> > > @@ -91,6 +91,9 @@ dma_addr_t virtqueue_get_desc_addr(struct virtqueue *vq);
> > >   dma_addr_t virtqueue_get_avail_addr(struct virtqueue *vq);
> > >   dma_addr_t virtqueue_get_used_addr(struct virtqueue *vq);
> > >
> > > +int virtqueue_resize(struct virtqueue *vq, u32 num,
> > > +		     void (*recycle)(struct virtqueue *vq, void *buf));
> >
> >
> > I wonder what's the advantages of coupling virtqueue_reset in
> > virtqueue_resize().
> 
> This is Michael's comment on the previous version
> 
> >
> > It looks to me it wold be more flexible to let the driver do:
> >
> > rest()
> >
> > detach()
> >
> > resize()
> >
> > enable_reset()
> >
> > One reason is that in the future we may want to add more functionality
> > e.g switching PASID during virtqueue reset.
> 
> Michael, from Jason Wang's plan, should we go back to the original 4 api model?
> 
> Thanks.


Jason, I feel a single api is preferable, because the need to do reset
as part of resize is an implementation detail, I can easily
imagine virtio spec being extended with a resize interface
which does not require a queue reset.

Makes sense to you?

> 
> >
> > Thanks
> >
> >
> > > +
> > >   /**
> > >    * virtio_device - representation of a device using virtio
> > >    * @index: unique position on the virtio bus
> >

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization