From: Long Li <longli@microsoft.com>
To: dev@dpdk.org, Wei Hu <weh@microsoft.com>,
Stephen Hemminger <stephen@networkplumber.org>,
stable@dpdk.org
Cc: Long Li <longli@microsoft.com>
Subject: [PATCH v2] net/netvsc: switch data path to synthetic on device stop
Date: Mon, 23 Mar 2026 16:49:57 -0700 [thread overview]
Message-ID: <20260323234957.1780150-1-longli@microsoft.com> (raw)
When DPDK stops a netvsc device (e.g. on testpmd quit), the data path
was left pointing to the VF/MANA device. If the kernel netvsc driver
subsequently reloads the MANA device and opens it, incoming traffic
arrives on the MANA device immediately, before the queues are fully
initialized. This causes bogus RX completion events to appear on the
TX completion queue, triggering a kernel WARNING in mana_poll_tx_cq().
Fix this by switching the data path back to synthetic (via
NVS_DATAPATH_SYNTHETIC) in hn_vf_stop() before stopping the VF device.
This tells the host to route traffic through the synthetic path, so
that when the MANA driver recreates its queues, no unexpected traffic
arrives until netvsc explicitly switches back to VF.
Also update hn_vf_start() to switch the data path back to VF after the
VF device is started, enabling correct stop/start cycling.
Both functions now use write locks instead of read locks since they
modify vf_vsc_switched state.
Fixes: dc7680e8597c ("net/netvsc: support integrated VF")
Cc: stable@dpdk.org
Signed-off-by: Long Li <longli@microsoft.com>
---
v2:
- hn_vf_stop(): only clear vf_vsc_switched on successful datapath switch
- hn_vf_start(): stop VF device if datapath switch to VF fails
drivers/net/netvsc/hn_vf.c | 59 ++++++++++++++++++++++++++++++++------
1 file changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/net/netvsc/hn_vf.c b/drivers/net/netvsc/hn_vf.c
index 99e8086afa..7840c77c5c 100644
--- a/drivers/net/netvsc/hn_vf.c
+++ b/drivers/net/netvsc/hn_vf.c
@@ -314,9 +314,17 @@ int hn_vf_add_unlocked(struct rte_eth_dev *dev, struct hn_data *hv)
}
switch_data_path:
- ret = hn_nvs_set_datapath(hv, NVS_DATAPATH_VF);
- if (ret == 0)
- hv->vf_ctx.vf_vsc_switched = true;
+ /* Only switch data path to VF if the device is started.
+ * Otherwise defer to hn_vf_start() to avoid routing traffic
+ * to the VF before queues are set up.
+ */
+ if (dev->data->dev_started) {
+ ret = hn_nvs_set_datapath(hv, NVS_DATAPATH_VF);
+ if (ret)
+ PMD_DRV_LOG(ERR, "Failed to switch to VF: %d", ret);
+ else
+ hv->vf_ctx.vf_vsc_switched = true;
+ }
exit:
return ret;
@@ -521,11 +529,32 @@ int hn_vf_start(struct rte_eth_dev *dev)
struct rte_eth_dev *vf_dev;
int ret = 0;
- rte_rwlock_read_lock(&hv->vf_lock);
+ rte_rwlock_write_lock(&hv->vf_lock);
vf_dev = hn_get_vf_dev(hv);
- if (vf_dev)
+ if (vf_dev) {
ret = rte_eth_dev_start(vf_dev->data->port_id);
- rte_rwlock_read_unlock(&hv->vf_lock);
+ if (ret == 0) {
+ /* Re-switch data path to VF if VSP has reported
+ * VF is present and we haven't switched yet
+ * (e.g. after a stop/start cycle).
+ */
+ if (hv->vf_ctx.vf_vsp_reported &&
+ !hv->vf_ctx.vf_vsc_switched) {
+ ret = hn_nvs_set_datapath(hv,
+ NVS_DATAPATH_VF);
+ if (ret) {
+ PMD_DRV_LOG(ERR,
+ "Failed to switch to VF: %d",
+ ret);
+ rte_eth_dev_stop(
+ vf_dev->data->port_id);
+ } else {
+ hv->vf_ctx.vf_vsc_switched = true;
+ }
+ }
+ }
+ }
+ rte_rwlock_write_unlock(&hv->vf_lock);
return ret;
}
@@ -535,15 +564,29 @@ int hn_vf_stop(struct rte_eth_dev *dev)
struct rte_eth_dev *vf_dev;
int ret = 0;
- rte_rwlock_read_lock(&hv->vf_lock);
+ rte_rwlock_write_lock(&hv->vf_lock);
vf_dev = hn_get_vf_dev(hv);
if (vf_dev) {
+ /* Switch data path back to synthetic before stopping VF,
+ * so the host stops routing traffic to the VF device.
+ */
+ if (hv->vf_ctx.vf_vsc_switched) {
+ ret = hn_nvs_set_datapath(hv, NVS_DATAPATH_SYNTHETIC);
+ if (ret) {
+ PMD_DRV_LOG(ERR,
+ "Failed to switch to synthetic: %d",
+ ret);
+ } else {
+ hv->vf_ctx.vf_vsc_switched = false;
+ }
+ }
+
ret = rte_eth_dev_stop(vf_dev->data->port_id);
if (ret != 0)
PMD_DRV_LOG(ERR, "Failed to stop device on port %u",
vf_dev->data->port_id);
}
- rte_rwlock_read_unlock(&hv->vf_lock);
+ rte_rwlock_write_unlock(&hv->vf_lock);
return ret;
}
--
2.43.0
next reply other threads:[~2026-03-23 23:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 23:49 Long Li [this message]
2026-03-24 16:00 ` [PATCH v2] net/netvsc: switch data path to synthetic on device stop Stephen Hemminger
2026-03-25 19:00 ` [EXTERNAL] " Long Li
-- strict thread matches above, loose matches on Subject: below --
2026-03-21 0:43 [PATCH] " Long Li
2026-03-23 23:58 ` [PATCH v2] " Long Li
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=20260323234957.1780150-1-longli@microsoft.com \
--to=longli@microsoft.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=weh@microsoft.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