From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1BC15A0350; Thu, 25 Jun 2020 12:21:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5CA30F04; Thu, 25 Jun 2020 12:21:29 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id F13D5E07 for ; Thu, 25 Jun 2020 12:21:27 +0200 (CEST) IronPort-SDR: 0mc/8sg55Y+RlzR4mAi3n0eHbtjOpjex+Bq8N22Ww4GEF5DVO6gc8zLv05tu66X5d72tV285dO HxfkhlOroBtw== X-IronPort-AV: E=McAfee;i="6000,8403,9662"; a="229549031" X-IronPort-AV: E=Sophos;i="5.75,278,1589266800"; d="scan'208";a="229549031" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2020 03:21:26 -0700 IronPort-SDR: 0TfT8Tj4KIGYDA+TbJ9aD3eTycaP4Bzf2SVmbruAiFoso2h4OCvob2UC4IYyuEwpkmUQyw+S9V +tvQyPU5rkkg== X-IronPort-AV: E=Sophos;i="5.75,278,1589266800"; d="scan'208";a="452958566" Received: from dhunt5-mobl5.ger.corp.intel.com (HELO [10.213.237.42]) ([10.213.237.42]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2020 03:21:23 -0700 To: "Sexton, Rory" , dev@dpdk.org References: <20200518103902.27927-1-rory.sexton@intel.com> <20200518103902.27927-3-rory.sexton@intel.com> From: "Hunt, David" Message-ID: <40553267-8d8d-cee8-37cc-8e9249a9b529@intel.com> Date: Thu, 25 Jun 2020 11:21:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200518103902.27927-3-rory.sexton@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v2 3/3] doc: update vm_power_manager cmdline options in doc X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 18/5/2020 11:39 AM, Sexton, Rory wrote: > Signed-off-by: Rory Sexton > --- > doc/guides/sample_app_ug/vm_power_management.rst | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst > index e98277ccb..dd0f46158 100644 > --- a/doc/guides/sample_app_ug/vm_power_management.rst > +++ b/doc/guides/sample_app_ug/vm_power_management.rst > @@ -410,20 +410,17 @@ There are a couple of command line parameters for enabling the out-of-band > monitoring of branch ratios on cores doing busy polling using PMDs as > described below: > > -``--core-list {list of cores}`` > +``--core-branch-ratio {list of cores}:{branch ratio for listed cores}`` > Specify the list of cores to monitor the ratio of branch misses > to branch hits. A tightly-polling PMD thread has a very low > branch ratio, therefore the core frequency scales down to the > minimum allowed value. On receiving packets, the code path changes, > causing the branch ratio to increase. When the ratio goes above > the ratio threshold, the core frequency scales up to the maximum > - allowed value. > - > -``--branch-ratio {ratio}`` > - Specify a floating-point number that identifies the threshold at which > - to scale up or down for the given workload. The default branch ratio > - is 0.01 and needs adjustment for different workloads. > - > + allowed value. The specified branch-ratio is a floating point number > + that identifies the threshold at which to scale up or down for the > + elements of the core-list. If not included the default branch ratio of > + 0.01 but will need adjustment for different workloads Could I suggest adding something along the following lines for further info? "This parameter can be used multiple times for different sets of cores. The branch ratio mechanism can also be useful for non-PMD cores and hyper-threaded environments where C-States are disabled." Reviewed-by: David Hunt