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 017D1A0562; Mon, 30 Mar 2020 06:10:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 883871BFD4; Mon, 30 Mar 2020 06:10:38 +0200 (CEST) Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by dpdk.org (Postfix) with ESMTP id 49ABCF12 for ; Mon, 30 Mar 2020 06:10:37 +0200 (CEST) Received: by mail-lf1-f67.google.com with SMTP id j17so12930754lfe.7 for ; Sun, 29 Mar 2020 21:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=wMMVeSP5sBPjNmgFvQ6GWl3P0Zy7/BJCyG9iQysrGHk=; b=qraPUXXOaPGpfbaRIchOaQcIN+pc4fCTuutHQyOeEHu27brWJ4mX6+/T9aOj1HO95t W519Zfdxr83+Li4HyGuIhEIyYdMn5d5DCHT8oWl4tlraKQ0mMK5roKrE/plDScQdYvNh trQIKjnKRHheofIDUTpfXWS4DRfPbQoK+dK78XOcxNle4wQiz/YaeFtmlZ27hRwpSBsR 7tarayyaU2IY+usIRq/yt3fYkFiVMN3iXl3JE80QCbGqXJBnzeClh8X9ViKP1Gp2v/vN INUsL+9q1zTJ5E2MPR4x0l9EIzt1bTaGeTtFXERSxLmdmO+zBhgXk+YAUcCDIR0N7rwD P4WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=wMMVeSP5sBPjNmgFvQ6GWl3P0Zy7/BJCyG9iQysrGHk=; b=JVE/EuLs3QvbwSIfYJYI47tXv+mKMSa8AOqzk4DOKudMb8M8FYuissWe38fYarNuSZ KQ0rPQfKtC0msg8UdqC4PHTRV/StDtNHDJi+jA0XAxtBI0mI2Oqnoq7hQkZNUl9AiQ+w naxzGJ9jYtduaTmRQ2/4ROqtlF0t2vEOyXWwB7BCjx1kIFsQAtfXyhnPTrLi/Bi0W35i RxZH9baoR/Ps+TARNqsWA4YDCYE3Kmj2wwu3peTMgUJVOyx6lf3uc7f+SgHMhnS+5V3v tAHwc1itpz3Uopxvvnso81TyyDCExkbSFn+4n3quYwk0ItbsRTe+/7MpaYAE/HHu03of sA6A== X-Gm-Message-State: AGi0PuZlsBd/nHQwhGx62MAf8/akovFJ46Y8RGrBDav2vgW4fuhcprGT +Q7VBZGA1Ee6SnSyuf04cYkCScr5jE4= X-Google-Smtp-Source: APiQypIFQ/+7VtjDDx+ouGBBs34szVxaUHin1aDLrWvyuvix0FWi2xnU4GpfteQ0f1p3W9AIv0dUxQ== X-Received: by 2002:ac2:5ede:: with SMTP id d30mr6700260lfq.157.1585541436118; Sun, 29 Mar 2020 21:10:36 -0700 (PDT) Received: from localhost.localdomain (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.googlemail.com with ESMTPSA id c22sm6210036lja.86.2020.03.29.21.10.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Mar 2020 21:10:35 -0700 (PDT) From: Dmitry Kozlyuk To: dev@dpdk.org Cc: "Dmitry Malloy (MESHCHANINOV)" , Dmitry Kozlyuk Date: Mon, 30 Mar 2020 07:10:17 +0300 Message-Id: <20200330041026.784624-1-dmitry.kozliuk@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [RFC PATCH 0/9] Windows basic memory management 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" This RFC implements basic MM with the following features: * Hugepages are dynamically allocated in user-mode. * IOVA is always PA, obtained through kernel-mode driver. * No 32-bit support (presumably not demanded). * No multi-process support. Note that without --in-memory EAL MM will create files in current working (runtime) directory. * No-huge mode for testing with no IOVA available. IOVA could be obtained using Address Windowing Extensions, but it is doubtfully demanded. Roadmap for Windows [1] proposes that memory management (MM) should be implemented in basic and advanced stages: 1. Basic MM must be sufficient for core libraries and network PMDs: 2. Advanced MM could address features missing from basic stage. Advanced memory management discussion is out of scope of this RFC. Windows community calls suggest is will be focused on security and IOMMU support. I will post a separate thread with background and suggestions. Cc'ing Dmitry Malloy (MESHCHANINOV) nevertheless. Because netUIO is not yet committed to dpdk-kmods, the first commit introduces a new simple driver, virt2phys. It will almost certainly become a part of netUIO once it is available for patches. Until then, it must be installed according to documentation provided with the patch. User-mode code locates the driver interface by GUID, so transition from virt2phys to netUIO should not require changes to DPDK. Hugepages allocation on Windows requires some privilege setup. Please refer to documentation provided in the "initialize hugepage info" patch. New EAL public functions for memory mapping are introduced. Their implementation for Linux and FreeBSD is identical. The upcoming patch series reorganizing EAL directories will help fixing that [2]. Windows MM duplicates quite a lot of code from Linux EAL: * eal_memalloc_alloc_seg_bulk * eal_memalloc_free_seg_bulk * calc_num_pages_per_socket * rte_eal_hugepage_init Need input if it should be left as-is to evolve independently, or some "common to memory hot-plug" code should be factored out. This duplication may be reduced naturally when advanced MM is implemented. Notes on checkpatch warnings: * No space after comma / no space before closing parent in macros--- definitely a false-positive, unclear how to suppress this. * Issues from imported BSD code---probably should be ignored? * Checkpatch is not run against dpdk-kmods (Windows drivers). [1]: http://core.dpdk.org/roadmap/windows/ [2]: https://patchwork.dpdk.org/project/dpdk/list/?series=9070 Dmitry Kozlyuk (8): eal/windows: do not expose private EAL facilities eal/windows: improve CPU and NUMA node detection eal/windows: initialize hugepage info eal: introduce internal wrappers for file operations eal: introduce memory management wrappers eal/windows: fix rte_page_sizes with Clang on Windows eal/windows: replace sys/queue.h with a complete one from FreeBSD eal/windows: implement basic memory management config/meson.build | 12 +- doc/guides/windows_gsg/build_dpdk.rst | 20 - doc/guides/windows_gsg/index.rst | 1 + doc/guides/windows_gsg/run_apps.rst | 47 + lib/librte_eal/common/eal_common_fbarray.c | 57 +- lib/librte_eal/common/eal_common_memory.c | 50 +- lib/librte_eal/common/eal_private.h | 116 +- lib/librte_eal/common/include/rte_memory.h | 69 + lib/librte_eal/common/malloc_heap.c | 1 + lib/librte_eal/freebsd/eal/eal.c | 40 + lib/librte_eal/freebsd/eal/eal_memory.c | 118 +- lib/librte_eal/linux/eal/eal.c | 40 + lib/librte_eal/linux/eal/eal_memory.c | 117 ++ lib/librte_eal/meson.build | 4 + lib/librte_eal/rte_eal_exports.def | 119 ++ lib/librte_eal/rte_eal_version.map | 4 + lib/librte_eal/windows/eal/eal.c | 152 +++ lib/librte_eal/windows/eal/eal_hugepages.c | 108 ++ lib/librte_eal/windows/eal/eal_lcore.c | 187 ++- lib/librte_eal/windows/eal/eal_memalloc.c | 423 ++++++ lib/librte_eal/windows/eal/eal_memory.c | 1166 +++++++++++++++++ lib/librte_eal/windows/eal/eal_mp.c | 103 ++ lib/librte_eal/windows/eal/eal_thread.c | 1 + lib/librte_eal/windows/eal/eal_windows.h | 113 ++ lib/librte_eal/windows/eal/include/pthread.h | 2 + lib/librte_eal/windows/eal/include/rte_os.h | 48 +- .../windows/eal/include/rte_virt2phys.h | 34 + .../windows/eal/include/rte_windows.h | 43 + .../windows/eal/include/sys/queue.h | 663 +++++++++- lib/librte_eal/windows/eal/include/unistd.h | 3 + lib/librte_eal/windows/eal/meson.build | 15 + 31 files changed, 3626 insertions(+), 250 deletions(-) create mode 100644 doc/guides/windows_gsg/run_apps.rst create mode 100644 lib/librte_eal/windows/eal/eal_hugepages.c create mode 100644 lib/librte_eal/windows/eal/eal_memalloc.c create mode 100644 lib/librte_eal/windows/eal/eal_memory.c create mode 100644 lib/librte_eal/windows/eal/eal_mp.c create mode 100644 lib/librte_eal/windows/eal/eal_windows.h create mode 100644 lib/librte_eal/windows/eal/include/rte_virt2phys.h create mode 100644 lib/librte_eal/windows/eal/include/rte_windows.h -- 2.25.1