netdev - Re: [PATCH v3 net-next 2/2] ionic: add devlink firmware 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: <20200915120025.0858e324@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 15 Sep 2020 12:00:25 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Shannon Nelson <snelson@...sando.io>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v3 net-next 2/2] ionic: add devlink firmware update

On Tue, 15 Sep 2020 11:44:07 -0700 Jacob Keller wrote:
> Exactly how I saw it.
> 
> Basically, the timeout should take effect as long as the (component,
> msg) pair stays the same.
> 
> So if you send percentage reports with the same message and component,
> then the timeout stays in effect. Once you start a new message, then the
> timeout would be reset.

I don't think I agree with that. As I said that'd make the timeout not
match the reality of what happens in the driver.

Say I have 4 updates (every 25%) each has a timeout of 30 seconds.
If I understand what you're saying correctly you'd set a timeout of 
2 min for the operation. But if first two chunks finish in 10 seconds,
and 3rd one timeouts out the timeout will happen (in the driver) when
the user-visible timer is at (50sec / 2 min). 

I think that each notification should update the timeout. And like
systemd we should not display the timeout counter in the first, say 5
seconds to minimize the display noise.

> We could in theory provide both a "timeout" and "time elapsed" field,
> which would allow the application to draw the timeout at an abitrary
> point. Then it could progress the time as normal if it hasn't received a
> new message yet, allowing for consistent screen updates...

I'm not sure I follow this part.

> But I think that might be overkill. For the cases where we do get some
> sort of progress, then the percentage update is usually enough.