From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, netdev@vger.kernel.org
Cc: Jacob Keller <jacob.e.keller@intel.com>,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
Rafal Romanowski <rafal.romanowski@intel.com>
Subject: [PATCH net-next 03/12] ice: consistently use q_idx in ice_vc_cfg_qs_msg()
Date: Tue, 8 Oct 2024 16:34:29 -0700 [thread overview]
Message-ID: <20241008233441.928802-4-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20241008233441.928802-1-anthony.l.nguyen@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
The ice_vc_cfg_qs_msg() function is used to configure VF queues in response
to a VIRTCHNL_OP_CONFIG_VSI_QUEUES command.
The virtchnl command contains an array of queue pair data for configuring
Tx and Rx queues. This data includes a queue ID. When configuring the
queues, the driver generally uses this queue ID to determine which Tx and
Rx ring to program. However, a handful of places use the index into the
queue pair data from the VF. While most VF implementations appear to send
this data in order, it is not mandated by the virtchnl and it is not
verified that the queue pair data comes in order.
Fix the driver to consistently use the q_idx field instead of the 'i'
iterator value when accessing the rings. For the Rx case, introduce a local
ring variable to keep lines short.
Fixes: 7ad15440acf8 ("ice: Refactor VIRTCHNL_OP_CONFIG_VSI_QUEUES handling")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_virtchnl.c | 21 +++++++++----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index 3c86d0c2fe1f..c8c1d48ff793 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -1715,8 +1715,8 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
/* copy Tx queue info from VF into VSI */
if (qpi->txq.ring_len > 0) {
- vsi->tx_rings[i]->dma = qpi->txq.dma_ring_addr;
- vsi->tx_rings[i]->count = qpi->txq.ring_len;
+ vsi->tx_rings[q_idx]->dma = qpi->txq.dma_ring_addr;
+ vsi->tx_rings[q_idx]->count = qpi->txq.ring_len;
/* Disable any existing queue first */
if (ice_vf_vsi_dis_single_txq(vf, vsi, q_idx))
@@ -1725,7 +1725,7 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
/* Configure a queue with the requested settings */
if (ice_vsi_cfg_single_txq(vsi, vsi->tx_rings, q_idx)) {
dev_warn(ice_pf_to_dev(pf), "VF-%d failed to configure TX queue %d\n",
- vf->vf_id, i);
+ vf->vf_id, q_idx);
goto error_param;
}
}
@@ -1733,24 +1733,23 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
/* copy Rx queue info from VF into VSI */
if (qpi->rxq.ring_len > 0) {
u16 max_frame_size = ice_vc_get_max_frame_size(vf);
+ struct ice_rx_ring *ring = vsi->rx_rings[q_idx];
u32 rxdid;
- vsi->rx_rings[i]->dma = qpi->rxq.dma_ring_addr;
- vsi->rx_rings[i]->count = qpi->rxq.ring_len;
+ ring->dma = qpi->rxq.dma_ring_addr;
+ ring->count = qpi->rxq.ring_len;
if (qpi->rxq.crc_disable)
- vsi->rx_rings[q_idx]->flags |=
- ICE_RX_FLAGS_CRC_STRIP_DIS;
+ ring->flags |= ICE_RX_FLAGS_CRC_STRIP_DIS;
else
- vsi->rx_rings[q_idx]->flags &=
- ~ICE_RX_FLAGS_CRC_STRIP_DIS;
+ ring->flags &= ~ICE_RX_FLAGS_CRC_STRIP_DIS;
if (qpi->rxq.databuffer_size != 0 &&
(qpi->rxq.databuffer_size > ((16 * 1024) - 128) ||
qpi->rxq.databuffer_size < 1024))
goto error_param;
vsi->rx_buf_len = qpi->rxq.databuffer_size;
- vsi->rx_rings[i]->rx_buf_len = vsi->rx_buf_len;
+ ring->rx_buf_len = vsi->rx_buf_len;
if (qpi->rxq.max_pkt_size > max_frame_size ||
qpi->rxq.max_pkt_size < 64)
goto error_param;
@@ -1765,7 +1764,7 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
if (ice_vsi_cfg_single_rxq(vsi, q_idx)) {
dev_warn(ice_pf_to_dev(pf), "VF-%d failed to configure RX queue %d\n",
- vf->vf_id, i);
+ vf->vf_id, q_idx);
goto error_param;
}
--
2.42.0
next prev parent reply other threads:[~2024-10-08 23:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 23:34 [PATCH net-next 00/12][pull request] Intel Wired LAN Driver Updates 2024-10-08 (ice, iavf, igb, e1000e, e1000) Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 01/12] ice: Implement ethtool reset support Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 02/12] ice: add E830 HW VF mailbox message limit support Tony Nguyen
2024-10-08 23:34 ` Tony Nguyen [this message]
2024-10-08 23:34 ` [PATCH net-next 04/12] ice: store max_frame and rx_buf_len only in ice_rx_ring Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 05/12] ice: Make use of assign_bit() API Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 06/12] ice: Use common error handling code in two functions Tony Nguyen
2024-10-09 2:23 ` Kalesh Anakkur Purayil
2024-10-08 23:34 ` [PATCH net-next 07/12] ice: Cleanup unused declarations Tony Nguyen
2024-10-09 2:22 ` Kalesh Anakkur Purayil
2024-10-08 23:34 ` [PATCH net-next 08/12] iavf: Remove " Tony Nguyen
2024-10-09 2:23 ` Kalesh Anakkur Purayil
2024-10-08 23:34 ` [PATCH net-next 09/12] igb: Cleanup " Tony Nguyen
2024-10-09 2:22 ` Kalesh Anakkur Purayil
2024-10-08 23:34 ` [PATCH net-next 10/12] e1000e: Remove duplicated writel() in e1000_configure_tx/rx() Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 11/12] e1000e: Link NAPI instances to queues and IRQs Tony Nguyen
2024-10-08 23:34 ` [PATCH net-next 12/12] e1000: " Tony Nguyen
2024-10-10 3:10 ` [PATCH net-next 00/12][pull request] Intel Wired LAN Driver Updates 2024-10-08 (ice, iavf, igb, e1000e, e1000) patchwork-bot+netdevbpf
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=20241008233441.928802-4-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=rafal.romanowski@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).