Re: [dpdk-dev] [PATCH v8 03/11] eal: introduce memory management wrappers

[Thomas Monjalon <thomas@monjalon.net>]

12/06/2020 15:44, Dmitry Kozliuk:
> > [...]
> > > +INTERNAL {
> > > +     global:
> > > +
> > > +     rte_mem_lock;
> > > +     rte_mem_map;
> > > +     rte_mem_page_size;
> > > +     rte_mem_unmap;
> > > +};
> >
> > Not sure why these functions are internal.
> > They may be useful for DPDK applications.
> > We would need to add the file in doxygen index.
> 
> Not sure if they are in DPDK scope, apart from rte_mem_lock, which
> generalizes rte_mem_lock_page already in rte_memory.h. What may be typical
> use cases for data-plane apps? I can see testpmd using mmap for allocating
> external memory (because of possible use of hugepages), does it need these
> functions exposed?

There is a chance the application needs such functions
for another part of its dataplane.

> > If we want to keep them internal, we should add a doxygen marker
> > @internal.
> 
> IIRC, it were you who proposed making them internal instead of
> experimental. And internal symbols can always be exposed later.

They they can be exposed later.
I think it's good to start internal.
Please add the @internal tag in doxygen to make the status clear.

> > > +#include <rte_eal_memory.h>
> >
> > I think we should find a better file name for these wrappers.
> > "EAL memory" means DPDK memory allocator in my mind.
> > We need a file name which is about OS-independent wrappers,
> > or libc wrappers.
> > What about rte_libc_mem.h? rte_mem_os.h? something else?
> 
> See above, but anyway, "libc" is non-generic.

Why libc is not generic?

Which file name can it be?