All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shannon Nelson <snelson@pensando.io>
To: Jacob Keller <jacob.e.keller@intel.com>, netdev@vger.kernel.org
Cc: Jakub Kicinski <kubakici@wp.pl>
Subject: Re: [iproute2-next v1] devlink: display elapsed time during flash update
Date: Tue, 29 Sep 2020 15:44:08 -0700	[thread overview]
Message-ID: <df1ad702-ab31-e027-e711-46d09f8fa095@pensando.io> (raw)
In-Reply-To: <20200929215651.3538844-1-jacob.e.keller@intel.com>

On 9/29/20 2:56 PM, 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.
>
> Recent changes to the kernel interface allow such long running commands
> to provide a timeout value indicating some upper bound on how long the
> relevant action could take.
>
> 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.
>
> Display this message whenever the status message from the kernel
> indicates a timeout value. Additionally also display the message if
> we've received no status for more than couple of seconds. If we elapse
> more than the timeout provided by the status message, replace the
> timeout display with "timeout reached".
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
>

Thanks, Jake.  In general this seems to work pretty well.  One thing, 
tho'...

Our fw download is slow (I won't go into the reasons here) so we're 
clicking through the Download x% over maybe 100+ seconds.  Since we send 
an update every 3% or so, we end up seeing the ( 0m 3s ) pop up and stay 
there the whole time, looking a little odd:

     ./iproute2-5.8.0/devlink/devlink dev flash pci/0000:b5:00.0 file 
ionic/dsc_fw_1.15.0-150.tar
     Preparing to flash
     Downloading  37% ( 0m 3s )
   ...
     Downloading  59% ( 0m 3s )
   ...
     Downloading  83% ( 0m 3s )

And at the end we see:

     Preparing to flash
     Downloading 100% ( 0m 3s )
     Installing ( 0m 43s : 25m 0s )
     Selecting ( 0m 5s : 0m 30s )
     Flash done

I can have the driver do updates more often in order to stay under the 3 
second limit and hide this, but it looks a bit funky, especially at the 
end where I know that 100% took a lot longer than 3 seconds.

sln



  reply	other threads:[~2020-09-29 22:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 21:56 [iproute2-next v1] devlink: display elapsed time during flash update Jacob Keller
2020-09-29 22:44 ` Shannon Nelson [this message]
2020-09-30 21:20   ` Jacob Keller
2020-09-30 21:36     ` Jakub Kicinski
2020-09-30 21:43       ` Jacob Keller
2020-09-30 21:55         ` Shannon Nelson
2020-09-30 22:02           ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df1ad702-ab31-e027-e711-46d09f8fa095@pensando.io \
    --to=snelson@pensando.io \
    --cc=jacob.e.keller@intel.com \
    --cc=kubakici@wp.pl \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.