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

[David Marchand <david.marchand@redhat.com>]

On Mon, Nov 8, 2021 at 3:27 PM Dmitry Kozlyuk <dkozlyuk@nvidia.com> wrote:
>
> 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.

No problem.

>
> 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.

Looking forward to 22.02 :-).
Thanks Dmitry.


-- 
David Marchand