qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v2 1/2] docs: vhost-user: add in-band kick/call me


From: Johannes Berg
Subject: Re: [Qemu-devel] [RFC v2 1/2] docs: vhost-user: add in-band kick/call messages
Date: Wed, 11 Sep 2019 17:09:18 +0200
User-agent: Evolution 3.30.5 (3.30.5-1.fc29)

On Wed, 2019-09-11 at 10:07 -0400, Michael S. Tsirkin wrote:
> 
> > +  #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD        12
> > +  #define VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS 13
> 
> INFLIGHT so INBAND?

*shrug*, sure

> > +  instead of waiting for the call; however, if the protocol feature
> > +  ``VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS`` has been negotiated
> > +  it instead means the updates should be done using the messages.
> 
> Hmm I don't like this. I propose that with 
> VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS
> we just don't allow VHOST_USER_SET_VRING_CALL (if you think it's
> important to allow them, we can say that we do not require them).

You can't actually skip SET_VRING_CALL, it's necessary to start a vring,
so libvhost-user for example calls dev->iface->queue_set_started() only
in this case. The docs in the "Starting and stopping rings" section also
explain this.

> But it's important for performance to be able to enable polling.

I don't think if you enable this you care about performance, after all
the whole point of it is to get REPLY_ACK for the in-band message.

> > +  When the ``VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS`` protocol
> > +  feature has been successfully negotiated, this message may be
> > +  submitted by the master to indicate that a buffer was added to
> > +  the vring instead of signalling it using the vring's event FD or
> 
> event -> kick?
> fd -> file descriptor

Sure.

> > +  having the slave rely on polling.
> 
> i think polling is a separate option and should be there with inband
> kicks.

See above. But I guess we could put a flag into bit 9 indicating that
you want to use messages instead of polling or a file descriptor, if you
prefer.

> > +``VHOST_USER_SLAVE_VRING_CALL``
> > +  :id: 4
> > +  :equivalent ioctl: N/A
> > +  :slave payload: vring state description
> > +  :master payload: N/A
> > +
> > +  When the ``VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS`` protocol
> > +  feature has been successfully negotiated, this message may be
> > +  submitted by the slave to indicate that a buffer was used from
> > +  the vring instead of signalling this using the vring's kick FD or
> > +  having the master relying on polling.
> 
> call FD?

I confused this far too many times and thought I got it right finally,
but yes, you're right.

johannes




reply via email to

[Prev in Thread] Current Thread [Next in Thread]