From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by dpdk.org (Postfix) with ESMTP id 44046F04 for ; Fri, 24 Nov 2017 11:35:12 +0100 (CET) Received: from 172.30.72.57 (EHLO DGGEMA405-HUB.china.huawei.com) ([172.30.72.57]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AZH51689; Fri, 24 Nov 2017 18:35:00 +0800 (CST) Received: from DGGEMA424-HUB.china.huawei.com (10.1.198.157) by DGGEMA405-HUB.china.huawei.com (10.3.20.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 24 Nov 2017 18:28:57 +0800 Received: from DGGEMA505-MBS.china.huawei.com ([169.254.4.143]) by dggema424-hub.china.huawei.com ([10.1.198.157]) with mapi id 14.03.0361.001; Fri, 24 Nov 2017 18:28:48 +0800 From: "Gonglei (Arei)" To: "mst@redhat.com" , Jason Wang , "n.nikolaev@virtualopensystems.com" CC: "qemu-devel@nongnu.org" , "dev@dpdk.org" , Fanhenglong , "Lianxueguo (Albert)" , "wangxin (U)" , "Huangweidong (C)" Thread-Topic: [Questions] about the VHOST_MEMORY_MAX_NREGIONS of vhost-user backend? Thread-Index: AdNlDi0VIVSHCnGLSfKcP1bndDzO2w== Date: Fri, 24 Nov 2017 10:28:48 +0000 Message-ID: <33183CC9F5247A488A2544077AF19020DA4A4429@DGGEMA505-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.18.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.5A17F5D5.01F4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.143, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ca6b071b482a043d33f82a3ab8350852 Subject: [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 10:35:14 -0000 Hi, Currently, the maximum number of supported memory regions for vhost-user ba= ckends is 8,=20 and the maximum supported memory regions for vhost-net backends is determin= ed by=20 " /sys/module/vhost/parameters/max_mem_regions".=20 In many scenarios, the vhost-user NIC will cause the memory region to becom= e a bottleneck, reports "a used vhost backend has no free memory slots left".=20 Such as memory hotplug (need to support multiple memory slots),=20 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 u= p to 8? Does it have any side effects if we increase the VHOST_MEMORY_MAX_NREGIONS?= =20 What about cross-version migration? #define VHOST_MEMORY_MAX_NREGIONS 8 static int vhost_user_memslots_limit(struct vhost_dev *dev) { return VHOST_MEMORY_MAX_NREGIONS; } Which is introduced by=20 commit 5f6f6664bf24dc53f4bf98ba812d55ca93684cd5 Author: Nikolay Nikolaev Date: Tue May 27 15:06:02 2014 +0300 Add vhost-user as a vhost backend. =20 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. =20 Each ioctl request of vhost-kernel has a vhost-user message equivalent, which is sent over the control socket. =20 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. =20 VHOST_SET_MEM_TABLE ignores the supplied vhost_memory structure and sca= ns the global ram_list for ram blocks with a valid fd field set. This woul= d be set when the '-object memory-file' option with share=3Don property i= s used. =20 Signed-off-by: Antonios Motakis Signed-off-by: Nikolay Nikolaev Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Thanks, -Gonglei