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 905B3A034D; Fri, 28 Jan 2022 12:17:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D5E84286A; Fri, 28 Jan 2022 12:17:22 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id A0F8E40141 for ; Fri, 28 Jan 2022 12:17:21 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4C9835C0087; Fri, 28 Jan 2022 06:17:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 28 Jan 2022 06:17:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=r7RpxFmd9b2xCW ualxyrsXEnTrRipkQr9HyX4+wF5Nk=; b=h/u/lUoseYZZ02apmb2vwZ3JZIE8hk 8rphf7IndoirFIaa1fmBTpn5LcUW/fZD85XFoxfYgIS4oC8YlSUSF99lFUBowQje WWHBlGY+LYPG3SPZmIA/Ldy2xgcnS41r6MN4RNQvnBWWy4KYfTrq6Po8izLgx9yJ 2HWvmf5GCgDb/YJ+K+xl2Vxl7K/LmguI1p+zpJOysbyeYhLleOoaP9vGcFy6ir7Y Et41ae7cNeCHwdI5ZI0zSfQ2ZpTUBz/xgt5oKqHXTRpUVjb0QpNxqoGtFTaQ+/eY dU6PaIC+en+7DH0l4mTp65GxM/e9eRYPXjfi/wC5ID8//UMCih7oACXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=r7RpxFmd9b2xCWualxyrsXEnTrRipkQr9HyX4+wF5 Nk=; b=ZXwjbdRz3Au6oEINl2TkQjJeL3x4Pc8Q9duU0gdW0FZgI7Q3laF3e/NAo 0w5O3uIZwUnt3lAIE2ENyTRywQkL+rBdghn2MkcEl1M+Zf9p1lMcx5mJQXwjjGcc nhmCMphSFBs1ouvRLPpfSxrWO4VkMU07Pa24xqYUo1JeFQLb2E95ocNjPJ5x3WpC DELBFQE8Xc0/6TBKR/SVYVyTe4UE3c6XOa8rSBREDEWTEr2Gi7GCVIDPVvpbDxXW oKjUMOjf97LHs9SKf2eL+I5IxQt5KdWeCpIv1jUpu6PLlcrtL+Qq3p4H2HNbHsN2 /84fEKQLClUpDcpEoVMFejeQMRrcg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeehgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 28 Jan 2022 06:17:17 -0500 (EST) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, Damjan Marion , dmitry.kozliuk@gmail.com Subject: Re: [dpdk-dev] [PATCH 21.02 v2] mem: don't warn about base addr if not requested Date: Fri, 28 Jan 2022 12:17:14 +0100 Message-ID: <1780203.atdPhlSkOF@thomas> In-Reply-To: <108cb3e3-3ca6-996d-9822-05dde4c657c1@intel.com> References: <0ae7d9b2c1ee0e12f8ae7faa2d154c03ae7e0c92.1604935662.git.anatoly.burakov@intel.com> <8f49e252a7be2d8561f4b32193e5800f98c40b0e.1604936860.git.anatoly.burakov@intel.com> <108cb3e3-3ca6-996d-9822-05dde4c657c1@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 22/01/2021 18:21, Burakov, Anatoly: > On 09-Nov-20 3:47 PM, Anatoly Burakov wrote: > > Any EAL memory allocation often goes through eal_get_virtual_area() > > function, which will print a warning whenever the resulting allocation > > didn't match the specified address requirements. This is useful for > > when we have requested a specific base virtual address, to let the user > > know that the mapping has deviated from that address. > > > > However, on Linux, we also have a default base address that's there to > > ensure better chances of successful secondary process initialization, > > as well as higher likelihood of the virtual areas to fit inside the > > IOMMU address width. Because of this default base address, there are > > warnings printed even when no base address was explicitly requested, > > which can be confusing to the user. > > > > Emit this warning with debug level unless base address was explicitly > > requested by the user. > > > > Cc: Damjan Marion > > > > Signed-off-by: Anatoly Burakov > > --- > > > > Notes: > > v2: > > - Fix the condition to not update the address incorrectly > > - Instead of removing the warning, let it have debug level unless base address > > was explicitly specified by the user > > > > I'm not entirely sure the trade off between user confusion and helpful debug > > information is worth it, but in my experience, i've stopped getting any emails > > about secondary processes a long time ago and this isn't a widely used feature, > > so i believe this is worth it. > > For some reason i didn't get David's comment in my inbox, so i'll copy > it here: > > > EAL options like --in-memory or --no-shconf makes MP unusable. > > If we add a rte_mp_disable() for them, we could check here for MP > > status here and display nothing at all. > > WDYT? > > That sounds like a nice idea, but this patch addresses a different issue. I think it is the same issue, pushed further. Anyway, let's take this patch (waiting for one year) and wait for another one removing the log completely in case secondary process is disabled. Applied