On Wed, Jan 15, 2020 at 07:23:14PM -0800, Raphael Norwitz wrote:
> > > + error_report("The VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS protocol
> > > "
> > > + "feature is not supported when the "
> > > + "VHOST_USER_PROTOCOL_F_REPLY_ACK features has also "
> > > + "been negotiated");
> > > + return -1;
> > > + }
> > > +
> > > + if (vhost_user_write(dev, &msg, NULL, 0) < 0) {
> > > + return -1;
> > > + }
> >
> > This will send the message each time e.g. memory hotplug
> > triggers. Why not just get this value during init time?
> > Also, any way we can cut down number of round trips?
> > Can we combine this value in a single message with
> > some other stuff we are fetching on startup?
> >
>
> Agreed, sending a VHOST_USER_GET_MEMSLOTS message on every hot-add is
> unnessesary. I can think of a couple ways to get number of memslots without
> adding any additional round trips. I don’t like either of them though.`
>
> 1.
> Only 14 of the 64 bits are used in the VHOST_USER_GET_FEATURES message are
> used to store feature flags. If CONFIGURE SLOTS is enabled, we could use
> the remaining 64 - VHOST_USER_PROTOCOL_F_MAX bits to store the maximum number
> of memory slots. We would only need around 10 bits to express a reasonable
> number of slots so that still leaves room for plenty of future features with
> VHOST_USER_PROTOCOL_F_CONFIGURE_SLOTS negotiated.
>
> 2.
> We could always have it sent from the backend with an existing
> VHOST_USER_GET_*
> message in vhost_user_backend_init(). The best option I see is using the
> VHOST_USER_GET_QUEUE_NUM if the VHOST_USER_PROTOCOL_F_MQ is negotiated. This
> has
> the obvious drawback of requiring VHOST_USER_PROTOCOL_F_MQ to negotiate
> VHOST_USER_PROTOCOL_F_CONFIGURE_SOTS. I don’t see another option without such
> a
> limitation.
>
> Both (1) and (2) seem hacky. I think it’s preferable to keep the
> VHOST_USER_GET_MAX_MEM_SLOTS message but send it once on init and cache the
> response in the vhost-user struct.
>
> Do you agree?
Makes sense.