From: Tian Xun Ng <luckilystar08@gmail.com>
To: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Emil Tantilov <emil.s.tantilov@intel.com>,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
aleksander.lobakin@intel.com, aleksandr.loktionov@intel.com,
decot@google.com, milena.olech@intel.com, joshua.a.hay@intel.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com,
Tian Xun Ng <tianxun.ng@bytedance.com>
Subject: [PATCH iwl-net v4 0/2] idpf: destroy the vports on shutdown
Date: Mon, 12 Oct 2026 14:30:25 +0800 [thread overview]
Message-ID: <20261012063027.27750-1-luckilystar08@gmail.com> (raw)
From: Tian Xun Ng <tianxun.ng@bytedance.com>
On shutdown idpf shuts its virtchnl transaction manager down before the
vports are torn down, so the device is never told that they are gone.
Patch 2 keeps the mailbox up for that teardown, as remove already does,
with a short timeout so that an unresponsive control plane cannot hold
up a reboot for long. Doing so would expose shutdown to an existing
remove-path race between the async PTP Tx timestamp callback and
idpf_ptp_release(), which patch 1 closes first.
An LLM coding assistant helped analyse the problem and draft the changes
and their messages. Both patches carry an Assisted-by tag.
Changes in v4:
- New patch 1, closing the Tx timestamp callback race that Sashiko
pointed out on v3. It already affects remove; with patch 2 it would
also reach shutdown.
- Patch 2: the Tx queue SW marker wait follows the same bail-out as the
mailbox transactions, so a control plane that acks DISABLE_QUEUES but
posts no markers costs one marker timeout instead of one per queue
(Emil).
- Patch 2: the statistics task stops sending once IDPF_REMOVE_IN_PROG is
set (Emil).
- Patch 2: the shutdown comment now says that a transaction already in
flight keeps its own timeout; bounding that would need support in
libie.
- Not changed: if one teardown reply or Tx queue marker takes longer
than 500 ms, the rest of the teardown is skipped. On the tested PFs
the queue-related messages took at most 240 ms, and the slowest,
DEALLOC_VECTORS (about 300 ms), is sent last, after DESTROY_VPORT.
With the driver made to treat the first Tx queue marker as missing, so
that UNMAP_QUEUE_VECTOR, DESTROY_VPORT and DEALLOC_VECTORS were
skipped, 3 of 3 warm reboots were still clean on these devices. A
function reset as a fallback was patch 2 of v1; in our tests a
function reset on shutdown did not stop the faults, so it was dropped.
I can add one for when the timeout fires if that is preferred.
Testing, besides what patch 2 describes: W=1 builds of idpf and libie
with allmodconfig and allyesconfig showed no new warnings after either
patch. On one server, modprobe -r idpf and a reload completed without
warnings or IOMMU faults. These devices do not support PTP, so the path
that patch 1 changes was not exercised on hardware.
Changes in v3:
- No new flags: adapter->vc_xn_timeout_ms (60 s from probe) is lowered
to 500 ms on shutdown, and idpf_send_mb_msg() fails the rest at once
after a shortened transaction times out (Emil).
- IDPF_REMOVE_IN_PROG is set before the service and event tasks are
cancelled (Emil); the comment and message no longer state that a reset
does not clear the vports (Emil).
v3: https://lore.kernel.org/all/20261009032706.94324-1-luckilystar08@gmail.com/
v2: https://lore.kernel.org/all/20261007055741.30629-1-luckilystar08@gmail.com/
v1: https://lore.kernel.org/all/20260917105205.37561-1-luckilystar08@gmail.com/
Tian Xun Ng (2):
idpf: don't use the Tx timestamp trackers once removal has started
idpf: keep the mailbox up while tearing down vports on shutdown
drivers/net/ethernet/intel/idpf/idpf.h | 3 +
drivers/net/ethernet/intel/idpf/idpf_lib.c | 3 +
drivers/net/ethernet/intel/idpf/idpf_main.c | 11 +++
.../net/ethernet/intel/idpf/idpf_virtchnl.c | 68 ++++++++++++++++---
.../net/ethernet/intel/idpf/idpf_virtchnl.h | 1 +
.../ethernet/intel/idpf/idpf_virtchnl_ptp.c | 3 +-
6 files changed, 80 insertions(+), 9 deletions(-)
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-10-12 6:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 6:30 Tian Xun Ng [this message]
2026-10-12 6:30 ` [PATCH iwl-net v4 1/2] idpf: don't use the Tx timestamp trackers once removal has started Tian Xun Ng
2026-10-12 6:30 ` [PATCH iwl-net v4 2/2] idpf: keep the mailbox up while tearing down vports on shutdown Tian Xun Ng
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=20261012063027.27750-1-luckilystar08@gmail.com \
--to=luckilystar08@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=decot@google.com \
--cc=edumazet@google.com \
--cc=emil.s.tantilov@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=joshua.a.hay@intel.com \
--cc=kuba@kernel.org \
--cc=milena.olech@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=tianxun.ng@bytedance.com \
/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