From: "Michael S. Tsirkin" <mst@redhat.com>
To: Raphael Norwitz <raphael.norwitz@nutanix.com>
Cc: qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <20200122035639-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200116032314.GA86980@raphael-norwitz.user.nutanix.com>
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.
next prev parent reply other threads:[~2020-01-22 8:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 7:00 [RFC PATCH 0/3] vhost-user: Lift Max Ram Slots Limitation Raphael Norwitz
2019-12-09 7:00 ` [RFC PATCH 1/3] Fixed Error Handling in vhost_user_set_mem_table_postcopy Raphael Norwitz
2020-01-14 7:07 ` Michael S. Tsirkin
2020-01-16 3:16 ` Raphael Norwitz
2019-12-09 7:00 ` [RFC PATCH 2/3] vhost-user: Refactor vhost_user_set_mem_table Functions Raphael Norwitz
2019-12-09 7:00 ` [RFC PATCH 3/3] Introduce Configurable Number of Memory Slots Exposed by vhost-user: Raphael Norwitz
2020-01-14 7:12 ` Michael S. Tsirkin
2020-01-16 3:23 ` Raphael Norwitz
2020-01-22 8:57 ` Michael S. Tsirkin [this message]
2020-01-13 19:43 ` [RFC PATCH 0/3] vhost-user: Lift Max Ram Slots Limitation Raphael Norwitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200122035639-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael.norwitz@nutanix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.