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 2253FA0507; Fri, 29 Apr 2022 21:03:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E28FF415D7; Fri, 29 Apr 2022 21:03:31 +0200 (CEST) Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by mails.dpdk.org (Postfix) with ESMTP id 7FC16410E3 for ; Fri, 29 Apr 2022 21:03:30 +0200 (CEST) Received: by mail-pj1-f46.google.com with SMTP id d23-20020a17090a115700b001d2bde6c234so8359725pje.1 for ; Fri, 29 Apr 2022 12:03:30 -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=xYkycNKHbIxISSNvaZ7au4YcONhyxmjgayw+tw8SJ5w=; b=tXXWv38KsWAtmEJVdnfPJL7Tzjb/abhHsVzUvsreF4PAeHPexo8f8wlM4ROTjeF10z cUxOcncrUoeATeFv5Vrqyz7LaWtVTQNd1CaIC44OB01176e+31C2auUZg8E5sevDJvcW ONdo/Ue3AcwJr5L40WuGPfiM6UT+zicah4fEfOy3Quj7dINCXIGkW5y9X1ommB0/ebbX EuNDuIDg9wUAHSASFeauPzlj1zm43dQoB1gUR01Ibl4BRnnOSljAphGRm72/S21Pcn6n cwpsyj3v3bii/ijtFKJSThOwGIih/gCDEBInZobTZwWW7+uuT/HsZJHUtwTrRWLiRrNW gsQQ== 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=xYkycNKHbIxISSNvaZ7au4YcONhyxmjgayw+tw8SJ5w=; b=lLtkUxkzZiCcbJb7rzGLmrGrCi3UNvDQb8qnFRvrGcuQWVCB/2ozV3k7iyJ36WMQfY lLHVFbAA51B1Ns2KjMAmNevi2sVbzw9fm6VHpUkApYdkWs8HS8Zv/MPZ4KBwxmaonfB4 Q+dEJ64GR2LYYTXbP9yAk1bxKr9kxul4qkh0SXdgIhcs4yitkG0d+OKKEfuE9V486VdO mqq7YMgGA0AffL0GDsIdAWu4Jo36W/WpPFMWpCrM+QuMjhGQ+duPjPggESVxLtzxN/zG 3VjAOZ/0F9vxNVv0gSjM5ez//aUAnCDFuRjD5xbIr4DzAj/4gh4PBzTp2Y3AAdI9PByq J+iQ== X-Gm-Message-State: AOAM530JJlGFvNK9RJwYKjQ3YGtkaL1ciKSciIWCxcQkw5ZuafkBN0Ff +B25rhOl4Pwu3/aU+wPVEifZzg== X-Google-Smtp-Source: ABdhPJxxb5hHylcr0wo/jwLpr9JtNXh3VeRfwGiATacswt0nHCO3ZvYUSboCvpVMyoBQm6r3Sj77bg== X-Received: by 2002:a17:90b:694:b0:1d9:6a2e:bc9 with SMTP id m20-20020a17090b069400b001d96a2e0bc9mr5423272pjz.169.1651259009736; Fri, 29 Apr 2022 12:03:29 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id a24-20020aa780d8000000b0050dc762813fsm4892pfn.25.2022.04.29.12.03.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 12:03:29 -0700 (PDT) Date: Fri, 29 Apr 2022 12:03:26 -0700 From: Stephen Hemminger To: Don Wallwork Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , Anatoly Burakov , Dmitry Kozlyuk , Bruce Richardson , dev@dpdk.org Subject: Re: [RFC] eal: allow worker lcore stacks to be allocated from hugepage memory Message-ID: <20220429120326.4c56227c@hermes.local> In-Reply-To: References: <20220426122000.24743-1-donw@xsightlabs.com> <20220426075858.2c28f427@hermes.local> <53a03de6-fb78-986e-64f6-890b08321343@xsightlabs.com> <20220426142124.524069c5@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35D87006@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Fri, 29 Apr 2022 14:52:03 -0400 Don Wallwork wrote: > >>>> > >>>> The expectation is that use of this optional feature would be limite= d to cases where the performance gains justify the implications of these tr= adeoffs. For example, a specific data plane application may be okay with li= mited stack size and could be tested to ensure stack usage remains within l= imits. =20 > > How to identify the required stack size and verify it... If aiming for = small stacks, some instrumentation would be nice, like rte_mempool_audit() = and rte_mempool_list_dump(). =20 > Theoretically, a region of memory following the stack could be populated= =20 > with a poison pattern that could be audited.=C2=A0=C2=A0 Not as robust as= hw=20 > mprotect/MMU, but it could provide some protection. > > Usually just doing mmap(.., PROT_NONE) will create a page that will cause S= EGV on access which is what you want.