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 BD98EA050D; Tue, 26 Apr 2022 23:21:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 93CCC40E78; Tue, 26 Apr 2022 23:21:29 +0200 (CEST) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mails.dpdk.org (Postfix) with ESMTP id E9C9C40691 for ; Tue, 26 Apr 2022 23:21:28 +0200 (CEST) Received: by mail-pg1-f178.google.com with SMTP id i62so4897155pgd.6 for ; Tue, 26 Apr 2022 14:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2HLKpNt2fKLatAE6ZmaIDoYToUJOPJbN8aWbemdgzvQ=; b=uRcRVF1wbLrZh+cWTCyOxpE1NG5f/T7KH/qA7BdJ1m9y1fxkXqvA+ps1yNwjZEdw9D s3Lg7B3UDbqumYZH4lR+Ys7NpKfsA53GEHK/1zKI9GZbnjqfXi1WFax2IYjK2prIhtc5 iMCnDZ0Epgoe7pKIkg8QPRl32y8e2sUUk6Ulf01WaQcHDCDiriYWZJVt7GyhGeAVtUzL RGZyHWh6NREQzECR+vVXGJj4TlrBa9ePHe9tfBwTFNyUl3WNCtXsnb2H4ltr2bequjnG tkso44RtHISe8UaTRNWCGIfXvc0hz2zG6WOTQo6vIa/LxVUrJ7JKdqz9TcTPm59QqSAY cVAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2HLKpNt2fKLatAE6ZmaIDoYToUJOPJbN8aWbemdgzvQ=; b=yL1brWiQum6L4jxXTxYE0xxP7reBstZh9py6JtUSh9H/ZqGRtaAY+x2eVO4gL9Azb4 LxtTL7i2p8xWSiGNog3/6mJ8MSv5RGU4y7NqzeQZET5TqMS3SWB5vojVY8hA4kM3l8WU ZCN3hfhjcwbatxHIR7FRgRueiRDkfMdOFvZZMzp7HhJb37FjQ8T/z3lTUvzloWvxazMJ xcTQsYeQYUDf8usTP1ErskOBLgednTB5xBwVo137W4O+cJS2NJ1z+VY6vbj7ubPIfWqi bfiRTiGCXmS80GEsPib4TQH7jADHvxg8Bq8QfjcnxNcB2Qww9vXH+rVGoPb7qOnT9hN5 eYMQ== X-Gm-Message-State: AOAM530e4m/zStlgwmBkMT3QIpvnjMvTXCS0qEGRhsyWcLZ56C5Z4iwy b6+dacbieBa4g0Jvl3yms6G0ZRCwLtlvgw== X-Google-Smtp-Source: ABdhPJy9miMNLh+DsK+SGHLi09whNpZEIlt4+FMDEjh6qFY/cG7d8SyPnoP3dP32c696xB1AySykzQ== X-Received: by 2002:a05:6a00:ad0:b0:4e1:2d96:2ab0 with SMTP id c16-20020a056a000ad000b004e12d962ab0mr26531637pfl.3.1651008087935; Tue, 26 Apr 2022 14:21:27 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id i23-20020a056a00225700b0050d38d0f58dsm9401263pfu.213.2022.04.26.14.21.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Apr 2022 14:21:27 -0700 (PDT) Date: Tue, 26 Apr 2022 14:21:24 -0700 From: Stephen Hemminger To: Don Wallwork Cc: dev@dpdk.org Subject: Re: [RFC] eal: allow worker lcore stacks to be allocated from hugepage memory Message-ID: <20220426142124.524069c5@hermes.local> In-Reply-To: <53a03de6-fb78-986e-64f6-890b08321343@xsightlabs.com> References: <20220426122000.24743-1-donw@xsightlabs.com> <20220426075858.2c28f427@hermes.local> <53a03de6-fb78-986e-64f6-890b08321343@xsightlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 26 Apr 2022 17:01:18 -0400 Don Wallwork wrote: > On 4/26/2022 10:58 AM, Stephen Hemminger wrote: > > On Tue, 26 Apr 2022 08:19:59 -0400 > > Don Wallwork wrote: > > > >> Add support for using hugepages for worker lcore stack memory. The > >> intent is to improve performance by reducing stack memory related TLB > >> misses and also by using memory local to the NUMA node of each lcore. > >> > >> Platforms desiring to make use of this capability must enable the > >> associated option flag and stack size settings in platform config > >> files. > >> --- > >> lib/eal/linux/eal.c | 39 +++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 39 insertions(+) > >> > > Good idea but having a fixed size stack makes writing complex application > > more difficult. Plus you lose the safety of guard pages. > > Thanks for the quick reply. > > The expectation is that use of this optional feature would be limited to > cases where > the performance gains justify the implications of these tradeoffs. For > example, a specific > data plane application may be okay with limited stack size and could be > tested to ensure > stack usage remains within limits. > > Also, since this applies only to worker threads, the main thread would > not be impacted > by this change. > > I would prefer it as a runtime, not compile time option. That way distributions could ship DPDK and application could opt in if it wanted.