From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0AED57EC7 for ; Thu, 13 Sep 2018 15:30:21 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 06:30:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,369,1531810800"; d="scan'208";a="88444601" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga004.fm.intel.com with ESMTP; 13 Sep 2018 06:30:04 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id w8DDU39W007360; Thu, 13 Sep 2018 14:30:03 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id w8DDU3i2001065; Thu, 13 Sep 2018 14:30:03 +0100 Received: (from lma25@localhost) by sivswdev01.ir.intel.com with LOCAL id w8DDU3Qp001061; Thu, 13 Sep 2018 14:30:03 +0100 Date: Thu, 13 Sep 2018 14:30:03 +0100 From: "Liang, Ma" To: Kevin Traynor Cc: "Hunt, David" , Radu Nicolau , dev@dpdk.org Message-ID: <20180913133003.GB6867@sivswdev01.ir.intel.com> References: <1529505898-6458-2-git-send-email-liang.j.ma@intel.com> <1530013217-22300-1-git-send-email-radu.nicolau@intel.com> <014ba7a7-c9a7-86da-e705-a688e53b83b3@redhat.com> <6a62972e-ddf4-c45a-88f9-170bc904e7f3@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [dpdk-dev] [PATCH v4 1/2] lib/librte_power: traffic pattern aware power control 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: , X-List-Received-Date: Thu, 13 Sep 2018 13:30:22 -0000 Hi Kevin, Many thanks for your feedback. Please check my comments below. On 13 Sep 10:46, Kevin Traynor wrote: > > Thanks for following up. It's allowing it to run without a training > phase which is what I thought could be problematic from an application > view, so that's nice. I'm not sure if it's much less effective without > that training phase etc, but the comment was focused on having a forced > training phase, so that is resolved now as it is not required. > I have re-worked the patch, therefore, the simple app will run without training as default option > I'm still not sure I see the use cases for the options where there *is* > a training type phase but it's difficult to know and considering it's > experimental, if you feel there are some potential use cases and > justification to add it, then fine with me. > However, the Training still is necessary. The mechanism need 2 anchor point. 1. The max empty poll the system can reach without any real traffic. That's is Maximum capability we use as a base line. 2. When the empty poll number drop to zero, that indicate the system is 100% busy due to always get work to do. 3. When the empty poll number drop to certain point(e.g. 30% of Max) the mechanism will move to next frequency. Without the Training phase, it's very hard to use normal traffic payload to get the absolute anchor point due to the traffic type, payload size, processor micro-arch, cache size etc, too many moving parts. I use default value which I think will be OK for mainstream xeon. if user use a very different system(e.g. arm), they still need re-run training phase. the training can be triggered by a parameter option. > I have a few comments on the API, which I'll reply directly to the patch. > > thanks, > Kevin. > > > Regards, > > Dave. > > > > > > > > > > > > > > > > > > > > >