From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id C22755688 for ; Thu, 13 Sep 2018 11:46:13 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1B0B8308404D; Thu, 13 Sep 2018 09:46:13 +0000 (UTC) Received: from ktraynor.remote.csb (ovpn-117-56.ams2.redhat.com [10.36.117.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id E9EA02010CAA; Thu, 13 Sep 2018 09:46:11 +0000 (UTC) To: "Hunt, David" , Radu Nicolau , dev@dpdk.org, liang.j.ma@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> From: Kevin Traynor Organization: Red Hat Message-ID: Date: Thu, 13 Sep 2018 10:46:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <6a62972e-ddf4-c45a-88f9-170bc904e7f3@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Thu, 13 Sep 2018 09:46:13 +0000 (UTC) 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 09:46:14 -0000 On 09/11/2018 10:19 AM, Hunt, David wrote: > Hi Kevin, > Hi Dave, > > On 27/6/2018 6:33 PM, Kevin Traynor wrote: >> On 06/26/2018 12:40 PM, Radu Nicolau wrote: >>> From: Liang Ma >>> >>> 1. Abstract > > --snip-- > >>> 2.2 There are two phases to establish the power management system: >>> >>> a.Initialization/Training phase. There is no traffic pass-through, >>> the system will test average empty poll numbers with >>> LOW/MED/HIGH power state. Those average empty poll numbers >>> will be the baseline >>> for the normal phase. The system will collect all core's counter >>> every 100ms. The Training phase will take 5 seconds. >>> >> This is requiring an application to sit for 5 secs in order to train and >> align poll numbers with states? That doesn't seem realistic to me. > > > Thanks for the discussion at DPDK Userspace conference. Since we got > back, Liang and > I have discussed the feedback we received, and we have a proposal. > > We can split out the training phase into a separate run of the application > which does the training, spits out the threshold numbers, and then > the actual runs will start instantly once the threshold parameters are > provided on the command line, or falls back to hard-coded defaults if > no command line parameters are given. > > So there are three ways of running the app > 1. Run without any threshold parameters, in which case the algorithm > runs with default numbers calculated based on the min and max > available frequency. > 2. Run with --train option, which requires no traffic on the NICS, and > runs the training algorithm, prints out the thresholds for the > host CPU, and exits. > 3. Take the output of the train phase, and provide the thresholds on > the command > line, and the app runs with the best fit to the running CPU. > > That would eliminate the training period at startup, unless the user > wanted to fine-tune > for a particular host CPU. > > Would that be an adequate solution to the training period concerns? > 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'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. I have a few comments on the API, which I'll reply directly to the patch. thanks, Kevin. > Regards, > Dave. > > > > > > > > > >