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]

Message-ID: <7a9ff898-bdae-9dab-12a9-30d825b6b67d@intel.com>
Date:   Wed, 30 Sep 2020 14:43:19 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org
Subject: Re: [iproute2-next v1] devlink: display elapsed time during flash
 update



On 9/30/2020 2:36 PM, Jakub Kicinski wrote:
> 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?
> 


The elapsed time is calculated from the last status message we receive.
In Shannon's case, the done/total % status messages come approximately
slow enough that the elapsed time message keeps popping up. Since it's
measuring from the last time we got a status message, it looks weird
because it resets to 3 seconds over and over and over.

>>> 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.
> 

My point was about changing when we calculated elapsed time from to be
"since the status message changed" rather than "since the last time the
driver sent any status even if the message remains the same".

I think clearing the timing message is a good improvement either way, so
I'll do that too.