From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6C969A034F; Mon, 17 Jan 2022 09:08:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A0F3411AE; Mon, 17 Jan 2022 09:08:25 +0100 (CET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2078.outbound.protection.outlook.com [40.107.236.78]) by mails.dpdk.org (Postfix) with ESMTP id 672624067B for ; Mon, 17 Jan 2022 09:08:23 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mdeuQMsUGupSPXXKVI7wQl8iy6nfCcFgeynldSrSLWyNgNX23w6UM5mzyX8mkCnprsJ3Q+x4PK9zisLCrwjOHv2RN/MDxhC20GUx6yAibGRZWfqj3gEBM7MvcGct5kuottHIgtRtrtmWeT1Aztq3zjBGPincIq5H85QPDO9OIHJGHJDONJDi0pocJFyi51F61nulCuOGwFU9FEt62opPN4MqzBLWID9s0BcXRhdIVapgAyJEog+T16N4xwnvbKRhTPLKMw96vdGGU3gyciWNQJMej1w/iTugZv0VfUD8fvDgqyjcYl7abbK0f3XKQ5Q9BE9j1OttPA5SkjjAq8alQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+XVNd5qa5ZlL/CS/VF8eTYGTTv6TESaF90gIqquAP94=; b=HMk1RqXJo9pIakUb7lB/0WgUuM1VFedRqbHJNQ+5ffAwhIRDWWxPjRofU5H6rFwWlaNRwikrGQkF6JpJ5WAaVzOTGLgOI+gJbPZ16eClyJbcsWIfNQgjG0gpM747b2aUOoeJnPRnGvW4kVkXXn7LinwabSugAp1dXEHnfN+sio5qPtirJLVwlueJC7odSu/xPPD0URfLxvznhoABD2l/RIzMuWcmwbHcx1TaLBNUT0KeoaxCYybHSPudjYs5EBuuveF0qtJKZDnFNKxzWQEdwskugoTFwJ9bPbPI9gj1Eq0eJKL8V6RwvMJS376xF+mJntY78DlyMVq4Lp6+bayipw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 12.22.5.238) smtp.rcpttodomain=intel.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+XVNd5qa5ZlL/CS/VF8eTYGTTv6TESaF90gIqquAP94=; b=NSd9byBQKObDeh3u1zaL8tp7l5JjdeyXGYQRnMSAi6nJv/czu0PhF3+kbvWd1WVU29OIpC/rKFn4+0tDO/1xl1GkL7+LP3zgHRMyKAG7eEIGCUNCE1hzcuYjUfiYaMdxv8KqK4VL5EwPeDheM4GIwJA/h0Oo2xz4uB699psS9LBRPmpyczWb9t9k0SdKUrIrTKv8Yvxdh6SUtq3thVt90BJe5Nbn7TWIk8bEtxsZDpZyLOEkhrEBz8Vnf+AQtSrdwLbyZrDzuRhK2bcC5E3oBRPC6sVQq5RkSxI4aDrc7bqLPNFTdfNHlqXnIK/2/2ECm9gyx191tfUzrSztoIO1aQ== Received: from MW4P221CA0014.NAMP221.PROD.OUTLOOK.COM (2603:10b6:303:8b::19) by DM5PR12MB1562.namprd12.prod.outlook.com (2603:10b6:4:d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.9; Mon, 17 Jan 2022 08:08:21 +0000 Received: from CO1NAM11FT065.eop-nam11.prod.protection.outlook.com (2603:10b6:303:8b:cafe::f1) by MW4P221CA0014.outlook.office365.com (2603:10b6:303:8b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.9 via Frontend Transport; Mon, 17 Jan 2022 08:08:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 12.22.5.238) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 12.22.5.238 as permitted sender) receiver=protection.outlook.com; client-ip=12.22.5.238; helo=mail.nvidia.com; Received: from mail.nvidia.com (12.22.5.238) by CO1NAM11FT065.mail.protection.outlook.com (10.13.174.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4888.9 via Frontend Transport; Mon, 17 Jan 2022 08:08:21 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by DRHQMAIL105.nvidia.com (10.27.9.14) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 17 Jan 2022 08:08:21 +0000 Received: from nvidia.com (10.126.231.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.9; Mon, 17 Jan 2022 00:08:19 -0800 From: Dmitry Kozlyuk To: CC: Anatoly Burakov Subject: [PATCH v1 1/6] doc: add hugepage mapping details Date: Mon, 17 Jan 2022 10:07:56 +0200 Message-ID: <20220117080801.481568-2-dkozlyuk@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220117080801.481568-1-dkozlyuk@nvidia.com> References: <20211230143744.3550098-1-dkozlyuk@nvidia.com> <20220117080801.481568-1-dkozlyuk@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.126.231.35] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e2ec3d25-5d1d-4c7b-bdbd-08d9d99086fe X-MS-TrafficTypeDiagnostic: DM5PR12MB1562:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QqeQI/b4+7BND22qHxKv4zlwJNFmnUONtwdmD8hBxO5Z8dg8igkINprNnOiTAt+6dERxBTwzmhY7xSvs9f9l/g1ePzXhttNtVGDuyYhXmJzzaw0kqcM56sRX4Qhi8Nuqs77QdFG15vcoazreW//JDPW81Np+VRB3Z/zrcGzyNhV6g/f5e1XvB51S3ob8Qg33hSEPlPQFELAHzNWbkZn7MscSstotJOlCKX/nbdbQBUulHp5w5+sAWS+lkFxX0y21To+/+5BiHLoXfe45eCgEicE3i8IEVJNs4lgpMogxjdtOdJx2SVX+SVl7VT/lM2BP82c6EtljNfCZWbNDTUpU4LkUSunDvQSMvJUM8pXxqL918b2eu2kctfLS70QS5TGzBU4rHtrCHh7f9oEdNNUlQ+PR4jnemyNL6HgpeBmDxgOF8H0BOso8sE31RYGGb5CRS+iEv/aiHyXzqdsWvD0D03114g+Za+RRHYQUbQUdxmWleHBM5GUCpBDdqm/COKwajqAhX5Sbc3ziROOnhdsMY2pjRzrL2FJjdE/2ainnjM+aAjciS6qvP8ivjZBnDspHRZhBLhNzUKFd7S33iNSEHAKbEtyLavssUQ2UaPVLhR6DaYPTqI1QBMakb+s+JrdKRp2T4L31+Ae48DqLGjH8u4itVV7H63vxG6S4DW3k2/YkCrYd7FgwZVSZRAbQSPuvpfdkHH4rqXw9BbbRyHTysjygOSre4QGsikvqRO1YGvvIvWKClSbA+ZuRiYApSjBPS7IKfv3xRxQl5BwAEpvVOwRTH1N07FufO8dFe5hk9qU= X-Forefront-Antispam-Report: CIP:12.22.5.238; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:mail.nvidia.com; PTR:InfoNoRecords; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(40470700002)(36756003)(316002)(2616005)(426003)(36860700001)(336012)(2906002)(70586007)(4326008)(8676002)(70206006)(5660300002)(7696005)(356005)(6286002)(6666004)(6916009)(82310400004)(40460700001)(55016003)(16526019)(186003)(26005)(508600001)(8936002)(1076003)(47076005)(83380400001)(86362001)(81166007)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2022 08:08:21.1901 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e2ec3d25-5d1d-4c7b-bdbd-08d9d99086fe X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[12.22.5.238]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT065.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1562 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hugepage mapping is a layer of EAL malloc builds upon. There were implicit references to its details, like mentions of segment file descriptors, but no explicit description of its modes and operation. Add an overview of mechanics used on ech supported OS. Convert memory management subsections from list items to level 4 headers: they are big and important enough. Signed-off-by: Dmitry Kozlyuk --- .../prog_guide/env_abstraction_layer.rst | 85 +++++++++++++++++-- 1 file changed, 76 insertions(+), 9 deletions(-) diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index c6accce701..bfe4594bf1 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -86,7 +86,7 @@ See chapter Memory Mapping Discovery and Memory Reservation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The allocation of large contiguous physical memory is done using the hugetlbfs kernel filesystem. +The allocation of large contiguous physical memory is done using hugepages. The EAL provides an API to reserve named memory zones in this contiguous memory. The physical address of the reserved memory for that memory zone is also returned to the user by the memory zone reservation API. @@ -95,11 +95,12 @@ and legacy mode. Both modes are explained below. .. note:: - Memory reservations done using the APIs provided by rte_malloc are also backed by pages from the hugetlbfs filesystem. + Memory reservations done using the APIs provided by rte_malloc are also backed by hugepages. -+ Dynamic memory mode +Dynamic Memory Mode +^^^^^^^^^^^^^^^^^^^ -Currently, this mode is only supported on Linux. +Currently, this mode is only supported on Linux and Windows. In this mode, usage of hugepages by DPDK application will grow and shrink based on application's requests. Any memory allocation through ``rte_malloc()``, @@ -155,7 +156,8 @@ of memory that can be used by DPDK application. :ref:`Multi-process Support ` for more details about DPDK IPC. -+ Legacy memory mode +Legacy Memory Mode +^^^^^^^^^^^^^^^^^^ This mode is enabled by specifying ``--legacy-mem`` command-line switch to the EAL. This switch will have no effect on FreeBSD as FreeBSD only supports @@ -168,7 +170,8 @@ not allow acquiring or releasing hugepages from the system at runtime. If neither ``-m`` nor ``--socket-mem`` were specified, the entire available hugepage memory will be preallocated. -+ Hugepage allocation matching +Hugepage Allocation Matching +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This behavior is enabled by specifying the ``--match-allocations`` command-line switch to the EAL. This switch is Linux-only and not supported with @@ -182,7 +185,8 @@ matching can be used by these types of applications to satisfy both of these requirements. This can result in some increased memory usage which is very dependent on the memory allocation patterns of the application. -+ 32-bit support +32-bit Support +^^^^^^^^^^^^^^ Additional restrictions are present when running in 32-bit mode. In dynamic memory mode, by default maximum of 2 gigabytes of VA space will be preallocated, @@ -192,7 +196,8 @@ used. In legacy mode, VA space will only be preallocated for segments that were requested (plus padding, to keep IOVA-contiguousness). -+ Maximum amount of memory +Maximum Amount of Memory +^^^^^^^^^^^^^^^^^^^^^^^^ All possible virtual memory space that can ever be used for hugepage mapping in a DPDK process is preallocated at startup, thereby placing an upper limit on how @@ -222,7 +227,68 @@ Normally, these options do not need to be changed. can later be mapped into that preallocated VA space (if dynamic memory mode is enabled), and can optionally be mapped into it at startup. -+ Segment file descriptors +Hugepage Mapping +^^^^^^^^^^^^^^^^ + +Below is an overview of methods used for each OS to obtain hugepages, +explaining why certain limitations and options exist in EAL. +See the user guide for a specific OS for configuration details. + +FreeBSD uses ``contigmem`` kernel module +to reserve a fixed number of hugepages at system start, +which are mapped by EAL at initialization using a specific ``sysctl()``. + +Windows EAL allocates hugepages from the OS as needed using Win32 API, +so available amount depends on the system load. +It uses ``virt2phys`` kernel module to obtain physical addresses, +unless running in IOVA-as-VA mode (e.g. forced with ``--iova-mode=va``). + +Linux implements a variety of methods: + +* mapping each hugepage from its own file in hugetlbfs; +* mapping multiple hugepages from a shared file in hugetlbfs; +* anonymous mapping. + +Mapping hugepages from files in hugetlbfs is essential for multi-process, +because secondary processes need to map the same hugepages. +EAL creates files like ``rtemap_0`` +in directories specified with ``--huge-dir`` option +(or in the mount point for a specific hugepage size). +The ``rtemap_`` prefix can be changed using ``--file-prefix``. +This may be needed for running multiple primary processes +that share a hugetlbfs mount point. +Each backing file by default corresponds to one hugepage, +it is opened and locked for the entire time the hugepage is used. +See :ref:`segment-file-descriptors` section +on how the number of open backing file descriptors can be reduced. + +Backing files may persist after the corresponding hugepage is freed +and even after the application terminates, +reducing the number of hugepages available to other processes. +EAL removes existing files at startup +and can remove newly created files before mapping them with ``--huge-unlink``. +However, since it disables multi-process anyway, +using anonymous mapping (``--in-memory``) is recommended instead. + +:ref:`EAL memory allocator ` relies on hugepages being zero-filled. +Hugepages are cleared by the kernel when a file in hugetlbfs or its part +is mapped for the first time system-wide +to prevent data leaks from previous users of the same hugepage. +EAL ensures this behavior by removing existing backing files at startup +and by recreating them before opening for mapping (as a precaution). + +Anonymous mapping does not allow multi-process architecture, +but it is free of filename conflicts and leftover files on hugetlbfs. +If memfd_create(2) is supported both at build and run time, +DPDK memory manager can provide file descriptors for memory segments, +which are required for VirtIO with vhost-user backend. +This means open file descriptor issues may also affect this mode, +with the same solution. + +.. _segment-file-descriptors: + +Segment File Descriptors +^^^^^^^^^^^^^^^^^^^^^^^^ On Linux, in most cases, EAL will store segment file descriptors in EAL. This can become a problem when using smaller page sizes due to underlying limitations @@ -731,6 +797,7 @@ We expect only 50% of CPU spend on packet IO. echo 100000 > pkt_io/cpu.cfs_period_us echo 50000 > pkt_io/cpu.cfs_quota_us +.. _malloc: Malloc ------ -- 2.25.1