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 884D6A0093; Mon, 15 Jun 2020 17:22:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6437F4C87; Mon, 15 Jun 2020 17:22:17 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id D2C802B94 for ; Mon, 15 Jun 2020 17:22:15 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id m81so18286455ioa.1 for ; Mon, 15 Jun 2020 08:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B1cv2eMRfqwhFBp5r/iTPpky32VeRW9YFBhY0RKLgsc=; b=Su/9DCDuvP8wG0dYKufKnJVLYgI1Sw9qauq5CB2q2+MTjz/UKzYPYnJRU/PGb8zTgh sEjOt6HxyFlbn9EQyB9lAQzW9yVtIOTJHORIoDw4z1hSHKcU3t41FCNSfcIU4RMzYHXI vGOJqB++DW8EuMuD3I2pgVM7duE/vSTMzyRtcuDz48bmJavamXNjYHLSUwgIarqFHLfQ faGPpCBpadl1p2lL+vMuM2q2HRoFDuPmb1mLB1cKPK04PaHl2MFMrVHI6189U9lsmA1f sJ0/9OUGm4rpTtBrKR4LFBwcVdMJBaQlDPylwXhxJwtYXaLQ5NvCaqxrx6peHihOyfcH HgLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B1cv2eMRfqwhFBp5r/iTPpky32VeRW9YFBhY0RKLgsc=; b=fjKuWoT3A0bQnsrxfe6uwlFAhXpBdczUjuNq0EtjkIakpth+lvxLHIncBP0HIqfgWG 3TrtJ5yIt/7NqO98pjIeZ5qFcAnG6HLmKJxaAu4IVknC/3Jy0AP6lNj3yVHrFsXu3lUy 7pioPxsh2zszxYBMP4ev7zkCxrqp/wsIrblH6CtmHI0qqnWbFecq4bJBV4LRZNm0F0mS VRvA1AVRB+FsKffexGpftILtMvc3WySQZVtuFKGawO21CMFco2rOv9N21iPNmNwPyKio sOC8SzN19gvKgU9t0PSy2fIhRBtsrCBsTKsV8jI8KR9G1wdmhCbBJj3EGhbkN25Agust XHEw== X-Gm-Message-State: AOAM532arPKnWYoPm+nnCih91MD6Fhi0/CFW48e9+xGq2ofbx7tIIgJu vo0qGpOdoPE7T+tCshGPHaEBxTReUkEU3Vnjgh4= X-Google-Smtp-Source: ABdhPJw3ckC3g6/WX8RXrg7pcjLtOAXHDEMfjaj+g52saFr5tCWagwVuzhUKEsQfWT/pnQvuTKf004tHeAsrDWR9toY= X-Received: by 2002:a02:a392:: with SMTP id y18mr22059835jak.112.1592234535121; Mon, 15 Jun 2020 08:22:15 -0700 (PDT) MIME-Version: 1.0 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> <0dff9790-c57f-7912-8ae3-7ee67f846d3d@intel.com> <93726fd8-b6ac-efa8-695e-214d24dfc561@intel.com> In-Reply-To: <93726fd8-b6ac-efa8-695e-214d24dfc561@intel.com> From: Jerin Jacob Date: Mon, 15 Jun 2020 20:51:59 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Harman Kalra , dpdk-dev , David Hunt , Liang Ma , Reshma Pattan Content-Type: text/plain; charset="UTF-8" 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 Mon, Jun 15, 2020 at 8:35 PM Burakov, Anatoly wrote: > > On 15-Jun-20 12:43 PM, Jerin Jacob wrote: > > On Mon, Jun 15, 2020 at 5:02 PM Burakov, Anatoly > > wrote: > >> > >> 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. > > > > Is probing "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" > > file presence, > > detects the power lib availability . Right? Not the failure. Right? > > IMO, it make sense to have following case: > > # first check, Is the system is capable of power lib if so use power lib > > # if the system is not capable of using power lib use interrupt mode. > > > > I think, there is difference between system capable of using power lib > > vs power lib not available or power lib failure. > > I am of the opinion that if a test sets up an unrealistic expectation of > how an application should behave, it's a problem with the test, not with > the application. > > If the system is not capable of running with power lib - the application > shouldn't be requested to run in such mode. But with this patch, default proposed mode is power lib without any explicit request. > > "The application behaved that way before" - yes, it did. It was a bug in > the application, that it allowed users to effectively misuse the > application and use it despite the fact that it was in a half-working > state. This problem has been addressed by 1) not allowing the > application to run in half-working state, and 2) adding a new mode where > the old "expected" behavior is *actually* expected and is "full working > state" now. > > Therefore, all users who were previously misusing the application to do > something it was not designed to do because of a bug in the > implementation, should now fix their usage and use the correct mode - > and such breakage is IMO necessary to call attention to earlier misuse > in the tools, and to correct this usage. > > What bothers me about your suggestion is that it is impossible to fail > the test if the wrong mode was requested (as in, if we request the > power-lib mode on a system that doesn't have freq scaling) - it instead > silently falls back to a mode that is almost guaranteed to work. I agree that it should fail, i.e someone explicitly request, power-lib mode or any mode and it should fail application if the platform we can not do that. My suggestion is all about, what is the default, IMO, if no argument is specified, the application should _probe_ the capability of the platfrom and choose the mode. One can override the probe to select the desired one. In such mode, fail to configure the mode should result in an error. > > -- > Thanks, > Anatoly