From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id F0143201 for ; Fri, 24 Nov 2017 22:07:40 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B941859FA; Fri, 24 Nov 2017 21:07:40 +0000 (UTC) Received: from redhat.com (ovpn-120-80.rdu2.redhat.com [10.10.120.80]) by smtp.corp.redhat.com (Postfix) with SMTP id E62805D9CB; Fri, 24 Nov 2017 21:07:36 +0000 (UTC) Date: Fri, 24 Nov 2017 23:07:36 +0200 From: "Michael S. Tsirkin" To: "Gonglei (Arei)" Cc: Jason Wang , "n.nikolaev@virtualopensystems.com" , "qemu-devel@nongnu.org" , "dev@dpdk.org" , Fanhenglong , "Lianxueguo (Albert)" , "wangxin (U)" , "Huangweidong (C)" Message-ID: <20171124230416-mutt-send-email-mst@kernel.org> References: <33183CC9F5247A488A2544077AF19020DA4A4429@DGGEMA505-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33183CC9F5247A488A2544077AF19020DA4A4429@DGGEMA505-MBS.china.huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 24 Nov 2017 21:07:40 +0000 (UTC) Subject: Re: [dpdk-dev] [Questions] about the VHOST_MEMORY_MAX_NREGIONS of vhost-user backend? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 21:07:41 -0000 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 > 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 > Signed-off-by: Nikolay Nikolaev > Reviewed-by: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin > > > Thanks, > -Gonglei >