From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 47C118E72 for ; Tue, 12 Jan 2016 14:39:18 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 12 Jan 2016 05:39:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,557,1444719600"; d="scan'208";a="725394302" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.28]) ([10.237.221.28]) by orsmga003.jf.intel.com with ESMTP; 12 Jan 2016 05:39:13 -0800 To: Pavel Fedin 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> <00e201d14d2b$77e03590$67a0a0b0$@samsung.com> <5694E46F.20508@intel.com> <00e601d14d30$f9ebbc80$edc33580$@samsung.com> From: Sergio Gonzalez Monroy Message-ID: <56950200.7070604@intel.com> Date: Tue, 12 Jan 2016 13:39:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <00e601d14d30$f9ebbc80$edc33580$@samsung.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 13:39:18 -0000 On 12/01/2016 12:01, Pavel Fedin wrote: > Hello! > >>> .repeated depends on CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS. By the way, looks like it does >> the same thing as you are trying to do with --single-file, but with hugepages, doesn't it? I >> see it's currently used by ivshmem (which is AFAIK very immature and half-abandoned). >> >> Similar but not the same. >> --single-file: a single file for all mapped hugepages. >> SINGLE_FILE_SEGMENTS: a file per set of physically contiguous mapped >> hugepages (what DPDK calls memseg , memory segment). So there could be >> more than one file. > Thank you for the explanation. > > By this time, i've done more testing. Current patchset breaks --no-huge. I did not study why: > --- cut --- > Program received signal SIGBUS, Bus error. > malloc_elem_init (elem=elem@entry=0x7fffe51e6000, heap=0x7ffff7fe5a1c, ms=ms@entry=0x7ffff7fb301c, size=size@entry=268435392) at /home/p.fedin/dpdk/lib/librte_eal/common/malloc_elem.c:62 > 62 /home/p.fedin/dpdk/lib/librte_eal/common/malloc_elem.c: No such file or directory. > Missing separate debuginfos, use: dnf debuginfo-install keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.13.2-11.fc23.x86_64 libcap-ng-0.7.7-2.fc23.x86_64 libcom_err-1.42.13-3.fc23.x86_64 libselinux-2.4-4.fc23.x86_64 openssl-libs-1.0.2d-2.fc23.x86_64 pcre-8.37-4.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64 > (gdb) where > #0 malloc_elem_init (elem=elem@entry=0x7fffe51e6000, heap=0x7ffff7fe5a1c, ms=ms@entry=0x7ffff7fb301c, size=size@entry=268435392) > at /home/p.fedin/dpdk/lib/librte_eal/common/malloc_elem.c:62 > #1 0x00000000004a50b5 in malloc_heap_add_memseg (ms=0x7ffff7fb301c, heap=) at /home/p.fedin/dpdk/lib/librte_eal/common/malloc_heap.c:109 > #2 rte_eal_malloc_heap_init () at /home/p.fedin/dpdk/lib/librte_eal/common/malloc_heap.c:232 > #3 0x00000000004be896 in rte_eal_memzone_init () at /home/p.fedin/dpdk/lib/librte_eal/common/eal_common_memzone.c:427 > #4 0x000000000042ab02 in rte_eal_init (argc=argc@entry=11, argv=argv@entry=0x7fffffffeb80) at /home/p.fedin/dpdk/lib/librte_eal/linuxapp/eal/eal.c:799 > #5 0x000000000066dfb9 in dpdk_init (argc=11, argv=0x7fffffffeb80) at lib/netdev-dpdk.c:2192 > #6 0x000000000040ddd9 in main (argc=12, argv=0x7fffffffeb78) at vswitchd/ovs-vswitchd.c:74 > --- cut --- > > And now i tend to think that we do not need --single-file at all. Because: > a) It's just a temporary workaround for "more than 8 regions" problem. > b) It's not compatible with physical hardware anyway. That's a good summary. I think --single-file was mostly solving the limit of vhost only mapping 8 fds. We end up with a single memseg as we do with --no-huge except that they are hugepages (well, also in this patch mapped with shared instead of private). Also, It would be compatible with physical hardware if using iommu and vfio. Sergio > So i think that we could easily use "--no-huge --shared-mem" combination. We could address hugepages compatibility problem later. > > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > >