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 94561A034E; Wed, 6 May 2020 23:53:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E92E1DB2E; Wed, 6 May 2020 23:53:57 +0200 (CEST) Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by dpdk.org (Postfix) with ESMTP id 556891DB2C for ; Wed, 6 May 2020 23:53:56 +0200 (CEST) Received: by mail-lj1-f195.google.com with SMTP id f11so4107511ljp.1 for ; Wed, 06 May 2020 14:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6JQe5OR3Gd6STg4lfpZmuR20ceO2g9N5S9NcGmYadM0=; b=Wp7TF922oYLeLeDCo5VDgbPcz3A8cpw5DNIEsyynkzE6tqdwY8A+jQkugFDaCYha3l VaXboYV+AhAV9q1FNIYjJntypBQ4ceLW+u6XO5+JpDIa4sNzcu+BmLdXFU7bAzNS2vw5 9a21bhwsuFhKMm9aqiXpKZ9ovOSorwaIJ7UbICpZCwbObCu4bZ8FJInDihX48gFY+5e4 tcmHxwzpyxRAJ2KvGYryGjeeXY0nKGUmB3fEftoeejiCqtsAnjxdw4wfcdntuqfX6/xs Cg1bgwOi9HR6l3o3icp8geSxK1aSuLmfZzzJtgiLXkpZ0KKAyzGBDaQClxl3uw2EVwwS hjbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6JQe5OR3Gd6STg4lfpZmuR20ceO2g9N5S9NcGmYadM0=; b=tOLNp6D6diUQrkeIKZqGSIMVQRJ0wo/AaWaKjNdqaqQDNAeRBok48xKh7HA6g6nIFz L5Q0/oa3PswAUEEJblT9ZjoD1rilXkTKCeDB+sgoekY9YZWNcXhZ8+xPky6enxIeL+lV Hxtg3sZ6WDYupNPUHwhOddtiwm/oHwui7txO89l+EPPgpNxe4aMs6ZPgVktwMHiFQlxA IPvGAD9lKOonr5HRcdtOi0VkcdMNE504vtGC8Grj7LqHETy4vQN2Wfg5w9HdWuBl1ymm 2X5U9WwBvYKnjMeyOCqEgu7WCTmhZz2XjzshxsT4P4KUSB1EkkPY2VxVjo3tNHIsOGQa 4VtA== X-Gm-Message-State: AGi0Pub36mDzDe4nDBIhqGyTEc+NNpGWKavy7gW/a44J68fiucNu8HmA 9S2SG8MZhgr9+8mXD4H0QyQ= X-Google-Smtp-Source: APiQypLAwvWidpg3ZVCy3L3OuuAtqJH8Xs1oDSRfwHIzDN8QVFpe6DAikb1NJ278nn6CdUDE/u0Yzg== X-Received: by 2002:a2e:571a:: with SMTP id l26mr6251000ljb.12.1588802035695; Wed, 06 May 2020 14:53:55 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id 78sm2085760ljf.76.2020.05.06.14.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2020 14:53:54 -0700 (PDT) Date: Thu, 7 May 2020 00:53:53 +0300 From: Dmitry Kozlyuk To: "Burakov, Anatoly" Cc: dev@dpdk.org, "Dmitry Malloy (MESHCHANINOV)" , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Thomas Monjalon , Harini Ramakrishnan , Omar Cardona , Pallavi Kadam , Ranjit Menon , John McNamara , Marko Kovacevic Message-ID: <20200507005353.28ec18da@Sovereign> In-Reply-To: <25dea975-7df1-6ad4-70b5-2ba5fd9647fa@intel.com> References: <20200410164342.1194634-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-9-dmitry.kozliuk@gmail.com> <41f2a43d-2c22-f408-f21f-64932e4d5bb8@intel.com> <20200506022017.5adf0b90@Sovereign> <25dea975-7df1-6ad4-70b5-2ba5fd9647fa@intel.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 8/8] eal/windows: implement 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" On 2020-05-06 10:46 GMT+0100 Burakov, Anatoly wrote: > On 06-May-20 12:20 AM, Dmitry Kozlyuk wrote: > > On 2020-05-05 17:24 GMT+0100 Burakov, Anatoly wrote: > >> On 29-Apr-20 12:50 AM, Dmitry Kozlyuk wrote: > >> Lots of duplication... I wonder if it would be possible to share at > >> least some of this code in common. Tracking down bugs because of > >> duplicated code desync is always a pain... > > > > This was the main question of the cover letter :) > > Dmitry Malloy explained to me recently that even internally Windows has > > no notion of preallocated hugepages and "memory types" (as memseg_primary_init > > describes it). Since Windows EAL is not going to support multi-process any > > time soon (if ever), maybe these reservations are not needed and memory manger > > should create MSLs and enforce socket limits dynamically? This way most of the > > duplicated code can be removed, I think. Or does MSL reservation serve some > > other purposes? > > MSL reservation serves the purpose of dynamically expanding memory > usage. But expansion is limited during init, because alloc_more_mem_on_socket() works with existing MSLs, correct? No going to change anything there, just trying to understand MM internals. > If there is no notion of NUMA nodes or multiple page sizes, then > you can greatly simplify the code, but you'd still need *some* usage of > MSL's if you plan to support dynamically allocating memory, or > supporting externally allocated memory (i assume it's out of scope for > now, since you can't do IOVA as VA). Windows is NUMA-aware and it supports both 2MB and 1GB hugepages (although Windows EAL does not at the moment, because Win32 API is not yet official). What I meant is that Windows does not reserve hugepages like Linux does with vm.nr_hugepages or hugepage-related kernel options. So logic duplicated from Linux EAL makes sense for Windows. The bulk of it can be extracted to some common file, but it will not be truly common, rather "everything but FreeBSD". Against it is a point that Windows MM may change significantly, but I honestly can't come up with an example of how can those duplicated parts may require adjustments. > So, yes, you could greatly simplify the memory management code *if* you > were to go FreeBSD way and not allow dynamic page reservation. If you > do, however, then i would guess that you'd end up writing something > that's largely similar to existing Linux code (minus multiprocess) and > so would just be duplicating effort. -- Dmitry Kozlyuk