From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 66392A0577;
Mon, 6 Apr 2020 14:37:38 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 428D71BEE1;
Mon, 6 Apr 2020 14:37:38 +0200 (CEST)
Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com
[209.85.208.194]) by dpdk.org (Postfix) with ESMTP id 597A61BED9
for <dev@dpdk.org>; Mon, 6 Apr 2020 14:37:36 +0200 (CEST)
Received: by mail-lj1-f194.google.com with SMTP id r7so14403145ljg.13
for <dev@dpdk.org>; Mon, 06 Apr 2020 05:37:36 -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=QcdAhSJthbYurks0Sc97XUDo7z5kzIMLUq9457So41I=;
b=rLqdP4GyC6z3mbtjh2S5PQKXpe9hanwt7nKrmCnDjAOpVt6tgSc5VpJ8YLB/wVx59r
7J4Suz4DFZTz2FxEnFxX+3dUkiHAjRE9yb1DEQvQVAitRbiSP9iNcYTKGsf3pi8iscll
qoTgxRJG9DlmmOaWUHb312YainAIg23xPS/HGCPq1atQAvxKR/y7tz0xRcddKCKvTeim
3IkbILzU7OF9dH1KueVEaolliTfmkD0Xv2q5vP+QOy5vy7LJ+y8+z9CiROf+D7QcRv5k
00a+9LE2rkqrx29n85BYhxyZdIJasfzU/wM+OJG7jrUe0nQOmriinSyxgh+T54HwGNmh
Mw0Q==
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=QcdAhSJthbYurks0Sc97XUDo7z5kzIMLUq9457So41I=;
b=Xb8bgzi95z4m3tAeItgixjTGP1EYmaFnPL6WQc6psfwpf/aIM3QPSNXMPysUwKQwyj
KjAVL/UCQcnOseeACnGX1GqSkFXgzub7K18jXleexqVFccHtzSv6pmRnktpQxZVSssKD
BMxy2GKkvnI8D3NJO1vAd3J/Lf14ukyG53LpE4sOMJcJGmZNlcvqFfnRatqRVdQJRq3U
lvB67KOZmlXuZtt/u7dFvXLNUzc/mbg+ITiLiNvcVo2UQVaiHkWLfy6pMGwkQyvgh6hg
Xjfm2NTvcqU7FuBa/DOjGvU+riTQCy6zaGTDw/rxUGhXK4cy6rwsNLttVDF3fk1z0CpH
w/Uw==
X-Gm-Message-State: AGi0PuZY0/rm0Iv9oAipZeG4oUkxlleVSOrI6ljqGWcAgMmV9UUc6Fit
ua5NfeIVux9YoygLtjZLVjY=
X-Google-Smtp-Source: APiQypIUqNd8zfvSqv0Nkk5RkV6uj++GDl6vpS0CszHFZ05nQBJ7YxgDMJqBWhlZkKDJGhKccqh0Ig==
X-Received: by 2002:a2e:89d2:: with SMTP id c18mr11897495ljk.29.1586176655913;
Mon, 06 Apr 2020 05:37:35 -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 u5sm1628997lfg.50.2020.04.06.05.37.35
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 06 Apr 2020 05:37:35 -0700 (PDT)
Date: Mon, 6 Apr 2020 15:37:34 +0300
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Fady Bader <fady@mellanox.com>
Cc: Tal Shnaiderman <talshn@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>
Message-ID: <20200406153734.40cb5c5a@Sovereign>
In-Reply-To: <AM0PR0502MB4034253D9FB173F686590D66BFC20@AM0PR0502MB4034.eurprd05.prod.outlook.com>
References: <AM0PR0502MB4034253D9FB173F686590D66BFC20@AM0PR0502MB4034.eurprd05.prod.outlook.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] questions about Windows basic memory management patch
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Hi,
> In the "eal/windows: fix rte_page_sizes with Clang on Windows" (http://patches.dpdk.org/patch/67390/) patch I didn't understand the work around that you did and what the problem was.
Clang on Windows always uses uint32_t as an underlying type for enums. As a
consequence, rte_hugepage_sizes cannot contain elements from 4GB onwards,
because they will be clamped to 0, resulting in the following error:
[17/41] Compiling C object lib/76b5a35@@rte_eal@sta/librte_eal_common_malloc_heap.c.obj.
FAILED: lib/76b5a35@@rte_eal@sta/librte_eal_common_malloc_heap.c.obj
clang @lib/76b5a35@@rte_eal@sta/librte_eal_common_malloc_heap.c.obj.rsp
../../../lib/librte_eal/common/malloc_heap.c:69:7: error: duplicate case value: 'RTE_PGSIZE_4G' and 'RTE_PGSIZE_16G' both equal '0'
case RTE_PGSIZE_16G:
^
../../../lib/librte_eal/common/malloc_heap.c:66:7: note: previous case defined here
case RTE_PGSIZE_4G:
^
1 error generated.
Maybe there's a better way to explain it in comments and commit message?
After I moved RTE_PGSIZE_4G and RTE_PGSIZE_16G outside of the enum, I had to
add `-fno-strict-enum` so that these values could be passed to where
rte_page_sizes is expected.
> Regarding rte_mp functions I see you implemented a stub, i.e. empty functions. I don't know why it is needed.
They're called from common EAL memory management routines.
> Just to make sure, does the rte_mem_map function that you implemented replaces Linux's mmap function ?
Yes. DPDK libraries have a few places they need memory-mapped files or
anonymous mappings, so I exported it (librte_mempool being the closest one,
libre_bpf also comes to my mind).
> Lastly, in the patch you implemented functions that were common for Linux and FreeBSD and in order to use them in Windows (e.g. eal_file_truncate that replaced ftruncate) and you got a duplicate code for Linux and FreeBSD, how can we solve this duplication ?
In v2 I'm going to create lib/librte_eal/posix subdirectory and move such
code there. I expect more code to end up there eventually, for example,
dynamic library loading. This possibility was among motivations for EAL
directory split.
There're another duplication that worries me: copy & paste from Linux EAL in
eal_malloc.c and eal_memory.c initialization. However, it this can't be
helped, I'd rather leave it be for now and reconsider it when implementing
advanced memory management.
--
Dmitry Kozlyuk