On 9/29/2020 3:44 PM, Shannon Nelson wrote:

On 9/29/20 2:56 PM, Jacob Keller wrote:

quoted

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.

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

sln