Re: [Qemu-devel] [virtio-dev] Re: [virtio-dev] Re: [virtio-dev] Re: [PATCH v1] virtio-net: enable configurable tx queue size

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

On Fri, Jun 16, 2017 at 06:10:27PM +0800, Wei Wang wrote:
> On 06/16/2017 04:57 PM, Jason Wang wrote:
> > 
> > 
> > On 2017年06月16日 11:22, Michael S. Tsirkin wrote:
> > > > I think the issues can be solved by VIRTIO_F_MAX_CHAIN_SIZE.
> > > > 
> > > > For now, how about splitting it into two series of patches:
> > > > 1) enable 1024 tx queue size for vhost-user, to let the users of
> > > > vhost-user
> > > > to easily use 1024 queue size.
> > > Fine with me. 1) will get property from user but override it on
> > > !vhost-user. Do we need a protocol flag? It seems prudent but we get
> > > back to cross-version migration issues that are still pending solution.
> What do you have in mind about the protocol flag?

Merely this: older clients might be confused if they get
a s/g with 1024 entries.

> Btw, I just tested the patch of 1), and it works fine with migration from
> the
> patched to non-patched version of QEMU. I'll send it out. Please have a
> check.
> 
> 
> > > Marc Andre, what's the status of that work?
> > > 
> > > > 2) enable VIRTIO_F_MAX_CHAIN_SIZE,  to enhance robustness.
> > > Rather, to support it for more backends.
> > 
> > Ok, if we want to support different values of max chain size in the
> > future. It would be problematic for migration of cross backends,
> > consider the case when migrating from 2048 (vhost-user) to 1024
> > (qemu/vhost-kernel).
> > 
> 
> I think that wouldn't be a problem. If there is a possibility to change the
> backend resulting in a change of config.max_change_size, a configuration
> change notification can be injected to the guest, then guest will read and
> get the new value.
> 
> Best,
> Wei

This might not be supportable by all guests. E.g. some requests might
already be in the queue. I'm not against reconfiguring devices across
migration but I think it's a big project. As a 1st step I would focus on
keeping configuration consistent across migrations.

-- 
MST