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 58B66A0A0A; Fri, 22 Jan 2021 18:21:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C78E314108A; Fri, 22 Jan 2021 18:21:10 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id B8731141080 for ; Fri, 22 Jan 2021 18:21:07 +0100 (CET) IronPort-SDR: Pr/XdmOTy4g9AuijbzCn8jxkNfi6HORR0V+rYgoQiorszIklMLaJ1X5Ozuby5QS9mdvGIrqqPJ 6qB9KezWKIhg== X-IronPort-AV: E=McAfee;i="6000,8403,9872"; a="176903024" X-IronPort-AV: E=Sophos;i="5.79,367,1602572400"; d="scan'208";a="176903024" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2021 09:21:07 -0800 IronPort-SDR: yDgPL/qSm5lAkspGKSyoLo2BhODB15xFqoszjPLN9SPOTwnMbhMm2C5YbthaEWLguhO1aHFhXc N+6KdOJAkqhw== X-IronPort-AV: E=Sophos;i="5.79,367,1602572400"; d="scan'208";a="357101468" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.25.114]) ([10.213.25.114]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2021 09:21:05 -0800 From: "Burakov, Anatoly" To: dev@dpdk.org Cc: Damjan Marion References: <0ae7d9b2c1ee0e12f8ae7faa2d154c03ae7e0c92.1604935662.git.anatoly.burakov@intel.com> <8f49e252a7be2d8561f4b32193e5800f98c40b0e.1604936860.git.anatoly.burakov@intel.com> Message-ID: <108cb3e3-3ca6-996d-9822-05dde4c657c1@intel.com> Date: Fri, 22 Jan 2021 17:21:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8f49e252a7be2d8561f4b32193e5800f98c40b0e.1604936860.git.anatoly.burakov@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 21.02 v2] mem: don't warn about base addr if not requested 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" 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. -- Thanks, Anatoly