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] [day] [month] [year] [list]

Message-ID: <e6c46e51-e377-20d0-564a-821c4610e35b@intel.com>
Date:   Wed, 30 Sep 2020 15:02:27 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Shannon Nelson <snelson@...sando.io>,
        Jakub Kicinski <kubakici@...pl>
Cc:     netdev@...r.kernel.org
Subject: Re: [iproute2-next v1] devlink: display elapsed time during flash
 update



On 9/30/2020 2:55 PM, Shannon Nelson wrote:
> On 9/30/20 2:43 PM, Jacob Keller wrote:
>> 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".
> 
> This would be better, and is a bit like what I was imagining early on, 
> but at this point I'm wondering if the display of the elapsed time is 
> actually useful, or simply making it messier.
> 
>>
>> I think clearing the timing message is a good improvement either way, so
>> I'll do that too.
> Yes.
> 

I think if we always clear the elapsed time on a new message it will
feel a lot cleaner overall.

Thanks,
Jake

> sln
> 
>