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