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 BCE5843F47; Mon, 29 Apr 2024 19:26:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 51FBF402A3; Mon, 29 Apr 2024 19:26:44 +0200 (CEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mails.dpdk.org (Postfix) with ESMTP id 6D0394029C for ; Mon, 29 Apr 2024 19:26:42 +0200 (CEST) Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2da4e54549fso1982651fa.1 for ; Mon, 29 Apr 2024 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1714411601; x=1715016401; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZKw06dGNBYXOar7l9GzESAYVyPELLMoW1QDxx4Rlt5A=; b=WCDJ5CYfs6aGXQsankDxfASKwzuthzoPz9Ev5oPTrqxpQD1SiCN14gJnKBEX6OqYaF 6oRbVXxEVQ+0gIMfLjO0w/j7A9Yj/NKNazLw29XvDartGtBpIxbv9WUFMkU1qim39/fc fhySjsUj0inT09YW8Lehps0fOmlxf7LKlAfGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714411601; x=1715016401; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZKw06dGNBYXOar7l9GzESAYVyPELLMoW1QDxx4Rlt5A=; b=Hkv39ijMk6eDcWH28SdMAKtuZAv9eJdP8kVrzkgxgQU81e/sdNNadP93gjZWwsk2St nliMUCPiVrJ8K8dXa8HvGSzC/CotyB5E0dCrwRs7ykRCvJ2DVaPVvhQJamBUBuriVh6k CRLtbgFji5byTpQKS7tv2D09tJIoXXIRQAOqYXx/yeXHk6VUv/TwZGe/rmWP+unMa+m2 IDjQ3t8A/InE08CW6W6MIOc+ZYPf9GqSpeW0wIqs7h4EBccTQXTvF/6b4OM53c27p/Lk P6Ysp3xJcbesegBZ6I/7oWT7AfoFTBHE2IgeOQSQZHk2fAQuHGtd1SR2BtDPk5XkzvI6 AW/A== X-Forwarded-Encrypted: i=1; AJvYcCWZziTrh/NaQewpe+7yqx+HSusgws7esQAYD+jW2+P8g8w2xf6catZIg85ZPUBLjxRigXe5UAgOPmvvIvw= X-Gm-Message-State: AOJu0Yzt2RwffgFCyzj6xIlDfTa71SahHB9DeplM3p4i0vv5ZO7zHBAU RfEPyg3aDLkz/4BVylQk5Rxpkz9NuM7FKHdfOyItmcE2Y1KMxo5Leu5bISZX54tbVe++5Kb8kvk 3+LdScn5mNKNZa88dWZW2RjUBCZH816E5ttz5ZA== X-Google-Smtp-Source: AGHT+IHeLTal+bl2i1aQK3BPWhoNh9ZNvTeFj4tAwRN1OjkvGtokO9SJLr/2BDoYnO1gN0XJhgNeAGUVcfmb/YT+ROc= X-Received: by 2002:a2e:9e0d:0:b0:2e0:5d7:a3b6 with SMTP id e13-20020a2e9e0d000000b002e005d7a3b6mr3320489ljk.0.1714411601477; Mon, 29 Apr 2024 10:26:41 -0700 (PDT) MIME-Version: 1.0 References: <20240404153106.19047-1-npratte@iol.unh.edu> <20240418161026.2839-1-npratte@iol.unh.edu> In-Reply-To: From: Nicholas Pratte Date: Mon, 29 Apr 2024 13:26:30 -0400 Message-ID: Subject: Re: [PATCH v4] dts: Change hugepage runtime config to 2MB Exclusively To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: jspewock@iol.unh.edu, wathsala.vithanage@arm.com, Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu, thomas@monjalon.net, mb@smartsharesystems.com, bruce.richardson@intel.com, yoan.picchi@foss.arm.com, paul.szczepanek@arm.com, dev@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 I fixed the docstring under setup_hugepages in os_session, and I also made a quick fix to the dts.rst documentation. For the dts.rst documentation, I think the following changes make more sense, based on the concerns outlined: (here is a snip of the documentation with the change I made) "as doing so prevents accidental/over allocation of with hugepage sizes not recommended during runtime due to contiguous memory space requirements." With regard to the wording used for the total number of hugepages, I could change the wording to either "quantity" or "number;" I think quantity makes more sense and is less ambiguous, but I'm curious what you think. With reference to your comments about putting this in a different patch set, I think a good argument could be made to put this kind of a change in out currently existing patch, but I understand the argument at both ends. Personally, I am in favor of adding this fix to the current patch since we're renaming key/value pairs in the schema and yaml already. As far as the property is concerned, when Jeremy and I discussed how to best implement this fix, he suggested that a property might make more sense here because of the potential changes that we might make to the default size in the future (whether that be by OS, arch or otherwise). Ultimately, we settled on inserting a property that returns 2048 for now with the understanding that, in the future, developers can add logic to the property as needed. Initially, I had the hugepage size configured in the manner you described, so the property implementation is not something I'm adamant on. I can make the suggested change you gave above, or alternatively, if my provided reasoning makes sense, I can insert a comment exclaiming the existence of the property.