Re: [Qemu-devel] [PATCH 0/4] vhost-user: protocol updates

[Flavio Leitner]

On Fri, Jul 17, 2015 at 05:09:26PM +0300, Michael S. Tsirkin wrote:
> This patchset sets the stage for extending the vhost user
> protocol, with full backwards compatibility.
> 
> The approach is to negotiate feature bits queried and
> acknowledged during device setup.
> 
> For now, there's no new functionality: two new messages
> are added that will allow negotiating new messages
> required for functionality such as MQ and migration.
> 
> For now, I used the feature bit 30 to signal support for these new messages,
> and we now have 64 more bits to play.
> 
> The patches can be found in my tree, branch vhost-user.
> 
> Only patch 1 is intended for 2.4.
> 
> Posting early so people working on extensions such as
> migration can review this - but please note
> the protocol is not set in stone yet.
> 
> Michael S. Tsirkin (4):
>   Revert "vhost-user: add multi queue support"
>   vhost-user: refactor ioctl translation
>   vhost-user: add protocol feature negotiation
>   vhost-user: unit test for new messages
> 
>  qapi-schema.json          |   6 +-
>  include/hw/virtio/vhost.h |   1 +
>  hw/net/vhost_net.c        |   5 +-
>  hw/virtio/vhost-user.c    | 150 
> ++++++++++++++++++++++++++++++----------------
>  net/vhost-user.c          |  37 ++++--------
>  tests/vhost-user-test.c   |  19 ++++++
>  docs/specs/vhost-user.txt |  40 +++++++++++--
>  qemu-options.hx           |   5 +-
>  8 files changed, 174 insertions(+), 89 deletions(-)
> 
> -- 
> MST
> 

The libvirt.org seems to be out so I can't check if the first
patch in the series reverting the mq support can be done.

The refactoring looks good.

Regarding to the protocol feature bits, it is nice because gives
flexibility so that master and slave can negotiate a common set
of features.  But it creates a matrix of possibilities that it
might be hard to maintain/test in the long term (64 possible
features and probably the last bit indicating another set of
64 bits, etc..)

Perhaps when this becomes a real problem one option could be that
we move some extensions to have mandatory support in the next 
protocol version. Doing so, would keep the matrix of extensions
under control.

Thanks,
fbl