From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id E24B98DB3 for ; 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) X-AuditID: cbfec7f4-f79026d00000418a-f4-5694e5932d0e Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 92.27.16778.395E4965; Tue, 12 Jan 2016 11:37:55 +0000 (GMT) Received: from fedinw7x64 ([106.109.131.169]) by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O0U004UQ8B60960@eusync2.samsung.com>; Tue, 12 Jan 2016 11:37:55 +0000 (GMT) From: Pavel Fedin To: 'Sergio Gonzalez Monroy' 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> <00d501d14d20$930c8ae0$b925a0a0$@samsung.com> <5694D9E9.6060704@intel.com> <00de01d14d28$7c2eaf80$748c0e80$@samsung.com> <5694DE7C.4050206@intel.com> In-reply-to: <5694DE7C.4050206@intel.com> Date: Tue, 12 Jan 2016 14:37:54 +0300 Message-id: <00e301d14d2d$ad9cb350$08d619f0$@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/PNAXdZpgsCZb31fwF86PJgAWMsQY0CZHOBwQJHg9NpAreV4wCcgEhu8A== Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42I5/e/4Fd3JT6eEGRzukbCY+/IHk8W7T9uZ LLpnf2Gz+P/rFavFoUOHGS02vZvEarFiwhFGB3aPB5dvMnn8WrCU1aPlyFtWj8V7XjJ5NL94 zuLxft9VtgC2KC6blNSczLLUIn27BK6M+WuPMhYc56lY1+DYwNjK1cXIySEhYCJxvu89I4Qt JnHh3nq2LkYuDiGBpYwSO/7vYYVwvjNKbL7VygpSxSagLnH66wcWEFtEwF7izNupjCBFzAKX GCVaD/1hA0kICRxklvh4TQvE5hTQlNhz4wlYg7BAqMSsRSfABrEIqEosb70FVs8rYCnRuv8v E4QtKPFj8j2geg6goeoSU6bkgoSZBbQlnry7wApxqYLEjrOvGUFKRARyJKbMSoMoEZGY9u8e 8wRGoVlIBs1CGDQLyaBZSDoWMLKsYhRNLU0uKE5KzzXUK07MLS7NS9dLzs/dxAiJmi87GBcf szrEKMDBqMTDm8E+JUyINbGsuDL3EKMEB7OSCK/dFqAQb0piZVVqUX58UWlOavEhRmkOFiVx 3rm73ocICaQnlqRmp6YWpBbBZJk4OKUaGLll/hSFcG5+9z/s6J3TNp8M875KNtnovWXI4xIW lLqbv7Zqnve0UiEex8qwsykbmCcdUbTjPld2qq54r/GPbtGcjaoyN7yXvPjuxG8jO7XviOIi yZiyFPFTy4/2dHEtUPpszhXjU3gt5KDfh/jv8WvXOfzkmHjtT6zDPYXJ32qy+I9kKlcWK7EU ZyQaajEXFScCANGFVgiWAgAA 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 11:37:57 -0000 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