From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F1CC7A00BE; Fri, 12 Jun 2020 23:37:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CA81F1BEDE; Fri, 12 Jun 2020 23:37:57 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id E72D91BEDD for ; Fri, 12 Jun 2020 23:37:56 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 41F985C0044; Fri, 12 Jun 2020 17:37:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 12 Jun 2020 17:37:56 -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= qlWnLW7vPJTU+zOfo4LAUPyf3cgavVFjfJq6Ajo3zKg=; b=pUFbsg7yO34pPbQo zCpneM8BBac4AmbAuxBvhP1NjK8thNxqgc0M1VM8sEkhGpNFm2GXuBhfY14Uoaij ueqiHokDP9/qosqJhyPdca4r2kQv5vhVof0Y0aKlm9LUAVYmY1A2x69kvJwRL+Tr ddJ9nkojogB6U7+sGnekORfQywTQ4RTefiuPeprlFUPp/Ur0vnvLTrCu6nX0AIOj yRGc8Hr/22qoIzlzC1kezhnxLclZz262j7mTuGTBpgQe4d1cUbaG47EwFYvdXtN6 d9vYT75VkDQr9ir2dePR5GR76zkz+IrcBuDk5vRFan+/S3fbVodVNbTQlG2DyYam 1J0k7A== 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=qlWnLW7vPJTU+zOfo4LAUPyf3cgavVFjfJq6Ajo3z Kg=; b=O1flyRIjC5fE90vRt8PwfZSMgNLSeaZ3+dVeYl7INWuHHMxWehC/9W5E7 6BIvho4TWQUQTEyi93m8HtUTsX6wuISTlQtGjlG62mIv0vPkdBeAHfv5s8k0gXea PE8sGOwKsZZml7nhD89DvhsjGAHkUN9H2IPq7WDAHhDwcFeo0ZcSriBbmiBiSAg1 dZpDf6n9pYLAuPOkwRysl0heh0VSbqyJUCSF20NTBevLlEIguCVTwyEcfIXerKS6 CmK4SVgqCCsMRWRMuo5uwkttV6luhxfN/V46VVNhDnsspMNlDCVw3McjXFgUMWdy 2V9F6WNMWtBKr8b9XEFpZmp12FabQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeiuddgudeijecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 40120328005A; Fri, 12 Jun 2020 17:37:53 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozliuk Cc: dpdk-dev , Dmitry Malloy , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Anatoly Burakov , Bruce Richardson , Ray Kinsella , Neil Horman Date: Fri, 12 Jun 2020 23:37:51 +0200 Message-ID: <11707067.C2Zn7LyNnq@thomas> In-Reply-To: References: <20200608074153.29611-1-dmitry.kozliuk@gmail.com> <8606444.FnLyTyo8xH@thomas> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 12/06/2020 22:24, Dmitry Kozliuk: > > > > > +#include > > > > > > > > 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? > > > > It means nothing on Windows. Also, mmap has little to do with libc. > > Which file name can it be? > > Your rte_mem_os.h sounds good, except internal header better be > rte_eal_mem_os.h. Alternative: rte_eal_paging.h. I don't think we need to use the prefix "eal" if we already have "rte_mem". I have no strong opinion. rte_eal_paging looks also good. Anyway, it is internal, so we could change it if needed. Please choose one :)