From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5E047A0524; Sun, 21 Mar 2021 02:01:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E2EC740143; Sun, 21 Mar 2021 02:01:06 +0100 (CET) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by mails.dpdk.org (Postfix) with ESMTP id 25F5A40041 for ; Sun, 21 Mar 2021 02:01:06 +0100 (CET) Received: by mail-lf1-f45.google.com with SMTP id o126so6238968lfa.0 for ; Sat, 20 Mar 2021 18:01:06 -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=qXRW3DOg8CaGOLAEFzxbdSJvNaVFwBnxHYjHDgDcFG4=; b=Qm1J0FlH6I+iYL9RCrnTbS16tEjnlgR/p6ls48N51MQxtgSi1Bl2oZQ5E3iRLH8l+h c+jgOPhLhW7TFF1TbSQYTFTx+shjkr9Dfi9tq/GqJ+v+nYPQDOR4v5KcgPraq7xiV79i i3+y5w3GkbtXE7NFcKxxdrHDY/h3Mzvu+89a5sGTrlyNoX3Ecd4ItnMc3zPgUDHy8pNR AWf/xvD1Lsu7H5lcTA5e+uNbeEaJYIz/Vcegt/G1MtbW5MyeVl2uM8PAQ+RoJ2rLCP1T JdcjyMOKzP1pihvz2Eub9x2fT6DyqvEuJEUFMxv4dlevanW8iVMFk1uUPr5lpBvKolNY 3zrg== 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=qXRW3DOg8CaGOLAEFzxbdSJvNaVFwBnxHYjHDgDcFG4=; b=ndSdKSTtq/kFY5FjeIciHWb/HhL6aUaaMbANWmxH4b/dtxxJkmVxPNGG7pZ8Sm0EZ9 mxxbKsdrhg0/K5OUDDNVpSD5C86/IPgeJCCxAYwhM8Z9N6w3lCV6H4LUtpZ6sMdO6UWJ NGDNX02yI3f3BRpoAKnvjbh1U/anBwyPjnMAiztu6h9aRtdg8eDm36OrYcUytyDqbq6u hNyQktzYbxt8KnB696Q6OaH++5oBJQjoz/oHLy2IPhZSSKrWsCoweCP4Gm6X5M4LuU/u YoRdHwThnOlNYNZpPWEXq92AlhHM8kt9L0vH0jiIhEisnLPVVswz2r8B1MjSPuT0Shzn ZUVA== X-Gm-Message-State: AOAM5330RkGlvVd31cYngZ58uoOMx59aCDqS82S32GJZEXQEl82EtX/P IE/ghiSpe6N7FjNsth8UDTQ= X-Google-Smtp-Source: ABdhPJx6AtoycB5OlNCJBzDPO9M/JNrZ1pKJe5nGMsYrDS4AYaboc/M8K2S+ySXvXoAGq1cIGAlB1g== X-Received: by 2002:ac2:51dc:: with SMTP id u28mr4816779lfm.322.1616288465610; Sat, 20 Mar 2021 18:01:05 -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 e18sm1326513ljl.92.2021.03.20.18.01.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Mar 2021 18:01:04 -0700 (PDT) Date: Sun, 21 Mar 2021 04:01:03 +0300 From: Dmitry Kozlyuk To: Jie Zhou , Anatoly Burakov Cc: dev@dpdk.org, xiaoyun.li@intel.com, roretzla@microsoft.com, pallavi.kadam@intel.com, thomas@monjalon.net, bruce.richardson@intel.com, ferruh.yigit@intel.com Message-ID: <20210321040103.0cd5bb77@sovereign> In-Reply-To: <1616172695-28505-1-git-send-email-jizh@linux.microsoft.com> References: <1616048795-16906-1-git-send-email-jizh@linux.microsoft.com> <1616172695-28505-1-git-send-email-jizh@linux.microsoft.com> X-Mailer: Claws Mail 3.17.6 (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 v2] app/test-pmd: enable testpmd on windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 2021-03-19 09:51 (UTC-0700), Jie Zhou: > Issue under active investigation: > - Recent DPDK upstream change "eal: detach memsegs on cleanup" exposed > failure at eal exit with "EAL: Could not unmap memory: No Error". > Investigating KERNELBASE!UnmapViewOfFile. The issue will cause system > crash. Currently temporarily remove cleanup at exit on Windows. > Will revert after issue root caused and fixed +Anatoly It's my fault I assumed "eal: detach memsegs on cleanup" series related to multiprocess only and didn't properly review it. The culprit is this code (eal_common_memory.c:1019): for (i = 0; i < RTE_DIM(mcfg->memsegs); i++) { struct rte_memseg_list *msl = &mcfg->memsegs[i]; /* skip uninitialized segments */ if (msl->base_va == NULL) continue; /* * external segments are supposed to be detached at this point, * but if they aren't, we can't really do anything about it, * because if we skip them here, they'll become invalid after * we unmap the memconfig anyway. however, if this is externally * referenced memory, we have no business unmapping it. */ if (!msl->external) if (rte_mem_unmap(msl->base_va, msl->len) != 0) RTE_LOG(ERR, EAL, "Could not unmap memory: %s\n", strerror(errno)); 1. It assumes memory is allocated using mapping, which is not the case for Windows. Instead of rte_mem_unmap() it should be eal_mem_free(), which is the same munmap() on Unices. However... 2. It assumes this line will remove all mappings within (base_va, size), as munmap()/rte_mem_unmap() would do. However, eal_mem_free(base_va, size) is only guaranteed to work if (base_va, size) came from eal_mem_reserve(size) or from OS-specific allocation (mmap on Unices, VirtualAlloc2 on Windows). Because of underlying munmap, it works as desired on Unices, but not on Windows. 3. A minor, but still: errno -> rte_errno, strerror -> rte_strerror. I can make eal_mem_free() behave as expected at issue 2. Or should we simple disable this code when where's no multiprocess support (how do we test for it properly, BTW)?