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 59E34A04B6 for ; Thu, 17 Sep 2020 13:28:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0671E1D618; Thu, 17 Sep 2020 13:28:50 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id EF6211D60E; Thu, 17 Sep 2020 13:28:46 +0200 (CEST) IronPort-SDR: LYTxkss4vEGbhy4IFo6g+dQGeBZFeqFwbdOIjc4PlLn/1VxnvGI+jaK2DTrB/Bt/FRq9ZsWyny RWRhkQXeEBvA== X-IronPort-AV: E=McAfee;i="6000,8403,9746"; a="158977992" X-IronPort-AV: E=Sophos;i="5.76,436,1592895600"; d="scan'208";a="158977992" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 04:28:43 -0700 IronPort-SDR: V+kTae17+yerqz4x1Es6H9+ohLZjYjRhF10bZ/rY7se3uAbFPxeTxnraWWCb4MkSgAxLv/ljx9 eWMHjLE2Hq3Q== X-IronPort-AV: E=Sophos;i="5.76,436,1592895600"; d="scan'208";a="483710722" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.206.43]) ([10.213.206.43]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 04:28:42 -0700 To: Nick Connolly , nicolas.dichtel@6wind.com Cc: dev@dpdk.org, stable@dpdk.org References: <20200805122640.13884-1-nick.connolly@mayadata.io> <4a1d578d-30e3-88de-be02-34ee0dd41ad1@mayadata.io> <906edd92-cda3-9e79-ebdd-29a944082b61@6wind.com> <64e06514-67ef-9843-48f1-beed83b03991@mayadata.io> From: "Burakov, Anatoly" Message-ID: <542c381e-9fad-d798-d1ce-2c51fb41da72@intel.com> Date: Thu, 17 Sep 2020 12:28:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <64e06514-67ef-9843-48f1-beed83b03991@mayadata.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [PATCH] mem: fix allocation failure on non-NUMA kernel X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 05-Aug-20 4:21 PM, Nick Connolly wrote: > > > On 05/08/2020 16:13, Nicolas Dichtel wrote: >> Le 05/08/2020 à 16:53, Nick Connolly a écrit : >> [snip] >>>>>>> +    if (check_numa()) { >>>>>>> +        ret = get_mempolicy(&cur_socket_id, NULL, 0, addr, >>>>>>> +                    MPOL_F_NODE | MPOL_F_ADDR); >>>>>>> +        if (ret < 0) { >>>>>>> +            RTE_LOG(DEBUG, EAL, "%s(): get_mempolicy: %s\n", >>>>>>> +                __func__, strerror(errno)); >>>>>>> +            goto mapped; >>>>>>> +        } else if (cur_socket_id != socket_id) { >>>>>>> +            RTE_LOG(DEBUG, EAL, >>>>>>> +                    "%s(): allocation happened on wrong socket >>>>>>> (wanted %d, >>>>>>> got %d)\n", >>>>>>> +                __func__, socket_id, cur_socket_id); >>>>>>> +            goto mapped; >>>>>>> +        } >>>>>>> +    } else { >>>>>>> +        if (rte_socket_count() > 1) >>>>>>> +            RTE_LOG(DEBUG, EAL, "%s(): not checking socket for >>>>>>> allocation >>>>>>> (wanted %d)\n", >>>>>>> +                    __func__, socket_id); >>>>>> nit: maybe an higher log level like WARNING? >>>>> Open to guidance here - my concern was that this is going to be >>>>> generated for >>>>> every call to alloc_seg() and I'm not sure what the frequency will >>>>> be - I'm >>>>> cautious about flooding the log with warnings under 'normal >>>>> running'.  Are the >>>>> implications of running on a multi socket system with NUMA support >>>>> disabled in >>>>> the kernel purely performance related for the DPDK or is there a >>>>> functional >>>>> correctness issue as well? >>>> Is it really a 'normal running' to have >>>> CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES in >>>> dpdk and not CONFIG_NUMA in the kernel? >>> I'm not an expert of DPDK, but I think it needs to be treated as 'normal >>> running', for the following reasons: >>> >>> 1. The existing code in eal_memalloc_alloc_seg_bulk() is designed to >>>     work even if check_numa() indicates that NUMA support is not >>> enabled: >>> >>>     #ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES >>>     if (check_numa()) { >>>              oldmask = numa_allocate_nodemask(); >>>              prepare_numa(&oldpolicy, oldmask, socket); >>>              have_numa = true; >>>          } >>>     #endif >> The question was not to return an error, but to display a warning. So >> the code >> will work (after your patch), no problem. >> >>> 2. The DPDK application could be built with >>>     CONFIG_RTE_EAL_NUMA_AWARE_HUGE_PAGES and then the binary run on >>>     different systems with and without NUMA support. >> In a production environment, it seems odd to have a custom kernel and >> a generic >> dpdk app, it's why I propose the log level WARNING (or NOTICE maybe?). >> I let other comment about this, I don't have a strong opinion. > Thanks - appreciate the input - I also have no strong opinions here and > am happy to be guided. If there is a socket mismatch, wouldn't allocation fail anyway, which would result in an error message? Usually, when things fail, the first obvious thing to do is turn up the debug log. I'm inclined to leave it as DEBUG. > > Regards, > Nick -- Thanks, Anatoly