From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mukawa@igel.co.jp>
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com
 [209.85.220.42]) by dpdk.org (Postfix) with ESMTP id B5B687F7D
 for <dev@dpdk.org>; Mon, 17 Nov 2014 07:03:48 +0100 (CET)
Received: by mail-pa0-f42.google.com with SMTP id et14so6813785pad.29
 for <dev@dpdk.org>; Sun, 16 Nov 2014 22:14:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :cc:subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=Bls3uOdMw2o12gErXUD96vsROcxVkA01Jxsgv+N0RjE=;
 b=ldN5CDluor7hLPg4V0dwip3Mp1FuyvyzE0SgwPs5pt/xm2aFzGKYMoJiGuguOSbP7N
 09tM1jlv9BAVrX2ZKGQl0/GYmG0cH7cdnLPdMbDaPQpvwN/edA3Le2q2X3UKo1jeVxM5
 ycB4fxm1vvPMSSvHkc4seVoUqMUMTWM4wzfdhELbDZYXvPabzOwGJXTEpigbaoDyaeRd
 KkNIvzJGehrlT9Nwh0XlpKHJc6YpdJv57OSyT9jHH+JiYgkd/9RezbYG6LbKXEbWiHGS
 choiFqP0nAiZpXUeYkXGbRPNdRWwC8crrxsTw297qTrxGU1cIsrkbenhp4IraLHk6DN2
 8Bmw==
X-Gm-Message-State: ALoCoQmKtW2ddAtxq2CrOklIOEf4sKYZRowfUgzmkk2D3Exi8ugsUdhDgDw7HLIqH7v96yKfe0L8
X-Received: by 10.70.94.168 with SMTP id dd8mr27278868pdb.76.1416204843316;
 Sun, 16 Nov 2014 22:14:03 -0800 (PST)
Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132])
 by mx.google.com with ESMTPSA id cc2sm33887159pbd.62.2014.11.16.22.14.01
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 16 Nov 2014 22:14:02 -0800 (PST)
Message-ID: <54699229.8010603@igel.co.jp>
Date: Mon, 17 Nov 2014 15:14:01 +0900
From: Tetsuya Mukawa <mukawa@igel.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Xie, Huawei" <huawei.xie@intel.com>
References: <C37D651A908B024F974696C65296B57B0F2F19EF@SHSMSX101.ccr.corp.intel.com>
 <5462DE39.1070006@igel.co.jp> <54645007.3010301@huawei.com>
 <54656950.1050204@igel.co.jp> <54657365.7090504@huawei.com>
 <546579A3.3010804@igel.co.jp> <54658853.2090100@huawei.com>
 <54658F55.4070409@igel.co.jp> <54659361.6000702@huawei.com>
 <5465A7C2.7080208@igel.co.jp>
 <C37D651A908B024F974696C65296B57B0F303CAA@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <C37D651A908B024F974696C65296B57B0F303CAA@SHSMSX101.ccr.corp.intel.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] vhost-user technical isssues
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Mon, 17 Nov 2014 06:03:49 -0000

Hi Xie,

(2014/11/14 19:59), Xie, Huawei wrote:
> I tested with latest qemu(with offset fix) in vhost app(not with test c=
ase), unmap succeeds only when the size is aligned to 1GB(hugepage size).=

I appreciate for your testing.

> Another important thing is  could we do mmap(0, region[i].memory_size, =
PROT_XX, mmap_offset) rather than with offset 0? With the region above 4G=
B, we will waste 4GB address space. Or we at least need to round down off=
set to nearest 1GB, and round up memory size to upper 1GB, to save some a=
ddress space waste.
>
> Anyway, this is ugly. Kernel doesn't take care of us, do those alignmen=
t for us automatically.
>

It seems 'offset' also should be aligned by hugepage size also.
But it might be a specification of mmap. Manpage of mmap says 'offset'
should be aligned by sysconf(_SC_PAGE_SIZE).
If the target file is on hugetlbfs, I guess hugepage size is used as
alignment size.

Thanks,
Tetsuya