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.