netdev - Re: [iproute2-next v1] devlink: display elapsed time during flash update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Sep 2020 14:36:59 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org
Subject: Re: [iproute2-next v1] devlink: display elapsed time during flash
 update

On Wed, 30 Sep 2020 14:20:43 -0700 Jacob Keller wrote:
> > 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 )

I'm not sure how to interpret this - are you saying that the timer
doesn't tick up or that the FW happens to complete the operation right
around the 3sec mark?

> > 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.
> >   
> 
> I think we have two options here:
> 
> 1) never display an elapsed time when we have done/total information
> 
> or
> 
> 2) treat elapsed time as a measure since the last status message
> changed, refactoring this so that it shows the total time spent on that
> status message.
> 
> Thoughts on this? I think I'm leaning towards (2) at the moment myself.
> This might lead to displaying the timing info on many % calculations
> though... Hmm

Is the time information useful after stage is complete? I'd just wipe
it before moving on to the next message.