On 7/25/26 10:32, Michael S. Tsirkin wrote:
On Thu, Jul 16, 2026 at 12:30:33PM +0500, Alexandr Moshkov wrote:
Ping :)
Thanks for reply!
I don't know what to do with this one. IIUC in flight migration is in 11.0
so I doubt we can just introduce new messages without a protocol flag.
The original plan was to push this series before the 11.0 release, using
the existing VHOST_USER_PROTOCOL_F_GET_VRING_BASE_INFLIGHT flag - since
the new message is a direct extension of that feature.
Now I agree that we need a separate protocol feature flag (like
VHOST_USER_PROTOCOL_F_GET_VRING_BASE_SKIP_DRAIN) for new
GET_VRING_BASE_SKIP_DRAIN message.
It says fix compatibility but really it's a feature, right?
I called it a "fix" because I saw missing migration compatibility as a
deficiency, but from protocol perspective its more like "feature" -
you're right. I'll update the subject.
And this is somehow related to GET_BASE?
Yes, GET_VRING_BASE_SKIP_DRAIN is a variant of GET_VRING_BASE - it stops
the vring the same way, but tells the backend to immediately suspend
in-flight I/O, rather than wait for it to complete.
Half the commits here have no or a single line of comment, those that
do, repeat what the commit does instead of explaining why.
That's not how it should be.
Here's a good template to use:
Currently .... This is a problem because ... We can not do .... because
... To address .... And then ....
Agreed, the descriptions are poor. I'll rewrite them following your
template. Thanks!
HTH
