From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 017C4A00BE;
	Fri, 12 Jun 2020 16:04:54 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 61A291BF5C;
	Fri, 12 Jun 2020 16:04:54 +0200 (CEST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 069E61BF5C
 for <dev@dpdk.org>; Fri, 12 Jun 2020 16:04:52 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
 by mailout.nyi.internal (Postfix) with ESMTP id 56C225C0198;
 Fri, 12 Jun 2020 10:04:52 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Fri, 12 Jun 2020 10:04:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm1; bh=
 tJcY4zuKVRcW2QJ3kR5SiCgdeAzE6eD12Wy5r6MZbCw=; b=eScvHh0xrMD0eQLl
 8756HiqBnl+uh5GoZSAoMTTIj8oVXL7QBJ56HmTvoLpOZ2XAbxi5Ebcfzb0pXQ3n
 Qn4w/rN2HVa9RY1958xvAtystJ9stXiE4rz+ZzLZF7dcfo0Pyb+MgqBMS/9wQ8dq
 Si9pEb1Kq29VXBs0EjroZtOqiExArOl0NtBtfGi5SUWW1+R50OWWJqoHZSvRt1Dx
 ZM4+fkkvX2yh8wSlZGFcOp1FgBETySIyMKNIKzQ8lnoyzdSg2xivjhPewa0ZTF2i
 0WDvP4lSwZxMUXkefP9jDVzC/OPHM1m3w75IzAtAIxd7+mZY2ZxXE1y6Sx1mUq1K
 MJ42Zw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; bh=tJcY4zuKVRcW2QJ3kR5SiCgdeAzE6eD12Wy5r6MZb
 Cw=; b=qqpszEL5VtMyRUF5hsZaqLWJnP+PPzsxvz/yoW11Utc256okA+K2R/TyZ
 ZAD9dS4mJ9oitVKSHrUg6D2t2E0Vx91hWxbfvveWq6/k+VY6UYbtDWo0DjnOajY7
 hfkLMJLuN9DQqg0Z+cBqykJ+QPB+Mgi0CiLbOTnhxlgVP/JWtLOqt4KHT+D7UumA
 xb8MMP8TkFCma2su1v7EO6enRtrjBTusHg9tf0r9IBwe76caUOIdvwpVg5NvRx0j
 YFK9X6qmaL8L0NpeXpJXYANsI3YZMHRO9LelCpyqsZ2BAE1CaFZjUb/TGTJ3uTef
 fbwUnJTKSsQRew9JahF/ciFywM7+w==
X-ME-Sender: <xms:govjXgeVu2JOnI4Y9Sy0mqRiH_lS_aD6miLadhnx5zOABmkumzjNvQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeiuddgjeefucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
 ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu
 ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf
 hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl
 ohhnrdhnvght
X-ME-Proxy: <xmx:govjXiPaLE7UD21UG8ZbbV4964Xb2zhvRT7TPyYgtHzS3Rc7GaHBQQ>
 <xmx:govjXhiruP7vxYoHqvYFFAl9DehprTexdRbVqpz2zmsYdQO4S6rOvg>
 <xmx:govjXl_VWy1F2dMXd8qIAAa7y21KnRVw87w9BH96yaO33_xXV5vAHg>
 <xmx:hIvjXghKZFuHULZ62OM6MNHwHcCf80YbTDGmuHwDttsFB1EUoKuAdg>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 19D1F30666C3;
 Fri, 12 Jun 2020 09:54:52 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozliuk <dmitry.kozliuk@gmail.com>
Cc: dpdk-dev <dev@dpdk.org>, Dmitry Malloy <dmitrym@microsoft.com>,
 Narcisa Ana Maria Vasile <Narcisa.Vasile@microsoft.com>,
 Fady Bader <fady@mellanox.com>, Tal Shnaiderman <talshn@mellanox.com>,
 Anatoly Burakov <anatoly.burakov@intel.com>,
 Bruce Richardson <bruce.richardson@intel.com>, Ray Kinsella <mdr@ashroe.eu>,
 Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 12 Jun 2020 15:54:48 +0200
Message-ID: <8606444.FnLyTyo8xH@thomas>
In-Reply-To: <CAEYuUWA++14xFUH2niaSai-5YY-YGCNaM1Ekb_aPALwgQU=Dvg@mail.gmail.com>
References: <20200608074153.29611-1-dmitry.kozliuk@gmail.com>
 <1737252.Ab5UzTuNQf@thomas>
 <CAEYuUWA++14xFUH2niaSai-5YY-YGCNaM1Ekb_aPALwgQU=Dvg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v8 03/11] eal: introduce memory management
	wrappers
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?