From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8A73C4727C for ; Tue, 29 Sep 2020 19:04:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 575032076D for ; Tue, 29 Sep 2020 19:04:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728300AbgI2TEk (ORCPT ); Tue, 29 Sep 2020 15:04:40 -0400 Received: from mga17.intel.com ([192.55.52.151]:23290 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727740AbgI2TEk (ORCPT ); Tue, 29 Sep 2020 15:04:40 -0400 IronPort-SDR: EejvoYsWown7srYIb/v4odrGUlbA9CIVlfZ86ES6pM/FMW85WFwv0XxFGOPdSs8UMoWkO8lCo1 bsdbuQ5/QVCQ== X-IronPort-AV: E=McAfee;i="6000,8403,9759"; a="142282385" X-IronPort-AV: E=Sophos;i="5.77,319,1596524400"; d="scan'208";a="142282385" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2020 12:04:39 -0700 IronPort-SDR: AZH+SdxckCVhaiu9xZ54yF0cswJj7i4QtmoJAWvtIaWc5OsEVsmeUH8B6Zu3GwH2xZ+5BIfRVI onf9EKzAjUGg== X-IronPort-AV: E=Sophos;i="5.77,319,1596524400"; d="scan'208";a="492963948" Received: from jekeller-mobl1.amr.corp.intel.com (HELO [10.209.162.133]) ([10.209.162.133]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2020 12:04:39 -0700 Subject: Re: [RFC iproute2-next] devlink: display elapsed time during flash update From: Jacob Keller To: Ido Schimmel Cc: Jakub Kicinski , netdev@vger.kernel.org, snelson@pensando.io References: <20200928234945.3417905-1-jacob.e.keller@intel.com> <20200929101846.2a296015@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200929180722.GA1674045@shredder> <4baf15d7-3e7a-9cf3-16cc-93507d07cf5b@intel.com> Organization: Intel Corporation Message-ID: Date: Tue, 29 Sep 2020 12:04:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <4baf15d7-3e7a-9cf3-16cc-93507d07cf5b@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 9/29/2020 11:45 AM, Jacob Keller wrote: > > > On 9/29/2020 11:07 AM, Ido Schimmel wrote: >> On Tue, Sep 29, 2020 at 10:56:23AM -0700, Jacob Keller wrote: >>> >>> >>> On 9/29/2020 10:18 AM, Jakub Kicinski wrote: >>>> On Mon, 28 Sep 2020 16:49:45 -0700 Jacob Keller wrote: >>>>> For some devices, updating the flash can take significant time during >>>>> operations where no status can meaningfully be reported. This can be >>>>> somewhat confusing to a user who sees devlink appear to hang on the >>>>> terminal waiting for the device to update. >>>>> >>>>> Provide a ticking counter of the time elapsed since the previous status >>>>> message in order to make it clear that the program is not simply stuck. >>>>> >>>>> Do not display this message unless a few seconds have passed since the >>>>> last status update. Additionally, if the previous status notification >>>>> included a timeout, display this as part of the message. If we do not >>>>> receive an error or a new status without that time out, replace it with >>>>> the text "timeout reached". >>>>> >>>>> Signed-off-by: Jacob Keller >>>>> --- >>>>> Sending this as an RFC because I doubt this is the best implementation. For >>>>> one, I get a weird display issue where the cursor doesn't always end up on >>>>> the end of line in my shell.. The % display works properly, so I'm not sure >>>>> what's wrong here. >>>>> >>>>> Second, even though select should be timing out every 1/10th of a second for >>>>> screen updates, I don't seem to get that behavior in my test. It takes about >>>>> 8 to 10 seconds for the first elapsed time message to be displayed, and it >>>>> updates really slowly. Is select just not that precise? I even tried using a >>>>> timeout of zero, but this means we refresh way too often and it looks bad. I >>>>> am not sure what is wrong here... >>>> >>>> Strange. Did you strace it? Perhaps it's some form of output buffering? >>>> >>> >>> Haven't yet, just noticed the weird output behavior and timing >>> inconsistency. >> >> Might be similar to this: >> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=8e6bce735a132150c23503a55ea0aef55a01425f >> > > Yep, I needed the fflush! That resolved the display issue! > > Thanks, > Jake > This also appears to have resolved the weird timing aspect.. the line wasn't flushed right away. strace with relative timestamps confirmed that select was infact waking up. I'll post a non-RFC version that includes the suggested cleanups from Jakub. Shannon, I'd appreciate if you could try out the next revision with your device to see if it looks good! Thanks, Jake