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 D6A99A034F; Wed, 6 May 2020 11:47:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BA9871D8CB; Wed, 6 May 2020 11:47:05 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id C99CF1D8CB for ; Wed, 6 May 2020 11:47:03 +0200 (CEST) IronPort-SDR: Z94ACLI+VTiovXmTzQe75HZ8tuzzhm0sNerLdmupJgz1+TYS1juIUSCFalpijRzaWGoM3CwdqV Eb3R2RegCSjw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2020 02:47:02 -0700 IronPort-SDR: hYc8SfLO3vveNMoC0UK8Tnv3shYdHS+yJb5Qfn+FjDfWUN+ROVWyESR3awq9ky+X9Fww1pNEku QiVwFV52P40g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,358,1583222400"; d="scan'208";a="278175449" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.209.121.37]) ([10.209.121.37]) by orsmga002.jf.intel.com with ESMTP; 06 May 2020 02:47:00 -0700 To: Dmitry Kozlyuk 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 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> From: "Burakov, Anatoly" Message-ID: <25dea975-7df1-6ad4-70b5-2ba5fd9647fa@intel.com> Date: Wed, 6 May 2020 10:46:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200506022017.5adf0b90@Sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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 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. 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). 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. > >>> diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c >>> index 7c21aa921..9fa7bf352 100644 >>> --- a/lib/librte_eal/common/eal_common_memzone.c >>> +++ b/lib/librte_eal/common/eal_common_memzone.c >>> @@ -19,7 +19,14 @@ >>> #include >>> #include >>> #include >>> + >>> +#ifndef RTE_EXEC_ENV_WINDOWS >>> #include >>> +#else >>> +#define rte_eal_trace_memzone_reserve(...) >>> +#define rte_eal_trace_memzone_lookup(...) >>> +#define rte_eal_trace_memzone_free(...) >>> +#endif >>> >> >> Is it possible for rte_eal_trace.h to implement this workaround instead? >> It wouldn't be very wise to have to have this in each file that depends >> on rte_eal_trace.h. > > I can add a patch that makes each tracepoint a no-op on Windows. > > We discussed this issue (spreading workarounds) 2020-04-30 on Windows > community call. The proper solution would be supporting trace on Windows, but > IIRC no one is yet directly assigned to do that. Apologies, i'm not plugged into those discussions :) -- Thanks, Anatoly