On 9/20/2026 8:27 PM, Tian Xun Ng wrote:
On 9/18/2026, Tantilov, Emil S wrote:
Actually we can't wait on shutdown. If the MBX is defunct, like CP is
down or unresponsive, the shutdown will hang for a very long time. This
is the reason why we wanted to avoid communication on shutdown. Have you
tested the shutdown after stopping the control plane?
No, I have not, and I cannot on this platform: the control plane sits
behind the device and I have no way to stop it from the host. So I have
to take your point as given, and as written the patch is not acceptable:
each teardown transaction uses IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC (60 s),
and the teardown per vport is disable_vport, disable_queues (which also
waits for the SW marker) and destroy_vport. With a dead CP and two vports
that is minutes of hang on every reboot, to remove a fault that only
shows up on warm reboots. That trade is wrong.
What I would like to propose for v2 is to keep the teardown but bound it:
a shutdown-specific timeout, on the order of a second or two, used for
those three transactions when the driver is shutting down. If the CP
answers, the device is told to stop its queues and the stray writes go
away; if it does not, shutdown loses a bounded couple of seconds instead
of minutes. Does that direction look acceptable to you, and is there a
timeout value you would consider safe? If you would rather not have any
mailbox traffic on shutdown at all, then I think the fix has to come from
the device side instead, and I would rather know that before sending v2.
If there is some clean way to shortcut the MBX on shutdown then I guess
it would be acceptable, but I don't know what a "safe" timeout would be.
As you can see the timeouts are already quite long, so you could
potentially still bail out on a working CP that just so happens to be
busy on the replies.
Also, consider the case where a reset on the PF will kill the MBX for
the VFs associated with it, so a shutdown on such a VF will always end
up timing out, since the VF reset is a message to the FW.
This logic already exists in the reset handling, there should be no need
to replicate it here. Do you have a trace and/or exact scenario that
leads to remove being called while in a reset, but MBX is still alive?
No, I do not have such a trace. I added idpf_is_reset_detected() defensively
rather than from an observed case, and I will drop it in v2.
OK, that makes more sense. I was curious if you are actually seeing an
issue in your testing.
For the record, what we do see without any of this, on arm64 with two idpf
functions: after a warm reboot the device still has its queues enabled with
the previous kernel's ring addresses, and the first queue reconfiguration in
the next boot makes it write SW_MARKER completions into memory that kernel
has already reused. 20 of 20 warm reboots on an unpatched control node, none
in 151 with the teardown messages delivered.
In that case wouldn't just the reset on shutdown be sufficient? The FW
should clear the resources on reset, which should take care of the stale
vports.
Thanks for the review.
Thanks,
Emil
