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 14:37:54 +0300
Message-ID: <00e301d14d2d$ad9cb350$08d619f0$@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> <00d501d14d20$930c8ae0$b925a0a0$@samsung.com>
 <5694D9E9.6060704@intel.com> <00de01d14d28$7c2eaf80$748c0e80$@samsung.com>
 <5694DE7C.4050206@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: 'Sergio Gonzalez Monroy' <sergio.gonzalez.monroy@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com
 [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id E24B98DB3
 for <dev@dpdk.org>; Tue, 12 Jan 2016 12:37:56 +0100 (CET)
Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244])
 by mailout3.w1.samsung.com
 (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014))
 with ESMTP id <0O0U009258B7DZA0@mailout3.w1.samsung.com> for dev@dpdk.org;
 Tue, 12 Jan 2016 11:37:55 +0000 (GMT)
In-reply-to: <5694DE7C.4050206@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!

> So are you suggesting to not introduce --single-file option but =
instead
> --shared-mem?
> AFAIK --single-file was trying to workaround the limitation of just
> being able to map 8 fds.

 Heh, yes, you're right... Indeed, sorry, i was not patient enough, i =
see it uses hpi->hugedir instead of using /dev/shm... I was confused by =
the code path... It seemed that --single-file is an alias to =
--no-hugepages.
 And the patch still changes mmap() mode to SHARED unconditionally, =
which is not good in terms of backwards compability (and this is =
explicitly noticed in the cover letter).

 So, let's try to sort out...
 a) By default we should still have MAP_PRIVATE
 b) Let's say that we need --shared-mem in order to make it MAP_SHARED. =
This can be combined with --no-hugepages if necessary (this is what i =
tried to implement based on the old RFC).
 c) Let's say that --single-file uses hugetlbfs but maps everything via =
single file. This still can be combined with --shared-mem.

 wouldn't this be more clear, more straightforward and implication-free?

 And if we agree on that, we could now try to decrease number of =
options:
 a) We could imply MAP_SHARED if cvio is used, because shared memory is =
mandatory in this case.
 b) (c) above again raises a question: doesn't it make =
CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS obsolete? Or may be we could use that =
one instead of --single-file (however i'm not a fan of compile-time =
configuration like this)?

Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia