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 3859B43F38; Tue, 30 Apr 2024 10:42:40 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6B10402A8; Tue, 30 Apr 2024 10:42:39 +0200 (CEST) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by mails.dpdk.org (Postfix) with ESMTP id 037AA40262 for ; Tue, 30 Apr 2024 10:42:36 +0200 (CEST) Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-518a56cdc03so6070791e87.1 for ; Tue, 30 Apr 2024 01:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1714466555; x=1715071355; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4ABYtPbTbrF5ldGhTu6BU0df2aYPtNpEhgJjYML2yq0=; b=VuuPnzoVCtW5slIwg6qxX8mltPHKA0wYHXuTiLdmWtrhSYs2TLELZMlaQIVYGdTCEf Gxn6B4XV4YWPl6hvSB8icWwlaoKgEEU1EvPq3Ws1ubB2jtMnEbV48AsQTUlikk4Ii9DD M7GWExCDdvkNzF+F2RO+aXq4Spt5qsIxdn3oAvvfL5n2vubHtrWk7Nt9e+vp+qzZnXZT 9rTttdXRZ+Xp4FEeR+dL2S0GP9HRS6FlgHcMVpu4LD8sCZca15TMi8IEaJvYxk7d1viD N5zn1IyX0b/ZxJm7Dwbl7i8f2E4aMYXu+U3Uy4xHAucy50/D38ZRAGfGbGi0EPKCpRGb 50HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714466555; x=1715071355; h=content-transfer-encoding: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=4ABYtPbTbrF5ldGhTu6BU0df2aYPtNpEhgJjYML2yq0=; b=dBn4Dest0JO1kHOhnJDC1ZJBDuPMkWkHmsC1iljhPrL0LyzVZGu9q03Ox61A0UreYC lRi1M8jAWQZjqvdQz3xDdbioiLJgQiCuoG4FSFirVlb2+t+dheVJAILfPLn7oDdz+tEm xSgHQgzwtEsXefEK8wCNlei4w+FvsGuYrntiY5SjWrwwuHmkwy4cJmMqUtDzFrvfZqsH oRGUAptBNXt7Gsdt7W6unjqaDj5TS9XieTtI+k7Cs447Edm4df1giNkC3VnIx1F6zj5+ 5ArXYSUpvhxvErg8ekcA2wYX8TbmsYRvoQPLBTmrhf7WghyzUMNm29V6HXqnozsEjJ2G GV9g== X-Forwarded-Encrypted: i=1; AJvYcCUbKAh4im1p5Jfq0kXAZiE3e4jKYggKamNPMp5lJZPfynbUYZDbF6LW95+cOD06YSPPD2LhcW4muol5X2E= X-Gm-Message-State: AOJu0Yz1pUS47nOMtSB7ZepruY4Xh0HI+gw2JiRaqTkmolljz2nwr8Zk if6Ns2Uevm2lnjIhb3M9M6LtZus/Wz0C5X2WNv8fQeL/mty+8QIDbGtOQpKNwRYqAF0mPTV/fF+ aJ1rd9jzHWmDV9o4Xc2kOI9kr/51ESf8LMFFJVA== X-Google-Smtp-Source: AGHT+IFPTQrZLfYWb0FRrKyySnlX90kG9FFYhiNE/IM1MctcaXal9d4VpTYr03Q4B2gS0gKkvnoQC3EQcWX7Mx/MCVE= X-Received: by 2002:a05:6512:1296:b0:51c:d2df:5cb6 with SMTP id u22-20020a056512129600b0051cd2df5cb6mr8442511lfs.68.1714466555537; Tue, 30 Apr 2024 01:42:35 -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: =?UTF-8?Q?Juraj_Linke=C5=A1?= Date: Tue, 30 Apr 2024 10:42:23 +0200 Message-ID: Subject: Re: [PATCH v4] dts: Change hugepage runtime config to 2MB Exclusively To: Nicholas Pratte 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" 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 Please leave the context you're addressing. Reading this was a bit confusing and also hard to understand. On Mon, Apr 29, 2024 at 7:26=E2=80=AFPM Nicholas Pratte wrote: > > 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." > Looks like there's a typo: allocation of with hugepage sizes > 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. > It looks like quantity is used with both countable and uncountable nouns, whereas number is only used with countable nouns, so quantity is also fine. Let's put it into this patch series. > 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. The current expectation, based on the previous discussion, is we won't be needing any logic, so I'd just make it a class variable (defined in OSSession, as it's the same for all sessions). We can change it in the future if we uncover a case where we might need it.