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 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 ; Mon, 6 Apr 2020 14:37:36 +0200 (CEST) Received: by mail-lj1-f194.google.com with SMTP id r7so14403145ljg.13 for ; 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 To: Fady Bader Cc: Tal Shnaiderman , "dev@dpdk.org" , Thomas Monjalon Message-ID: <20200406153734.40cb5c5a@Sovereign> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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