Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
Cc: Anthony Nguyen <anthony.l.nguyen@intel.com>
Subject: [Intel-wired-lan] [PATCH net-next v2 04/13] ice: move vsi_type assignment from ice_vsi_alloc to ice_vsi_cfg
Date: Wed, 18 Jan 2023 17:16:44 -0800	[thread overview]
Message-ID: <20230119011653.311675-5-jacob.e.keller@intel.com> (raw)
In-Reply-To: <20230119011653.311675-1-jacob.e.keller@intel.com>

The ice_vsi_alloc and ice_vsi_cfg functions are used together to allocate
and configure a new VSI, called as part of the ice_vsi_setup function.

In the future with the addition of the subfunction code the ice driver
will want to be able to allocate a VSI while delaying the configuration to
a later point of the port activation.

Currently this requires that the port code know what type of VSI should
be allocated. This is required because ice_vsi_alloc assigns the VSI type.

Refactor the ice_vsi_alloc and ice_vsi_cfg functions so that VSI type
assignment isn't done until the configuration stage. This will allow the
devlink port addition logic to reserve a VSI as early as possible before
the type of the port is known. In this way, the port add can fail in the
event that all hardware VSI resources are exhausted.

Since the ice_vsi_cfg function already takes the ice_vsi_cfg_params
structure, this is relatively straight forward.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
Changes since v1:
* Re-order after new patch
* Changed to take into account ice_vsi_cfg_params

 drivers/net/ethernet/intel/ice/ice_lib.c | 51 ++++++++++++------------
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 1a2af5a9cffe..e2f0b28a89d7 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -639,23 +639,18 @@ ice_vsi_alloc_def(struct ice_vsi *vsi, struct ice_channel *ch)
 /**
  * ice_vsi_alloc - Allocates the next available struct VSI in the PF
  * @pf: board private structure
- * @params: parameters to use when allocating the new VSI
  *
- * The VF pointer is used for ICE_VSI_VF and ICE_VSI_CTRL. For ICE_VSI_CTRL,
- * it may be NULL in the case there is no association with a VF. For
- * ICE_VSI_VF the VF pointer *must not* be NULL.
+ * Reserves a VSI index from the PF and allocates an empty VSI structure
+ * without a type. The VSI structure must later be initialized by calling
+ * ice_vsi_cfg().
  *
  * returns a pointer to a VSI on success, NULL on failure.
  */
-static struct ice_vsi *
-ice_vsi_alloc(struct ice_pf *pf, struct ice_vsi_cfg_params *params)
+static struct ice_vsi *ice_vsi_alloc(struct ice_pf *pf)
 {
 	struct device *dev = ice_pf_to_dev(pf);
 	struct ice_vsi *vsi = NULL;
 
-	if (WARN_ON(params->type == ICE_VSI_VF && !params->vf))
-		return NULL;
-
 	/* Need to protect the allocation of the VSIs at the PF level */
 	mutex_lock(&pf->sw_mutex);
 
@@ -672,11 +667,7 @@ ice_vsi_alloc(struct ice_pf *pf, struct ice_vsi_cfg_params *params)
 	if (!vsi)
 		goto unlock_pf;
 
-	vsi->type = params->type;
 	vsi->back = pf;
-	vsi->port_info = params->pi;
-	/* For VSIs which don't have a connected VF, this will be NULL */
-	vsi->vf = params->vf;
 	set_bit(ICE_VSI_DOWN, vsi->state);
 
 	/* fill slot and make note of the index */
@@ -687,16 +678,6 @@ ice_vsi_alloc(struct ice_pf *pf, struct ice_vsi_cfg_params *params)
 	pf->next_vsi = ice_get_free_slot(pf->vsi, pf->num_alloc_vsi,
 					 pf->next_vsi);
 
-	if (vsi->type == ICE_VSI_CTRL) {
-		if (vsi->vf) {
-			WARN_ON(vsi->vf->ctrl_vsi_idx != ICE_NO_VSI);
-			vsi->vf->ctrl_vsi_idx = vsi->idx;
-		} else {
-			WARN_ON(pf->ctrl_vsi_idx != ICE_NO_VSI);
-			pf->ctrl_vsi_idx = vsi->idx;
-		}
-	}
-
 unlock_pf:
 	mutex_unlock(&pf->sw_mutex);
 	return vsi;
@@ -2856,14 +2837,24 @@ ice_vsi_cfg_def(struct ice_vsi *vsi, struct ice_vsi_cfg_params *params)
 }
 
 /**
- * ice_vsi_cfg - configure VSI and tc on it
+ * ice_vsi_cfg - configure a previously allocated VSI
  * @vsi: pointer to VSI
  * @params: parameters used to configure this VSI
  */
 int ice_vsi_cfg(struct ice_vsi *vsi, struct ice_vsi_cfg_params *params)
 {
+	struct ice_pf *pf = vsi->back;
 	int ret;
 
+	if (WARN_ON(params->type == ICE_VSI_VF && !params->vf))
+		return -EINVAL;
+
+	vsi->type = params->type;
+	vsi->port_info = params->pi;
+
+	/* For VSIs which don't have a connected VF, this will be NULL */
+	vsi->vf = params->vf;
+
 	ret = ice_vsi_cfg_def(vsi, params);
 	if (ret)
 		return ret;
@@ -2872,6 +2863,16 @@ int ice_vsi_cfg(struct ice_vsi *vsi, struct ice_vsi_cfg_params *params)
 	if (ret)
 		ice_vsi_decfg(vsi);
 
+	if (vsi->type == ICE_VSI_CTRL) {
+		if (vsi->vf) {
+			WARN_ON(vsi->vf->ctrl_vsi_idx != ICE_NO_VSI);
+			vsi->vf->ctrl_vsi_idx = vsi->idx;
+		} else {
+			WARN_ON(pf->ctrl_vsi_idx != ICE_NO_VSI);
+			pf->ctrl_vsi_idx = vsi->idx;
+		}
+	}
+
 	return ret;
 }
 
@@ -2956,7 +2957,7 @@ ice_vsi_setup(struct ice_pf *pf, struct ice_vsi_cfg_params *params)
 	    WARN_ON(!params->pi))
 		return NULL;
 
-	vsi = ice_vsi_alloc(pf, params);
+	vsi = ice_vsi_alloc(pf);
 	if (!vsi) {
 		dev_err(dev, "could not allocate VSI\n");
 		return NULL;
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  parent reply	other threads:[~2023-01-19  1:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19  1:16 [Intel-wired-lan] [PATCH net-next v2 00/13] ice: various virtualization cleanups Jacob Keller
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 01/13] ice: fix function comment referring to ice_vsi_alloc Jacob Keller
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 02/13] ice: drop unnecessary VF parameter from several VSI functions Jacob Keller
2023-01-26  9:36   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 03/13] ice: refactor VSI setup to use parameter structure Jacob Keller
2023-01-24  3:15   ` G, GurucharanX
2023-01-19  1:16 ` Jacob Keller [this message]
2023-01-24  3:16   ` [Intel-wired-lan] [PATCH net-next v2 04/13] ice: move vsi_type assignment from ice_vsi_alloc to ice_vsi_cfg G, GurucharanX
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 05/13] ice: Fix RDMA latency issue by allowing write-combining Jacob Keller
2023-01-25 15:21   ` Andrysiak, Jakub
2023-01-30 10:03   ` Alexander Lobakin
2023-01-30 23:34     ` Keller, Jacob E
2023-01-31  0:26       ` Tony Nguyen
2023-01-31 22:57       ` Jacob Keller
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 06/13] ice: move ice_vf_vsi_release into ice_vf_lib.c Jacob Keller
2023-01-26  9:36   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 07/13] ice: Pull common tasks into ice_vf_post_vsi_rebuild Jacob Keller
2023-01-26  9:37   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 08/13] ice: add a function to initialize vf entry Jacob Keller
2023-01-26  9:38   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 09/13] ice: introduce ice_vf_init_host_cfg function Jacob Keller
2023-01-26  9:38   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 10/13] ice: convert vf_ops .vsi_rebuild to .create_vsi Jacob Keller
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 11/13] ice: introduce clear_reset_state operation Jacob Keller
2023-01-19  8:42   ` Paul Menzel
2023-01-19 19:18     ` Jacob Keller
2023-01-27  9:48   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 12/13] ice: introduce .irq_close VF operation Jacob Keller
2023-01-27  9:48   ` Szlosek, Marek
2023-01-19  1:16 ` [Intel-wired-lan] [PATCH net-next v2 13/13] ice: remove unnecessary virtchnl_ether_addr struct use Jacob Keller
2023-01-27  9:49   ` Szlosek, Marek

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=20230119011653.311675-5-jacob.e.keller@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.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