Re: [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files

[Dmitry Kozlyuk <dkozlyuk@nvidia.com>]

Hi David,

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
[...]
> > > - finegrained control of hugepage files, but it has the drawback of
> > > imposing primary/secondary run with the same options.
> > >   The second part seems complex to configure. I see conflicts with
> > > existing options, so it seems a good way to get caught up in the
> > > carpet (sorry if it translates badly from French :p).
> >
> > I don't see why synchronizing memory options is a big issue.
> 
> We have too many options for the memory subsystem.
> 
> I mentionned --socket-mem, --huge-dir, --file-prefix.
> But there is also --huge-unlink, --no-shconf, --in-memory, --legacy-mem, -
> -single-file-segments, --match-allocations and --socket-limit.
> Some of those do part of the job, others are incompatible with this new
> option and probably some are orthogonal.
> 
> Sure we can add a new one that prepare your toasts, coffee and wake up the
> kids (that's progress!).
>
> Maybe you can provide an example on how this is used?

Sorry for the late reply.

After more consideration offline with Thomas
we concluded that the --mem-file option is indeed too intrusive.
I'm going to propose a new solution for the slow restart issue for 22.02,
probably with a knob like you proposed,
only not just changing when the memory is zeroed,
but most importantly allowing EAL to reuse hugepages.
So that in the end the usage would be as follows,
and if it's a restart, memory clearing would be bypassed:

	./dpdk-app --huge-reuse -- ...

Refactoring and benchmark patches may still be useful,
so review efforts were hopefully not in vain.
Thank you for asking the right questions!

FWIW, I agree that memory options should be cleaned up independently.