From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pavel Fedin <p.fedin@samsung.com>
Subject: Re: [PATCH 2/4] mem: add API to obstain memory-backed
	file info
Date: Tue, 12 Jan 2016 13:04:04 +0300
Message-ID: <00d501d14d20$930c8ae0$b925a0a0$@samsung.com>
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>
 <CAGSMBPNeAt9a3kpiJmP=zVwEhoHeBbLfe7baBq8msfitqAb6+A@mail.gmail.com>
 <5694C36D.2040006@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: nakajima.yoshihiro@lab.ntt.co.jp, "'Michael S. Tsirkin'" <mst@redhat.com>,
 dev@dpdk.org, ann.zhuangyanying@huawei.com
To: "'Tan, Jianfeng'" <jianfeng.tan@intel.com>,
 'Rich Lane' <rich.lane@bigswitch.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com
 [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id E8412591A
 for <dev@dpdk.org>; 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)
In-reply-to: <5694C36D.2040006@intel.com>
Content-language: ru
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

 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