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 D2FD3A00BE; Fri, 12 Jun 2020 12:47:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7724A2C15; Fri, 12 Jun 2020 12:47:28 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id A52DC1B19 for ; Fri, 12 Jun 2020 12:47:27 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 14D565C005F; Fri, 12 Jun 2020 06:47:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 12 Jun 2020 06:47:27 -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= CeWZLAdZvASv2UUeV6XYD3Pa9kIfFklzgKY6fydoIc0=; b=io3haSpCPCWk9Pie cN+RXOHitZcMMW5dzm5rKbVnbhAnA1qe6lqXOOxYWiN2dgmyOw6PYa/DbsnxB7N8 68kyIPxde31Wzcf/kkK+h8VeAWcu5ET29fVZjsexJnZ8oVFRGTRgzbkch86UWJXr YGq8GWIvaL/O+js40JG0DCEjFt2OO/cJMc0hZvyt20qPVJ1zKXtKf0eVQLpkFyX5 mRIZ4J7JQKVMfEKJ/ZpZ2t8vJ7fGSWgZK8GMSTieHpeKnOHEo8lk9itjj9S1nWnO rdt4rhAz0/VVWB5pJ4tTbZOcJ7cE2RPBm/2Nj/LZNT6Ujp7OyzKq5yRvsyzpghBG r+cpzg== 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=CeWZLAdZvASv2UUeV6XYD3Pa9kIfFklzgKY6fydoI c0=; b=lvyRYzWb0VYv+7OgtmvPoqIadbqTSDXwLTKZ8ERJZFApz9R6CZCFOr17w QmsxbcqDM4u0xigjjUH9AS10oQNt1TnFyBDbcBidAa783h2N+5LG33TglKX/AAwk YjU2WTGIKVO01zQcRAmY5duJu2kq2C9I9rDxCgmBun9ZrRJqDesza10/OLdWgKjG k1ZnT9czcCn5EvofdoI8Gmwsxp8/gWCtd1mAE1cPTYcAunqAgrGbgqCosGXFcsBu plsbbFkRXSc0aSskXVUSJOcI7goYVt7fnznH5JfSMkE1y5lsLYl4fwFjSu/uWMsU fwNABXnqO3YhVXOaVt/mB7nxQYwCw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeiuddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 5C9293061DC5; Fri, 12 Jun 2020 06:47:25 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: dev@dpdk.org, Dmitry Malloy , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Anatoly Burakov , Bruce Richardson , Ray Kinsella , Neil Horman Date: Fri, 12 Jun 2020 12:47:23 +0200 Message-ID: <1737252.Ab5UzTuNQf@thomas> In-Reply-To: <20200610142730.31376-4-dmitry.kozliuk@gmail.com> References: <20200608074153.29611-1-dmitry.kozliuk@gmail.com> <20200610142730.31376-1-dmitry.kozliuk@gmail.com> <20200610142730.31376-4-dmitry.kozliuk@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 10/06/2020 16:27, Dmitry Kozlyuk: > Introduce OS-independent wrappers for memory management operations used > across DPDK and specifically in common code of EAL: > > * rte_mem_map() > * rte_mem_unmap() > * rte_mem_page_size() > * rte_mem_lock() > > Windows uses different APIs for memory mapping and reservation, while > Unices reserve memory by mapping it. Introduce EAL private functions to > support memory reservation in common code: > > * eal_mem_reserve() > * eal_mem_free() > * eal_mem_set_dump() > > Wrappers follow POSIX semantics limited to DPDK tasks, but their > signatures deliberately differ from POSIX ones to be more safe and > expressive. New symbols are internal. Being thin wrappers, they require > no special maintenance. [...] > +/** > + * Reserve a region of virtual memory. > + * > + * Use eal_mem_free() to free reserved memory. > + * > + * @param requested_addr > + * A desired reservation addressm which must be page-aligned. Typo: addressm > + * The system might not respect it. > + * NULL means the address will be chosen by the system. > + * @param size > + * Reservation size. Must be a multiple of system page size. > + * @param flags > + * Reservation options, a combination of eal_mem_reserve_flags. > + * @returns > + * Starting address of the reserved area on success, NULL on failure. > + * Callers must not access this memory until remapping it. > + */ > +void * > +eal_mem_reserve(void *requested_addr, size_t size, int flags); [...] > +/** > + * Configure memory region inclusion into core dumps. Not sure about the word "core" here. > + * > + * @param virt > + * Starting address of the region. > + * @param size > + * Size of the region. > + * @param dump > + * True to include memory into core dumps, false to exclude. > + * @return > + * 0 on success, (-1) on failure and rte_errno is set. > + */ > +int > +eal_mem_set_dump(void *virt, size_t size, bool dump); [...] > --- /dev/null > +++ b/lib/librte_eal/include/rte_eal_memory.h > @@ -0,0 +1,93 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2020 Dmitry Kozlyuk > + */ > + > +#include > + > +#include > + > +/** @file Mamory management wrappers used across DPDK. */ typo on "Mamory" + @file must be on a separate line: /** @file * * Memory management wrappers used across DPDK. */ > + > +/** Memory protection flags. */ > +enum rte_mem_prot { > + RTE_PROT_READ = 1 << 0, /**< Read access. */ > + RTE_PROT_WRITE = 1 << 1, /**< Write access. */ > + RTE_PROT_EXECUTE = 1 << 2 /**< Code execution. */ > +}; > + > +/** Additional flags for memory mapping. */ Typo on "Addtional" > +enum rte_map_flags { > + /** Changes to the mapped memory are visible to other processes. */ > + RTE_MAP_SHARED = 1 << 0, > + /** Mapping is not backed by a regular file. */ > + RTE_MAP_ANONYMOUS = 1 << 1, > + /** Copy-on-write mapping, changes are invisible to other processes. */ > + RTE_MAP_PRIVATE = 1 << 2, > + /** > + * Force mapping to the requested address. This flag should be used > + * with caution, because to fulfill the request implementation > + * may remove all other mappings in the requested region. However, > + * it is not required to do so, thus mapping with this flag may fail. > + */ > + RTE_MAP_FORCE_ADDRESS = 1 << 3 > +}; [...] > +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. If we want to keep them internal, we should add a doxygen marker @internal. > +#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?