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

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

On Tue, Oct 12, 2021 at 11:09 PM Dmitry Kozlyuk <dkozlyuk@nvidia.com> wrote:
> > From this, I see two parts in this patch:
> > - faster restart, reusing hugepage files as is (combination of not calling
> > unlink() and doing "clear on alloc"),
> >   This part is interesting, and I think a single knob for this would be
> > enough.
>
> In combination with rte_extmem* API this know would indeed allow to implement the feature in the app. However, the drawback is that all the logic to select hugepage size, NUMA, and names would need to be done from the app, probably with its own options. OTOH, there is already hugetlbfs and numactl to avoid apps duplicating this logic. Also, it's not only the fast restart, but also the fast initial start on a prepared system.

How do you "prepare" a system?


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

Thanks.

-- 
David Marchand