2016-06-10 12:08, Burakov, Anatoly: > Hi Thomas, > > > 2016-06-10 09:47, Burakov, Anatoly: > > > > > > The last step of the ivshmem cleanup will be to remove the > > > > > > memory hack RTE_EAL_SINGLE_FILE_SEGMENTS. Then > > > > > > CONFIG_RTE_LIBRTE_IVSHMEM could be removed. > > > > > > > > > > The reason for that hack is that we often need to map several > > > > > hugepages, > > > > and some of those pages could be 2M in size. If you're sharing 1G > > > > worth of contiguous memory backed by 2M pages, that's 512 files in > > > > the command line in vanilla DPDK, but can be made into one with > > > > RTE_EAL_SINGLE_FILE_SEGMENTS, so that QEMU command-line doesn't > > get > > > > overly long. > > > > > > > > > > So removing this hack, while definitely desired, will adversely > > > > > affect some use cases, such as using IVSHMEM on platforms where 1G > > > > > pages aren't supported. Whether we want to go with the effort of > > > > > supporting those is of course an open question - I personally > > > > > don't have any data on IVSHMEM userbase. Maybe Kevin/other OVS > > > > > devs could help me out > > > > here > > > > > :) > > > > > > > > We can keep supporting 2M pages by having a command line option, > > > > instead of the #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS. > > > > But as I said, it is not the top priority to remove this hack. > > > > > > Ah, so you're not suggesting removing the _functionality_, just the > > > #ifdef? > > That could be made to work I guess... > > > > > > Also, please correct me if I'm wrong, but I seem to remember some > > patches about putting all memory in a single file - I think that should > > work for > > IVSHMEM as well, because I believe IVSHMEM handles holes in files just fine, > > and can map even if everything resides inside a single file. So if that > > patch > > does what I think it does, we might just integrate it and remove the single > > file > > segments code entirely. > > > > Yes it can be considered in a memory allocator rework. > > Please jump in this thread: > > http://dpdk.org/ml/archives/dev/2016-April/037444.html > > I've read through that thread, and I don't think anything should be done to > support that in IVSHMEM. IVSHMEM library should correctly detect all mapped > files, whatever the memory layout on the host side (contiguous, > noncontiguous, single file...). On the guest, we're simply adding memzones > which we map from a PCI device, so IVSHMEM shouldn't be affected by any > changes to how memzones/mempools are allocated (mempools aren't even allowed > for use with IVSHMEM).
You misunderstood me. I was talking about a rework of RTE_EAL_SINGLE_FILE_SEGMENTS. I just say it must be reworked and it can happen in the discussion of a global rework of the memory allocator. It should not be related to IVSHMEM.
