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
