From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id E8412591A for ; Tue, 12 Jan 2016 11:04:08 +0100 (CET) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O0U002J83YVSL70@mailout1.w1.samsung.com> for dev@dpdk.org; Tue, 12 Jan 2016 10:04:07 +0000 (GMT) X-AuditID: cbfec7f4-f79026d00000418a-62-5694cf977562 Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 39.66.16778.79FC4965; Tue, 12 Jan 2016 10:04:07 +0000 (GMT) Received: from fedinw7x64 ([106.109.131.169]) by eusync1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O0U00IZL3YS9U80@eusync1.samsung.com>; Tue, 12 Jan 2016 10:04:07 +0000 (GMT) From: Pavel Fedin To: "'Tan, Jianfeng'" , 'Rich Lane' References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-3-git-send-email-jianfeng.tan@intel.com> <5694C36D.2040006@intel.com> In-reply-to: <5694C36D.2040006@intel.com> Date: Tue, 12 Jan 2016 13:04:04 +0300 Message-id: <00d501d14d20$930c8ae0$b925a0a0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQLOfZuJ4skKn5NxqR5aD7duH+7e0wGBr/PNAXdZpgsCZb31fwF86PJgnMZnIhA= Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsVy+t/xy7rTz08JM1h3WMRi7ssfTBbvPm1n smifeZbJonv2FzaLv7NbWS3+/3rFanGs5xOrxaFDhxktNr2bxGpxfcIFVgcujweXbzJ5/Fqw lNWj5chbVo/G5xIei/e8ZPJofvGcxWPeyUCP9/uusgVwRHHZpKTmZJalFunbJXBlHP4VX9Ao UNE/4xB7A+Ncri5GTg4JAROJP6suMULYYhIX7q1nA7GFBJYySux6ZdXFyAVkf2eU6O96ygyS YBNQlzj99QMLiC0iEC7R8buJEaSIWWACk8SRw5tZIbqXM0m0dimC2JwCmhJ7pv8FaxAW8JC4 Nu8r2CAWAVWJ1mV/wbbxClhKXN73lQnCFpT4MfkeUD0H0FB1iSlTckHCzALaEk/eXWCFOFRB YsfZ14wQN/hJtDbvZYOoEZGY9u8e8wRGoVlIJs1CmDQLyaRZSDoWMLKsYhRNLU0uKE5KzzXU K07MLS7NS9dLzs/dxAiJsS87GBcfszrEKMDBqMTDm8E+JUyINbGsuDL3EKMEB7OSCK/dFqAQ b0piZVVqUX58UWlOavEhRmkOFiVx3rm73ocICaQnlqRmp6YWpBbBZJk4OKUaGL0V1fN447kc fuxkfrGqg1NlwUyOzvpSTqlpx1/9s6jQPsknsZ654c6sDauOZfdytHecUVx2mXNy4Ld1qX5/ WnfFMdyXu2CpJbp0o8r7u/JN176/2cav3mxU9dFwReXyhhOLY0MSt2tyX3erbji3U7XQJX5B 5dWrIvt+sxv//+3rOE1CZa9yvxJLcUaioRZzUXEiAFk7ga+tAgAA Cc: nakajima.yoshihiro@lab.ntt.co.jp, "'Michael S. Tsirkin'" , dev@dpdk.org, ann.zhuangyanying@huawei.com Subject: Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:04:09 -0000 Hello! >> Should this be "hugepage->size =3D internal_config.memory"? Otherwise = the vhost-user >> memtable entry has a size of only 2MB. > I don't think so. See the definition: > 47 struct hugepage_file { > 48 void *orig_va; /**< virtual addr of first mmap() */ > 49 void *final_va; /**< virtual addr of 2nd mmap() */ > 50 uint64_t physaddr; /**< physical addr */ > 51 size_t size; /**< the page size */ > 52 int socket_id; /**< NUMA socket ID */ > 53 int file_id; /**< the '%d' in HUGEFILE_FMT */ > 54 int memseg_id; /**< the memory segment to which page = belongs */ = =20 > 55 #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS =20 > 56 int repeated; /**< number of times the page size = is repeated */ = =20 > 57 #endif =20 > 58 char filepath[MAX_HUGEPAGE_PATH]; /**< path to backing file = on filesystem */ = =20 > 59 }; > size stands for the page size instead of total size. But in this case host gets this page size for total region size, = therefore qva_to_vva() fails. I haven't worked with hugepages, but i guess that with real hugepages = we get one file per page, therefore page size =3D=3D mapping size. With = newly introduced --single-file we now have something that pretends to be = a single "uber-huge-page", so we need to specify total size of the = mapping here. BTW, i'm still unhappy about ABI breakage here. I think we could easily = add --shared-mem option, which would simply change mapping mode to = SHARED. So, we could use it with both hugepages (default) and plain mmap = (with --no-hugepages). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia