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 85D95A053E for ; Wed, 5 Aug 2020 17:13:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5805F1BFF5; Wed, 5 Aug 2020 17:13:41 +0200 (CEST) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 50FEF37B4 for ; Wed, 5 Aug 2020 17:13:40 +0200 (CEST) Received: by mail-wm1-f65.google.com with SMTP id p14so6152599wmg.1 for ; Wed, 05 Aug 2020 08:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=reply-to:subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G+vMNnTJqCee3790nx0o+ORwhFp/HE+TScFn4UDO9yI=; b=ME1V5uf7W1M0IS8JDCu5GGoWtZIufFfRw73mGCB1SreGagHHpCTiDNnI+1UQM5PoDz YWS5OELbAgzJeVKKlYrHGjbCpokG04UATyk7APBaXMR/Ua2pobK2MtonsDfTXg22g6wp tEM6pfpdDg66fRelZoIjr9NWwly/l2B4pKIYULIDAwrt9+m7W5C0jZ4cKklR5Pt+KGzc k0BxgVDDfs8V4E7QbpvC6U5wzFjMbh1rEBzpUrhX/LCA7ZhhnknTd6b+cGfJksdbwkA4 +nhhlyz2PUSgpVR8C0TTjjAR4JDBp/5uHQbeUYE1bwCcDOQUcX5COnVOLBUzFQFEpM0X YdnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=G+vMNnTJqCee3790nx0o+ORwhFp/HE+TScFn4UDO9yI=; b=sRFHlLrsqrR42f3XUb0gT7o87aFVoTy0okquw+nv1+Ol6FSTRd+E/WOMBNybIJETPa 2nkxTsevVMUIEI8T67GTfeyqgNuxNinIt/9Z13roIIQNzXy/yHGoREOTZZTSH3bAyyNZ SGQuRB4aDMwq6wK6sMBwCvwhZtvzHVBt7qrY+YSOrqT+bfvqQ7TW+q7Q6Suw/7d757qp eKtmhG6cZ8BhV6X5dIEN9bxRlwevtbjKO7ZpaJz9Dy8GZQgphmcmbrnwDhZaZk8KT/Qb QVS5y82jnYbQ+B7hpmabpeNHcFep1omA00mapzQsKrhKm4VZZUaRwAo1COUmKDrvRO93 zi/w== X-Gm-Message-State: AOAM5305Fj5NOvthK5G6mezL+A0FeG0tHzacQWrtukhV37hRUgupzG7J SeSfIcAk1huDwY2ModOE9sRSKi63qyY= X-Google-Smtp-Source: ABdhPJxcA3o0aZojvb+IeqA/l15ROuez7ko1lf42BVCQITK3JCy1ZM+v/aUKMYwTuLa7bego4bz4+A== X-Received: by 2002:a1c:ed15:: with SMTP id l21mr3539307wmh.37.1596640419265; Wed, 05 Aug 2020 08:13:39 -0700 (PDT) Received: from ?IPv6:2a01:e0a:410:bb00:1829:7379:df21:bd9? ([2a01:e0a:410:bb00:1829:7379:df21:bd9]) by smtp.gmail.com with ESMTPSA id t11sm2890910wrs.66.2020.08.05.08.13.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 08:13:38 -0700 (PDT) To: Nick Connolly , Anatoly Burakov 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> From: Nicolas Dichtel Organization: 6WIND Message-ID: Date: Wed, 5 Aug 2020 17:13:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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 Reply-To: nicolas.dichtel@6wind.com 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" 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. Regards, Nicolas