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 1569FA0352; Wed, 6 May 2020 01:20:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A6D921D6A0; Wed, 6 May 2020 01:20:21 +0200 (CEST) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by dpdk.org (Postfix) with ESMTP id 000D51D573 for ; Wed, 6 May 2020 01:20:19 +0200 (CEST) Received: by mail-lf1-f65.google.com with SMTP id j14so2795073lfg.9 for ; Tue, 05 May 2020 16:20:19 -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=OkgdJr4HPu8bp0Qr9ptErYERiTZ1z1JctIb6gozZSI8=; b=oUxpo+f4U4QcVOtL/a1XtFrHORSRWC6+6CSCE0V0FOtghR27d3pnRv0+jrCFpA/Zkm nv0rFGDAIheVS+Sk5TAbVj05+MvADMfHHbYLghUpMHy2E15l+Dk5kRVmVn9ScsWmg3dY 0RwueWxvBwSYW6ZhFHNzWCj07RsXXvVBJC4+Ch+3u9Tk0G+wcrAt1BAA7NE34B5Mc0Bv 35/LJEbGEPlzoV0DilP4kisIfi3AMejlpXW4K40hRusR9+dnpjwfKwGrS8enU4ruB0B+ EfTgwge+75qXS7Dbmb/ptqcVS19H/hokECUp70dNAH9CGjYoDk0qWhWnD4KIp3LQgoE5 PyOw== 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=OkgdJr4HPu8bp0Qr9ptErYERiTZ1z1JctIb6gozZSI8=; b=Gly+OAqgdlejYB0JV3bQKYFW6z/PC2hkSHLhHGyYyoxQk9IkR/zUns5D2lFqImd7uv EXJB4ReL8tmFrERxyrmPIrw60zgCNMI0PWs1s2RF1FNq9plU6owojFWWr6PyPfx5DWq1 SHORg38yPeIHIuJzCRxw47gKJe/hCLLV1K6NDJZ0Uj1ijwPoX7VrQJNBmnQKkG3B92RZ 4GuoanwsR4N8aqlDy8egfgA6VTB35SbX0s+PMmz/B3QwteTsXiGyKxX3bW+pmRaeRvJ3 0pEhieEcN71/YhjiyCpIDgaCNZLxl5hrKDzMBZnHBfQ9mD96kkQAVuzkR+8nD1evrCF9 nlqg== X-Gm-Message-State: AGi0PuZuqJ0OaxzbqLGWCgJYHDaOWmENSrwOHivHe22VT389K4jqwwrn mjkeXQtFmiYmbIwipBBbEJY= X-Google-Smtp-Source: APiQypLmyGhdYvctS+t3MaAEGzOTh8E7vt97IRV6pUc+P75ufwhdID/rICK5hMjsdPIpTQMrGH/2ww== X-Received: by 2002:a19:6b13:: with SMTP id d19mr3162896lfa.126.1588720819450; Tue, 05 May 2020 16:20:19 -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 f27sm160443lfe.93.2020.05.05.16.20.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 16:20:18 -0700 (PDT) Date: Wed, 6 May 2020 02:20:17 +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: <20200506022017.5adf0b90@Sovereign> In-Reply-To: <41f2a43d-2c22-f408-f21f-64932e4d5bb8@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> 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-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? > > 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. [snip] > > + /* Prevent creation of shared memory files. */ > > + if (internal_config.no_shconf == 0) { > > + RTE_LOG(WARNING, EAL, "Multi-process support is requested, " > > + "but not available.\n"); > > + internal_config.no_shconf = 1; > > In the future i would like to deprecate no_shconf because it's a strict > subset of in_memory mode and serves the same purpose. Might i suggest > using in_memory flag instead? IIRC no_shconf is automatically set when > you set in_memory mode. OK, thanks. -- Dmitry Kozlyuk