From: Jacob Keller <jacob.e.keller@intel.com>
To: Jakub Kicinski <kuba@kernel.org>, Shannon Nelson <snelson@pensando.io>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v3 net-next 2/2] ionic: add devlink firmware update
Date: Tue, 15 Sep 2020 11:44:07 -0700 [thread overview]
Message-ID: <1dfa16c8-8bb6-a429-6644-68fd94fc2830@intel.com> (raw)
In-Reply-To: <20200915103913.46cebf69@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 9/15/2020 10:39 AM, Jakub Kicinski wrote:
> On Tue, 15 Sep 2020 10:20:11 -0700 Shannon Nelson wrote:
>>>>> What should the userland program do when the timeout expires? Start
>>>>> counting backwards? Stop waiting? Do we care to define this at the moment?
>>>> [component] bla bla X% (timeout reached)
>>>
>>> Yep. I don't think userspace should bail or do anything but display
>>> here. Basically: the driver will timeout and then end the update
>>> process with an error. The timeout value is just a useful display
>>> so that users aren't confused why there is no output going on while
>>> waiting.
>>>
>> If individual notify messages have a timeout, how can we have a
>> progress-percentage reported with a timeout? This implies to me that
>> the timeout is on the component:bla-bla pair, but there are many
>> notify messages in order to show the progress in percentage done.
>> This is why I was suggesting that if the timeout and component and
>> status messages haven't changed, then we're still working on the same
>> timeout.
>
> My thinking is that the timeout is mostly useful for commands which
> can't meaningfully provide the progress percentage, or the percentage
> update is at a very high granularity. If percentage updates are reported
> often they should usually be sufficient.
>
> We mostly want to make sure user doesn't think the system has hung.
>
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.
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...
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.
next prev parent reply other threads:[~2020-09-15 18:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 22:48 [PATCH v3 net-next 0/2] ionic: add devlink dev flash support Shannon Nelson
2020-09-08 22:48 ` [PATCH v3 net-next 1/2] ionic: update the fw update api Shannon Nelson
2020-09-08 22:48 ` [PATCH v3 net-next 2/2] ionic: add devlink firmware update Shannon Nelson
2020-09-08 23:54 ` Jakub Kicinski
2020-09-09 16:23 ` Shannon Nelson
2020-09-09 16:44 ` Jakub Kicinski
2020-09-09 17:58 ` Shannon Nelson
2020-09-09 19:22 ` Jakub Kicinski
2020-09-10 1:34 ` Shannon Nelson
2020-09-10 17:56 ` Jakub Kicinski
2020-09-14 22:02 ` Shannon Nelson
2020-09-14 22:59 ` Jakub Kicinski
2020-09-14 23:15 ` Jacob Keller
2020-09-14 23:36 ` Jakub Kicinski
2020-09-14 23:47 ` Shannon Nelson
[not found] ` <7e44037cedb946d4a72055dd0898ab1d@intel.com>
2020-09-15 1:14 ` Shannon Nelson
2020-09-15 15:50 ` Jakub Kicinski
2020-09-15 16:50 ` Keller, Jacob E
2020-09-15 17:20 ` Shannon Nelson
2020-09-15 17:39 ` Jakub Kicinski
2020-09-15 18:44 ` Jacob Keller [this message]
2020-09-15 19:00 ` Jakub Kicinski
2020-09-15 22:11 ` Shannon Nelson
2020-09-15 22:27 ` Jakub Kicinski
2020-09-15 0:52 ` Keller, Jacob E
2020-09-14 23:19 ` Jacob Keller
2020-09-09 21:30 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1dfa16c8-8bb6-a429-6644-68fd94fc2830@intel.com \
--to=jacob.e.keller@intel.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=snelson@pensando.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).