qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC PATCH 3/3] Introduce Configurable Number of Memory Slots Expose


From: Michael S. Tsirkin
Subject: Re: [RFC PATCH 3/3] Introduce Configurable Number of Memory Slots Exposed by vhost-user:
Date: Wed, 22 Jan 2020 03:57:06 -0500

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.




reply via email to

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