On 9/15/20 12:00 PM, Jakub Kicinski wrote:
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.
I have an asynchronous FW interaction where the driver sends one FW
command to start the fw-install and sends several more FW commands to
check on the status until either it gets a done or error status or too
many seconds have elapsed. How would you suggest this gets modeled?
In the model you are suggesting, the driver can only do a single
status_notify with a timeout before the initial async FW command, then
no other status_notify messages until the driver gets the done/error
status, or the time has elapsed, regardless of how long that might
take. The user will only see the timeout ticking, but no activity from
the driver. This allows the user to see what the deadline is, but
doesn't reassure them that the process is still moving.
I'm suggesting that the driver might send some intermediate
status_notify messages in order to assure the user that things are not
stalled out. Driving a spinner would be nice, but we don't have that
concept in this interface, so poking the done/total values could be used
for that. In order to not reset the timeout on each of these
intermediate updates, we pass the same timeout value.
At this point I'm going to try a patchset that implements the basics
that we already have agreed upon, and this detail can get worked out
later, as I believe it doesn't change the internal implementation.
sln
