[dpdk-dev] [PATCH v9 03/12] eal: introduce memory management wrappers

[Dmitry Kozlyuk]

On Mon, 15 Jun 2020 06:53:45 -0400
Neil Horman <nhorman at tuxdriver.com> wrote:

> On Mon, Jun 15, 2020 at 10:41:20AM +0300, Dmitry Kozlyuk wrote:
> > On Mon, 15 Jun 2020 07:03:23 +0100
> > "Kinsella, Ray" <mdr at ashroe.eu> wrote:
> > 
> > [snip]  
> > > > +
> > > > +INTERNAL {
> > > > +	global:
> > > > +
> > > > +	rte_mem_lock;
> > > > +	rte_mem_map;
> > > > +	rte_mem_page_size;
> > > > +	rte_mem_unmap;
> > > > +};    
> > > 
> > > Don't
> > > 
> > > * eal_mem_reserve()
> > > * eal_mem_free()
> > > * eal_mem_set_dump()
> > > 
> > > Belong in the map file also?  
> > 
> > No need to export these funtions, they're only used by librte_eal.
> >   
> But theres lots of locations in dpdk that could be using these functions.  I
> count 57 calls sites in dpdk for sysconf(SC_PAGESIZE), spread throughout the
> library collection, as well as some others for sysconf(_SC_IOV_MAX) and
> sysconf(_SC_NPROCESSORS_CONF).  If the goal is to abstract away the use of
> sysconf in dpdk, you probably at least want to export rte_mem_page_size.
> 
> the same is likely true for mmap/munmap

My comment (and Ray's one, I believe) was about eal_mem_*() functions. Those
you're talking about, rte_mem_*(), are exported from EAL, but only visible to
DPDK. Everything above is true, sysconf(), etc. can be replaced as the need
arises to make the calling code OS-agnostic.

-- 
Dmitry Kozlyuk