Re: [dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.