From: Jacob Keller <jacob.e.keller@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [net-next PATCH 07/11] ice: use ice_for_each_vf for iteration during removal
Date: Tue, 15 Feb 2022 17:31:23 -0800 [thread overview]
Message-ID: <20220216013127.3263153-8-jacob.e.keller@intel.com> (raw)
In-Reply-To: <20220216013127.3263153-1-jacob.e.keller@intel.com>
When removing VFs, the driver takes a weird approach of assigning
pf->num_alloc_vfs to 0 before iterating over the VFs using a temporary
variable.
This logic has been in the driver for a long time, and seems to have
been carried forward from i40e.
We want to refactor the way VFs are stored, and iterating over the data
structure without the ice_for_each_vf interface impedes this work.
The logic relies on implicitly using the num_alloc_vfs as a sort of
"safe guard" for accessing VF data.
While this sort of guard makes sense for Single Root IOV where all VFs
are added at once, the data structures don't work for VFs which can be
added and removed dynamically. We also have a separate state flag,
ICE_VF_DEINIT_IN_PROGRESS which is a stronger protection against
concurrent removal and access.
Avoid the custom tmp iteration and replace it with the standard
ice_for_each_vf iterator. Delay the assignment of num_alloc_vfs until
after this loop finishes.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 6351af58f74e..3e2357460f34 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -500,7 +500,7 @@ void ice_free_vfs(struct ice_pf *pf)
{
struct device *dev = ice_pf_to_dev(pf);
struct ice_hw *hw = &pf->hw;
- unsigned int tmp, i;
+ unsigned int i;
if (!pf->vf)
return;
@@ -519,10 +519,7 @@ void ice_free_vfs(struct ice_pf *pf)
else
dev_warn(dev, "VFs are assigned - not disabling SR-IOV\n");
- tmp = pf->num_alloc_vfs;
- pf->num_qps_per_vf = 0;
- pf->num_alloc_vfs = 0;
- for (i = 0; i < tmp; i++) {
+ ice_for_each_vf(pf, i) {
struct ice_vf *vf = &pf->vf[i];
mutex_lock(&vf->cfg_lock);
@@ -558,6 +555,8 @@ void ice_free_vfs(struct ice_pf *pf)
if (ice_sriov_free_msix_res(pf))
dev_err(dev, "Failed to free MSIX resources used by SR-IOV\n");
+ pf->num_qps_per_vf = 0;
+ pf->num_alloc_vfs = 0;
devm_kfree(dev, pf->vf);
pf->vf = NULL;
--
2.35.1.129.gb80121027d12
next prev parent reply other threads:[~2022-02-16 1:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 1:31 [Intel-wired-lan] [net-next PATCH 00/11] ice: convert VF storage to hash table Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 01/11] ice: refactor unwind cleanup in eswitch mode Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 02/11] ice: store VF pointer instead of VF ID Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 03/11] ice: pass num_vfs to ice_set_per_vf_res() Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 04/11] ice: move clear_malvf call in ice_free_vfs Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 05/11] ice: move VFLR acknowledge during ice_free_vfs Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 06/11] ice: remove checks in ice_vc_send_msg_to_vf Jacob Keller
2022-02-16 1:31 ` Jacob Keller [this message]
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 08/11] ice: convert ice_for_each_vf to include VF entry iterator Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 09/11] ice: factor VF variables to separate structure Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 10/11] ice: introduce VF accessor functions Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 11/11] ice: convert VF storage to hash table with krefs and RCU Jacob Keller
2022-02-16 1:43 ` Keller, Jacob E
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=20220216013127.3263153-8-jacob.e.keller@intel.com \
--to=jacob.e.keller@intel.com \
--cc=intel-wired-lan@osuosl.org \
/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