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 A3D03A0093; Mon, 15 Jun 2020 13:32:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 022614C7A; Mon, 15 Jun 2020 13:32:05 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 37D0A1023 for ; Mon, 15 Jun 2020 13:32:03 +0200 (CEST) IronPort-SDR: i1YwK6k08dwvYPWUm6R0sBcQXYogjB5iD5buYqkVQi5TRxaPcb8lL1ERqPv2BCfJ8rGgxT55xV DJC78Wv+ikMA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2020 04:32:02 -0700 IronPort-SDR: Z3x0vdkG1nZ1Az1FlCVjQxIXfJAGxu6rk/P+kVJJT0B0PgAZgweoIp6cu/qF/hsx/0Mt5NoZn/ 1BvWOm46HvjA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,514,1583222400"; d="scan'208";a="475984205" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.251.93.100]) ([10.251.93.100]) by fmsmga006.fm.intel.com with ESMTP; 15 Jun 2020 04:32:00 -0700 To: Harman Kalra Cc: dev@dpdk.org, David Hunt , liang.j.ma@intel.com, reshma.pattan@intel.com References: <20200529131955.GA83122@outlook.office365.com> <660267ae-00a0-bb55-fbc3-9ac1473957ea@intel.com> <20200530100228.GA24648@outlook.office365.com> <20200602102259.GA54715@outlook.office365.com> <20200602121654.GA106816@outlook.office365.com> From: "Burakov, Anatoly" Message-ID: <0dff9790-c57f-7912-8ae3-7ee67f846d3d@intel.com> Date: Mon, 15 Jun 2020 12:31:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200602121654.GA106816@outlook.office365.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 3/3] l3fwd-power: add interrupt-only mode 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 02-Jun-20 1:16 PM, Harman Kalra wrote: > On Tue, Jun 02, 2020 at 03:53:07PM +0530, Harman Kalra wrote: >> On Mon, Jun 01, 2020 at 01:50:26PM +0100, Burakov, Anatoly wrote: >>> On 30-May-20 11:02 AM, Harman Kalra wrote: >>>> On Fri, May 29, 2020 at 03:19:45PM +0100, Burakov, Anatoly wrote: >>>>> External Email >>>>> >>>>> ---------------------------------------------------------------------- >>>>> On 29-May-20 2:19 PM, Harman Kalra wrote: >>>>> >>>>>>> if (ret < 0) >>>>>>> rte_exit(EXIT_FAILURE, "Invalid L3FWD parameters\n"); >>>>>>> - if (app_mode != APP_MODE_TELEMETRY && init_power_library()) >>>>>>> + if (app_mode == APP_MODE_DEFAULT) >>>>>>> + app_mode = APP_MODE_LEGACY; >>>>>>> + >>>>>>> + /* only legacy and empty poll mode rely on power library */ >>>>>>> + if ((app_mode == APP_MODE_LEGACY || app_mode == APP_MODE_EMPTY_POLL) && >>>>>>> + init_power_library()) >>>>>>> rte_exit(EXIT_FAILURE, "init_power_library failed\n"); >>>>>> Hi, >>>>>> >>>>>> Rather than just exiting from here can we have a else condition to >>>>>> automatically enter into the "interrupt only" mode. >>>>>> Please correct me if I am missing something. >>>>> >>>>> Hi, >>>>> >>>>> Thanks for your review. I don't think silently proceeding is a good idea. If >>>>> the user wants interrupt-only mode, they should request it. Silently falling >>>>> back to interrupt-only mode will create an illusion of successful >>>>> initialization and set the wrong expectation for how the application will >>>>> behave. >>>>> >>>> >>>> Hi, >>>> >>>> Thanks for the explanation which even I also believe is logically perfect. >>>> >>>> But since l3fwd-power is an old application and has many users around >>>> which are currently using this app in interrupt only mode without giving >>>> an extra argument. But suddenly they will start getting failure messages with >>>> the new patchset. >>>> >>>> My only intent with else condition was backward compatibility. >>>> Or may be we can have more descriptive failure message, something like >>>> "init_power_library failed, check manual for other modes". >>>> >>>> Thanks >>>> Harman >>>> >>>> >>> >>> I think we can compormise on an informative log message suggesting to use >>> interrupt mode. I'm not keen on reverting to previous buggy behavior :) >>> >> Hi >> >> I am not insisting to revert to previous behavior, I am just trying to >> highlight some probable issues that many users might face as its an old >> application. >> Since many arm based soc might not be supporting frequency scaling, can >> we add the following check as soon as the application starts, probe the >> platform if it supports frequency scaling, if not automatically set the >> mode to interrupt mode, something like: >> if (access("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", >> F_OK)) >> app_mode = APP_MODE_INTERRUPT; > > Sorry, no direct check in application but we can introduce a new API in > power library: > bool rte_is_freq_scaling() { > return access("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", > F_OK); > } > > and in the application we can use "rte_is_freq_scaling()" at the start. > What you're suggesting here is effectively what you have already suggested: silently fall back to interrupt-only mode if power lib init failed. I already outlined why i don't think it's a good approach. >> >> >> Thanks >> Harman >> >>>>> -- >>>>> Thanks, >>>>> Anatoly >>> >>> >>> -- >>> Thanks, >>> Anatoly -- Thanks, Anatoly