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 at entry=0x7fffe51e6000, heap=0x7ffff7fe5a1c, > ms=ms at entry=0x7ffff7fb301c, size=size at 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 at entry=0x7fffe51e6000, heap=0x7ffff7fe5a1c, > ms=ms at entry=0x7ffff7fb301c, size=size at 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=<optimized out>) 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 at entry=11, argv=argv at > 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 > >
