From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Cc: Bruce Richardson <bruce.richardson@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Praveen Shetty <praveen.shetty@intel.com>
Subject: [PATCH] net/ice: fix incorrect mbuf cleanup function
Date: Fri, 21 Feb 2025 16:04:02 +0000 [thread overview]
Message-ID: <20250221160402.855510-1-bruce.richardson@intel.com> (raw)
The mbuf cleanup function is not being called correctly on close of the
driver, due to the vector_tx flag not being set correctly on each Tx
queue. Normally, this causes no visible problems, because the default is
to have the vector flag unset, which means that, if vector Tx path is
chosen, we only free every second mbuf in the descriptor vector ring - a
subtle memory leak.
The reverse case - where we initially configure a port to use a vector
driver, and then later reconfigure it for scalar - causes a segfault on
close, as the vector cleanup is used on a scalar SW ring, and that
vector path treats the extra metadata in the SW ring as mbufs to be
freed.
This is due to an inconsistency across drivers on port start: in e.g.
the i40e driver, the Rx and Tx functions are chosen before the
individual queues are started, while in ice driver the order is
reversed. Because the Tx function selection is done after the queues
are initialized, the initialized queues use an old value of the overall
flag indicating if a vector Tx path is being used.
Fix the issue by moving the Rx and Tx path selection before queue start.
Fixes: 552979dfb1c9 ("net/intel: create common Tx queue mbuf cleanup")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
drivers/net/intel/ice/ice_ethdev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/intel/ice/ice_ethdev.c b/drivers/net/intel/ice/ice_ethdev.c
index 0e092702cc..3cdfa16f77 100644
--- a/drivers/net/intel/ice/ice_ethdev.c
+++ b/drivers/net/intel/ice/ice_ethdev.c
@@ -3961,6 +3961,9 @@ ice_dev_start(struct rte_eth_dev *dev)
ice_declare_bitmap(pmask, ICE_PROMISC_MAX);
ice_zero_bitmap(pmask, ICE_PROMISC_MAX);
+ ice_set_rx_function(dev);
+ ice_set_tx_function(dev);
+
/* program Tx queues' context in hardware */
for (nb_txq = 0; nb_txq < data->nb_tx_queues; nb_txq++) {
ret = ice_tx_queue_start(dev, nb_txq);
@@ -3989,9 +3992,6 @@ ice_dev_start(struct rte_eth_dev *dev)
}
}
- ice_set_rx_function(dev);
- ice_set_tx_function(dev);
-
mask = RTE_ETH_VLAN_STRIP_MASK | RTE_ETH_VLAN_FILTER_MASK |
RTE_ETH_VLAN_EXTEND_MASK;
if (ice_is_dvm_ena(hw))
--
2.43.0
reply other threads:[~2025-02-21 16:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20250221160402.855510-1-bruce.richardson@intel.com \
--to=bruce.richardson@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=praveen.shetty@intel.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;
as well as URLs for NNTP newsgroup(s).