Allow `Master` to set flags in the header about vhost

[sboeuf]

@jiangliu any idea how you expect this to be handled?

I was thinking we could extend the Master structure with an extra method set_flags, set the flags for MasterInternal (which would have a new field).
Then we need to make new_request_header() a method of MasterInternal, so that we could provide the proper flags when the header is created with VhostUserMsgHeader::new().

WDYT?

[jiangliu]

There's one issue here, according to the spec:
VHOST_USER_PROTOCOL_F_REPLY_ACK
The original vhost-user specification only demands replies for certain commands. This differs from the vhost protocol implementation where commands are sent over an ioctl() call and block until the client has completed.

With this protocol extension negotiated, the sender (QEMU) can set the need_reply [Bit 3] flag to any command. This indicates that the client MUST respond with a Payload VhostUserMsg indicating success or failure. The payload should be set to zero on success or non-zero on failure, unless the message already has an explicit reply body.

So the NEED_REPLY flag is per message instead of per connection. If we implement it as per connection, the code change will not be trivial. But if we implement as per connection, that doesn't follow the spec too. Not sure how qemu makes use of the flag.

[sboeuf]

@jiangliu

So the NEED_REPLY flag is per message instead of per connection. If we implement it as per connection, the code change will not be trivial. But if we implement as per connection, that doesn't follow the spec too. Not sure how qemu makes use of the flag.

I agree you should be able to enable it on a per message basis instead of a per connection one. In practice, I think you either want your connection to be synchronized or you don't, but I still agree we should follow the spec.
I think the approach I've described can provide a simple way of achieving this, since you could call into the set_flags() method before you issue a new command. That means each time you invoke a command, it will evaluate what's in MasterInternal.
That's the less intrusive way of implementing this whole thing, otherwise you would have to modify all the existing functions (hence breaking the API), by adding a flags parameter to all of them.

About QEMU, unless I'm mistaken, I don't think it handles this feature.

[jiangliu]

Sounds like a plan.