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 66A30A0093; Mon, 2 May 2022 15:15:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1281640F35; Mon, 2 May 2022 15:15:44 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140054.outbound.protection.outlook.com [40.107.14.54]) by mails.dpdk.org (Postfix) with ESMTP id 9C7A340E28 for ; Mon, 2 May 2022 15:15:42 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oZKtJJe6oSGLVzHED3v3w1bHuCuZVSyX0GnCeani/xJskXjgpaWaTJQyfQ2wj+p406UaREv6+oGRL5//PxXNC5mAmRxmA4btegVPSLppVih+JxorQF3ogJV5yghvzr3hYQZAmw4gWeE0r7ouU8SWqkflqXoLpd9ly3qB8PwFzbiKwQ6c0CovMf5ekYwB329M6YOuy+i0ytjyDOOz7zFqdlGVIJzdEmqX3JDqt0JuaEKgItbue7R7n3Tvm3Dlx9XG8Uac08cEbYJmto8X6dfE0PdxhwCXRQuFs/hjJVhbVwAo5DGMj9DyWMiRisN1yDiBkZtlTbXjIGFR9PbV3qP4ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=el24+AO8HOSh0LlEZXjzQje9VWjmgJUVvbrcE3tlYcI=; b=W1wY8IiQV7ohyp6efFQXtlEnzTd7K2FbaHY8ubJatB0zTnAvwwQiuHOUv4pkWvqUZDjTA0o9MPQIPjecnfi76dpx+mBm6NgTtMJcgEybD14o5iXj5KRB8R03gc4NWLIHHvTpiFsgBfN2txqzQmwRttJcYHb4FsrXIaws0CQqN131jWqfc/08v2rHpiBZsPBSeAo9F8WMmIQAFbfufH+kXP9pQnnmqTkWeofRGWz5tSTE15vIppUO1DHHFs8T32FQhnIWTyH3MgvWOmkGCWCe/uTwUfb92e3apni3h7Hh6cE1FS8x6WEwXCkrZPu8R3aROQA3Nd+Ba5+dnmGcU93DuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=xsightlabs.com; dmarc=pass action=none header.from=xsightlabs.com; dkim=pass header.d=xsightlabs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xsightlabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=el24+AO8HOSh0LlEZXjzQje9VWjmgJUVvbrcE3tlYcI=; b=fsvSEoxX9V7PrcI/iI0SCOt/7QEUgtJpAwUSfjkjTOUQ1kuzpbh5fCQZBOrm4bnUqGjHSAlxK4vYdQGsWiRA1SOO7ngSBnq6MP5+tzUqAfovUeREZew7WZnox4VgXRn7dvtCKorWszivgFxavJMF3c94lr9kk2j3t8HS/ZfaaDg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=xsightlabs.com; Received: from DB9P193MB1482.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:2a6::7) by AM9P193MB1491.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:306::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.13; Mon, 2 May 2022 13:15:41 +0000 Received: from DB9P193MB1482.EURP193.PROD.OUTLOOK.COM ([fe80::3c11:328c:a5e5:7253]) by DB9P193MB1482.EURP193.PROD.OUTLOOK.COM ([fe80::3c11:328c:a5e5:7253%5]) with mapi id 15.20.5206.024; Mon, 2 May 2022 13:15:41 +0000 Message-ID: <064b6e35-0e49-a96f-cc16-cbb02a67009d@xsightlabs.com> Date: Mon, 2 May 2022 09:15:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [RFC] eal: allow worker lcore stacks to be allocated from hugepage memory To: Stephen Hemminger Cc: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Anatoly Burakov , Dmitry Kozlyuk , Bruce Richardson , dev@dpdk.org 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> <20220429120326.4c56227c@hermes.local> From: Don Wallwork In-Reply-To: <20220429120326.4c56227c@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1P189CA0005.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::18) To DB9P193MB1482.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:2a6::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f6754e33-1784-4faf-0bef-08da2c3ddb47 X-MS-TrafficTypeDiagnostic: AM9P193MB1491:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sh1ANj0R52a3fBErapWlszmeizL3ACCNb6yniDC+2RL3zKQ31NF3XqT9nAU0wDGnsN9X5u7Rmbb4sS+fhsWN9hQynBg/pPRQSNaAPmFGftdeTN7Ape5FVev28bZ5ZoGx520u4djzEp4JMjtfRiHBgwi8LNwdpPzIiRlgoyQ/RVOrgiejBGKUCBQjsALDloDfLS9fKB/kQAEvAE4l7Hdo/CwGFtEhw/o1Msxkkigp0m11iIt9AFK44SAwhsUkdjlR5V+LfO9IIsXy1uUKFUkdLb+2ER0Z6mtN3JaVwdS3Yq/3dlkR23I3aT2hbGDTxwOiJtk7oPK6XZGuibHrKp26UvQiXwRzZ+x9ehH7vodyYX++8BSxWeEopnVFRl0R/tdEoLIw2ckmSWbymaNkZca57tyCtjRumoNdqAM8OjrbiO9BDy/tyw05TX4+GkHrlRr/9DeZn4bJAF6Bk2Y9BXV88W1ttYH12tIWUmrUAFaelpfMXbKfDwIelTDYW5ng3aQK8NZ6X/IHVJUVelPZM79CfXXHzqb6bUJuksOnOtOjwCPOdOEdKRKivhfBGtcSNIwuGMCYuX1m4aJerdnsaUl0aOIoiQc3uZJJ2do5cKRFl0ZCJBb686r5LPx+ctNB/qZJT9VKHarkaBPv0fWOhRdzgBR8J1GH6eFCnU/T8dcISuU/wN9kYwgZv4SlKfc2ZmcwblvqYXMLh4XnPCR0nSMEAdNzY16AUmfOiH8GKVadvvDgnyjeCjSamCAXk0uq8qXIHhHATApP1gj/9wMCGDdwBw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9P193MB1482.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(8676002)(66476007)(6666004)(66946007)(66556008)(53546011)(6506007)(4326008)(2906002)(38100700002)(5660300002)(38350700002)(86362001)(8936002)(508600001)(26005)(31696002)(6486002)(6512007)(83380400001)(2616005)(54906003)(316002)(52116002)(6916009)(36756003)(186003)(31686004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U0xGekxUNnNRczAyMnVTZUtxYUR1TWVQRTgwL2M3K3FwTWFZRXFsbHJiMHpz?= =?utf-8?B?MStHaStsNmJ1Tk9lWUF4Q0lBUlNVL1VWYS8xUUJ0cE1TcTJSVldvL1NkV1Bu?= =?utf-8?B?VFk4NXVOU2IrenNoTXNBYjFxQ29NZzJURkJmVEZHQUJIVkhkbTQyN2NKelp3?= =?utf-8?B?ZTNJWjZrRFhXM0V3L0EzZUhES1VSYVB6cVpuQ2x3dWsxeVdQclVCSVpQejhL?= =?utf-8?B?a0tOb3FtVmcxRVpCVm9BbFhJeCtERDJMOXJnUmV4M0plVkRkT2cxYlFMclhl?= =?utf-8?B?YVU5d3JqZmFvU2VYUG1OM2JlbU03Uyt4bm50QkxSYVlCZjFranVDWUUrdE84?= =?utf-8?B?blY1SHpGaEtaMndhUWpIQ052a0I1UzJySDFjeS9iZ3k4aXptb0VwZERlU2Uv?= =?utf-8?B?UHVIT1BVY1E4MUtsaEdiais4ajVYd0t6TENvZUN6d0hvYU4yRWVSb2JvaEF4?= =?utf-8?B?WEJMODN6S20yRkxZSkRnL2s1ZkExN2c0c3BEYVkwRzZITEl2ZGkwbVRsd3hY?= =?utf-8?B?MG13USswVEZnczJCcXJrVmF2aXpyR1JpS0hNcFhoUTMxanN6YlZoV29MN1Yx?= =?utf-8?B?NlVINnB1bkpuYWxVb29oUXQ0am9EOHVldFRuS3VPUlRyd21ZWUtmNHJKK0Rl?= =?utf-8?B?K1FKWkhRdnVEdFUxQ0UxbFJsWGFXMVNsNWpNWitJWktnN0dybHg0WFRkTUtH?= =?utf-8?B?NC9nYXRDajRnVTh4WWRXS2N4MEQrNmJacElnaUpXT3V5Nk5iTlIySEZoZXNG?= =?utf-8?B?WUJzc2ZVd3J3SVptOGZGUGJBTEhuOFV6YWM5M2wyYjJKck9ReUdKRXExU053?= =?utf-8?B?L2c4SEVmc0lHTWt4ZFY2Z2l6ZVE3dHRmb29Mb0dDcUNFQWdsd1JrRmxOTmxl?= =?utf-8?B?L1BDT21QbVAwTlRCUTJWUVo3QVJvVHdUV3pRM0x0WXlBMk9EeEZIdXZ1emsy?= =?utf-8?B?L3dTbi9zV1BSVFFzT0pMY0VBZGUrR1YxWGdWNDBSSTF3RzZNWWI1UWFXdkNj?= =?utf-8?B?c2tTZEVNTG80czJ3UVpkV1luYjkwdTluUyswOHhuMS84NHlrMVMxbFA4OFE1?= =?utf-8?B?b2p0NXYwMHdES0RiNzBmRFcweHdjZGJiMWFyTlN1anJPaHhGT21ZdTVNTmRw?= =?utf-8?B?cXZSWGJodUlFeDhrM1RBWm83UWYwLzA3bE1BNDl5UzNtMzF3S01hejc5aVNO?= =?utf-8?B?cXdRL0tBNFNNaUFWVTVZTlRCS3pEUklYRmlXWGROdVlSZWdlS1lxSnU0U214?= =?utf-8?B?djdkbE9DWWJvZTFCcXI5N00wanVtSmNYRGJUNm43M1BlcTR0VnA1TCtnN3FQ?= =?utf-8?B?V01OR1p4VThBU0s3cGFOemtBK3cvWWhabGgrNjlSWGFzaWVwZVBxU2hqYUY0?= =?utf-8?B?WEVWakRneUZnNXNWUUFpZGYyTUIwT3hMT09kNGNvQjlwbDljSjNaRnJkM3JR?= =?utf-8?B?VDhpUTF2elltN1BwMExrL05pNGEwRkZDeGJtN1Y3RmR1Q21SRHAwTW1JZzdz?= =?utf-8?B?U2x3WmwycGQxZkpMdml1VnBwVFBZWnVIN0xPMHhCQXlmYjd3ak5ZV3VWQXVS?= =?utf-8?B?UUVqbFh2dnF0MHdFSGdobktjQmhCQ1c3UTVheEVaWU43VWpkd3NuVzZmM1Vw?= =?utf-8?B?eFZlaHNoVEhSWUprallxckU1QTBFR0J6SWt4NWNWZGd6N1Z1cUZFaXlZK0pv?= =?utf-8?B?eHg4WUVpZnV5MTRaTExBOVFadFlTTERMcTJhU1VJVGtLaGh0OFZuMnRwbVJO?= =?utf-8?B?ZjVpak9uRU9FSjA3TENPWU5pWjZkNXgwck1LWTNzeVZjQ0tqMDFYLzRBczNI?= =?utf-8?B?Uk5EdFZvZUlORDU5QjFQbFg0b2hxb0w2ZUxISG1hak1jYm1zUitQSXorN3BS?= =?utf-8?B?bzJUQWVyY3o4NTBOaTVpbHcwRnRVS0dCK2U4V295ZU5vRWlpT3E2MTRGUU90?= =?utf-8?B?TGxkUVFPRks1a0EwSEZ3WmhwYy9INlRLWTQzZ0lRajQ1b21zNXdWcjFLeURs?= =?utf-8?B?VEVlQnhJeEh4N0pkOUNDZzk3a0o3RWxrcm5pRVVaTG9EWGVodE9ibGd3T3Rq?= =?utf-8?B?clZzMGcyTGhWM29va2s0QW5JWEtzM0NIaEtSMlhwYy9GbnNvSEJuTXZSNVA0?= =?utf-8?B?b2w3MG5rN2RiczllY3lNV1lmcWY2UjJUN2JjZTdXek5IR3ZIcEJqTmRQTU54?= =?utf-8?B?K3JSd1NySGJJODlnanNISzNXeDZRZjBmaDRzVWJqdjJCZVo3UU9leGZCclVC?= =?utf-8?B?SURyci9MdXlxZnVxaHdkcjN3bktiYmJySGcvd0tDOHZCaGV1MmFEczJhSlhF?= =?utf-8?B?WHg4VnYxSit0b1E3ZjRWc2J3bzViN2FpZnRnM3VWbzcwOEl0YXZQZz09?= X-OriginatorOrg: xsightlabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6754e33-1784-4faf-0bef-08da2c3ddb47 X-MS-Exchange-CrossTenant-AuthSource: DB9P193MB1482.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2022 13:15:41.1246 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 646a3e34-83ea-4273-9177-ab01923abaa9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7dfzfY257JYRHHnTCKhM9NLCrKeFjjZySoNFrmpXA5xPCkuJaM76oZ2juOISG2aSBlePUSiS5SY4u7aSg2Xytg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P193MB1491 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 4/29/2022 3:03 PM, Stephen Hemminger wrote: > On Fri, 29 Apr 2022 14:52:03 -0400 > Don Wallwork wrote: > >>>>>> 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. >>> 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(). >> Theoretically, a region of memory following the stack could be populated >> with a poison pattern that could be audited.   Not as robust as hw >> mprotect/MMU, but it could provide some protection. > Usually just doing mmap(.., PROT_NONE) will create a page that will cause SEGV on access > which is what you want. As mentioned elsewhere, the problem with this is we don't want to allocate an entire hugepage per stack just to get a guard page. There is a simple way to verify this.  If the application is run without the hugepage stacks option and it does not seg fault, then we know it is safe to run the application with the hugepage stacks given the same thread stack size.