All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>
Cc: Jason Wang <jasowang@redhat.com>,
	"n.nikolaev@virtualopensystems.com"
	<n.nikolaev@virtualopensystems.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Fanhenglong <fanhenglong@huawei.com>,
	"Lianxueguo (Albert)" <lianxueguo@huawei.com>,
	"wangxin (U)" <wangxinxin.wang@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>
Subject: Re: [Questions] about the VHOST_MEMORY_MAX_NREGIONS of vhost-user backend?
Date: Fri, 24 Nov 2017 23:07:36 +0200	[thread overview]
Message-ID: <20171124230416-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020DA4A4429@DGGEMA505-MBS.china.huawei.com>

On Fri, Nov 24, 2017 at 10:28:48AM +0000, Gonglei (Arei) wrote:
> Hi,
> 
> Currently, the maximum number of supported memory regions for vhost-user backends is 8, 
> and the maximum supported memory regions for vhost-net backends is determined by 
> " /sys/module/vhost/parameters/max_mem_regions". 
> 
> In many scenarios, the vhost-user NIC will cause the memory region to become a bottleneck, reports
>  "a used vhost backend has no free memory slots left". 
> 
> Such as memory hotplug (need to support multiple memory slots), 
> and GPU pass-through (need to register multiple bar regions) and so on.
> 
> So, my questions are: Why definition vhost-user memory card memory region up to 8?
> Does it have any side effects if we increase the VHOST_MEMORY_MAX_NREGIONS? 
> What about cross-version migration?
> 
> #define VHOST_MEMORY_MAX_NREGIONS    8

I think we can extend it with a protocol flag.


> static int vhost_user_memslots_limit(struct vhost_dev *dev)
> {
>     return VHOST_MEMORY_MAX_NREGIONS;
> }
> 
> Which is introduced by 
> commit 5f6f6664bf24dc53f4bf98ba812d55ca93684cd5
> Author: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
> Date:   Tue May 27 15:06:02 2014 +0300
> 
>     Add vhost-user as a vhost backend.
>     
>     The initialization takes a chardev backed by a unix domain socket.
>     It should implement qemu_fe_set_msgfds in order to be able to pass
>     file descriptors to the remote process.
>     
>     Each ioctl request of vhost-kernel has a vhost-user message equivalent,
>     which is sent over the control socket.
>     
>     The general approach is to copy the data from the supplied argument
>     pointer to a designated field in the message. If a file descriptor is
>     to be passed it will be placed in the fds array for inclusion in
>     the sendmsg control header.
>     
>     VHOST_SET_MEM_TABLE ignores the supplied vhost_memory structure and scans
>     the global ram_list for ram blocks with a valid fd field set. This would
>     be set when the '-object memory-file' option with share=on property is used.
>     
>     Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
>     Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
>     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> 
> Thanks,
> -Gonglei
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>
Cc: Jason Wang <jasowang@redhat.com>,
	"n.nikolaev@virtualopensystems.com"
	<n.nikolaev@virtualopensystems.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Fanhenglong <fanhenglong@huawei.com>,
	"Lianxueguo (Albert)" <lianxueguo@huawei.com>,
	"wangxin (U)" <wangxinxin.wang@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>
Subject: Re: [Qemu-devel] [Questions] about the VHOST_MEMORY_MAX_NREGIONS of vhost-user backend?
Date: Fri, 24 Nov 2017 23:07:36 +0200	[thread overview]
Message-ID: <20171124230416-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020DA4A4429@DGGEMA505-MBS.china.huawei.com>

On Fri, Nov 24, 2017 at 10:28:48AM +0000, Gonglei (Arei) wrote:
> Hi,
> 
> Currently, the maximum number of supported memory regions for vhost-user backends is 8, 
> and the maximum supported memory regions for vhost-net backends is determined by 
> " /sys/module/vhost/parameters/max_mem_regions". 
> 
> In many scenarios, the vhost-user NIC will cause the memory region to become a bottleneck, reports
>  "a used vhost backend has no free memory slots left". 
> 
> Such as memory hotplug (need to support multiple memory slots), 
> and GPU pass-through (need to register multiple bar regions) and so on.
> 
> So, my questions are: Why definition vhost-user memory card memory region up to 8?
> Does it have any side effects if we increase the VHOST_MEMORY_MAX_NREGIONS? 
> What about cross-version migration?
> 
> #define VHOST_MEMORY_MAX_NREGIONS    8

I think we can extend it with a protocol flag.


> static int vhost_user_memslots_limit(struct vhost_dev *dev)
> {
>     return VHOST_MEMORY_MAX_NREGIONS;
> }
> 
> Which is introduced by 
> commit 5f6f6664bf24dc53f4bf98ba812d55ca93684cd5
> Author: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
> Date:   Tue May 27 15:06:02 2014 +0300
> 
>     Add vhost-user as a vhost backend.
>     
>     The initialization takes a chardev backed by a unix domain socket.
>     It should implement qemu_fe_set_msgfds in order to be able to pass
>     file descriptors to the remote process.
>     
>     Each ioctl request of vhost-kernel has a vhost-user message equivalent,
>     which is sent over the control socket.
>     
>     The general approach is to copy the data from the supplied argument
>     pointer to a designated field in the message. If a file descriptor is
>     to be passed it will be placed in the fds array for inclusion in
>     the sendmsg control header.
>     
>     VHOST_SET_MEM_TABLE ignores the supplied vhost_memory structure and scans
>     the global ram_list for ram blocks with a valid fd field set. This would
>     be set when the '-object memory-file' option with share=on property is used.
>     
>     Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
>     Signed-off-by: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
>     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> 
> Thanks,
> -Gonglei
> 

  reply	other threads:[~2017-11-24 21:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 10:28 [Questions] about the VHOST_MEMORY_MAX_NREGIONS of vhost-user backend? Gonglei (Arei)
2017-11-24 10:28 ` [Qemu-devel] " Gonglei (Arei)
2017-11-24 21:07 ` Michael S. Tsirkin [this message]
2017-11-24 21:07   ` Michael S. Tsirkin

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=20171124230416-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=dev@dpdk.org \
    --cc=fanhenglong@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=lianxueguo@huawei.com \
    --cc=n.nikolaev@virtualopensystems.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wangxinxin.wang@huawei.com \
    --cc=weidong.huang@huawei.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.