All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Anthony Nguyen <anthony.l.nguyen@intel.com>,
	Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next 03/13] ice: move vsi_type assignment from ice_vsi_alloc to ice_vsi_cfg
Date: Wed, 18 Jan 2023 06:37:22 +0100	[thread overview]
Message-ID: <Y8eFkqSXDbTOAaL4@localhost.localdomain> (raw)
In-Reply-To: <a16975c6-55d7-1945-063e-6e0ccf5a10af@intel.com>

On Tue, Jan 17, 2023 at 11:20:43AM -0800, Jacob Keller wrote:
[...]
> >>  /**
> >> - * ice_vsi_cfg - configure VSI and tc on it
> >> + * ice_vsi_cfg - configure a previously allocated VSI
> >>   * @vsi: pointer to VSI
> >> + * @vsi_type: the type of VSI to configure as
> >> + * @pi: the port info for this VSI
> >>   * @vf: pointer to VF to which this VSI connects. This field is used primarily
> >>   *      for the ICE_VSI_VF type. Other VSI types should pass NULL.
> >>   * @ch: ptr to channel
> >>   * @init_vsi: is this an initialization or a reconfigure of the VSI
> >> + *
> >> + * Configure a VSI allocated with ice_vsi_alloc.
> >>   */
> >> -int ice_vsi_cfg(struct ice_vsi *vsi, struct ice_vf *vf, struct ice_channel *ch,
> >> -		int init_vsi)
> >> +int ice_vsi_cfg(struct ice_vsi *vsi, enum ice_vsi_type vsi_type,
> >> +		struct ice_port_info *pi, struct ice_vf *vf,
> >> +		struct ice_channel *ch, int init_vsi)
> >>  {
> >> +	struct ice_pf *pf = vsi->back;
> >>  	int ret;
> >>  
> >> +	if (WARN_ON(vsi_type == ICE_VSI_VF && !vf))
> >> +		return -EINVAL;
> >> +
> >> +	vsi->type = vsi_type;
> >> +	vsi->port_info = pi;
> >> +
> >> +	/* For VSIs which don't have a connected VF, this will be NULL */
> >> +	vsi->vf = vf;
> >> +
> >>  	ret = ice_vsi_cfg_def(vsi, ch, init_vsi);
> >>  	if (ret)
> >>  		return ret;
> >> @@ -2879,6 +2871,15 @@ int ice_vsi_cfg(struct ice_vsi *vsi, struct ice_vf *vf, struct ice_channel *ch,
> >>  	if (ret)
> >>  		ice_vsi_decfg(vsi);
> >>  
> >> +	if (vsi->type == ICE_VSI_CTRL) {
> >> +		if (vf) {
> > I know that it is only copy paste, but shouldn't we also check if
> > vsi_idx isn't already set like in PF case?
> > 
> Not sure what you mean? make sure idx is valid? but a memset of vsi will
> initialize that to 0 which will be "valid"?
> 
> or do you want to like confirm that the vsi->idx points to the vsi in
> the array with the right pointer?
> 

Maybe I am missing something. I assume that ther can be only one VF
control VSI on VF. If we set vf->ctrl_vsi_idx to the new value we will lost
previous one without removing the vsi index from hw. In case of PF
control VSI we have WARN_ON for this case:
WARN_ON(pf->ctr_idx != ICE_NO_VSI)

Shouldn't we have
WARN_ON(vf->ctrl_idx != ICE_NO_VSI)
to be sure that there is no more VF control VSIs on this VF?

When VF control VSI is removed the vf->ctr_vsi_idx is set to ICE_NO_VSI,
so it should work as expected.

Probably this case never happen (calling ice_vsi_setup() for VF control
VSI second time on the same VF), but if we have the security check for
PF it will be nice to have the same check for VF.

> >> +			vf->ctrl_vsi_idx = vsi->idx;
> >> +		} else {
> >> +			WARN_ON(pf->ctrl_vsi_idx != ICE_NO_VSI);
> >> +			pf->ctrl_vsi_idx = vsi->idx;
> >> +		}
> >> +	}
> >> +
> >>  	return ret;
> >>  }
> >>  
> >> @@ -2962,13 +2963,13 @@ ice_vsi_setup(struct ice_pf *pf, struct ice_port_info *pi,
> >>  	struct ice_vsi *vsi;
> >>  	int ret;
> >>  
> >> -	vsi = ice_vsi_alloc(pf, pi, vsi_type, ch, vf);
> >> +	vsi = ice_vsi_alloc(pf);
> > Looks nicer :)
> > 
> 
> :) we just moved the mess a bit.
> 
> >>  	if (!vsi) {
> >>  		dev_err(dev, "could not allocate VSI\n");
> >>  		return NULL;
> >>  	}
> >>  
> >> -	ret = ice_vsi_cfg(vsi, vf, ch, ICE_VSI_FLAG_INIT);
> >> +	ret = ice_vsi_cfg(vsi, vsi_type, pi, vf, ch, ICE_VSI_FLAG_INIT);
> > Maybe it is good patchset to implement Your idea about having vsi init
> > params structure?
> > 
> 
> 
> Probably.. I was sending what I had in our internal subfunction +
> scalable tree, so I don't have that developed yet.
> 

Sure

> >>  	if (ret)
> >>  		goto err_vsi_cfg;
> >>  
> >> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/ethernet/intel/ice/ice_lib.h
> >> index b76f05e1f8a3..fb785d8cde9a 100644
> >> --- a/drivers/net/ethernet/intel/ice/ice_lib.h
> >> +++ b/drivers/net/ethernet/intel/ice/ice_lib.h
> >> @@ -73,7 +73,8 @@ ice_get_res(struct ice_pf *pf, struct ice_res_tracker *res, u16 needed, u16 id);
> >>  #define ICE_VSI_FLAG_INIT	BIT(0)
> >>  #define ICE_VSI_FLAG_NO_INIT	0
> >>  int ice_vsi_rebuild(struct ice_vsi *vsi, int init_vsi);
> >> -int ice_vsi_cfg(struct ice_vsi *vsi, struct ice_vf *vf,
> >> +int ice_vsi_cfg(struct ice_vsi *vsi, enum ice_vsi_type vsi_type,
> >> +		struct ice_port_info *pi, struct ice_vf *vf,
> >>  		struct ice_channel *ch, int init_vsi);
> >>  
> >>  bool ice_is_reset_in_progress(unsigned long *state);
> >> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> >> index 8fd9c87f30e2..29cd77dd3812 100644
> >> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> >> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> >> @@ -5010,7 +5010,8 @@ int ice_load(struct ice_pf *pf)
> >>  		return err;
> >>  
> >>  	vsi = ice_get_main_vsi(pf);
> >> -	err = ice_vsi_cfg(vsi, NULL, NULL, ICE_VSI_FLAG_INIT);
> >> +	err = ice_vsi_cfg(vsi, ICE_VSI_PF, pf->hw.port_info, NULL, NULL,
> >> +			  ICE_VSI_FLAG_INIT);
> >>  	if (err)
> >>  		goto err_vsi_cfg;
> >>  
> >> -- 
> >> 2.38.1.420.g319605f8f00e
> >>
> >> _______________________________________________
> >> Intel-wired-lan mailing list
> >> Intel-wired-lan@osuosl.org
> >> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-01-18  5:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 22:37 [Intel-wired-lan] [PATCH net-next 00/13] ice: various virtualization cleanups Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 01/13] ice: fix function comment referring to ice_vsi_alloc Jacob Keller
2023-01-16 10:31   ` Michal Swiatkowski
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 02/13] ice: drop unnecessary VF parameter from several VSI functions Jacob Keller
2023-01-16 10:34   ` Michal Swiatkowski
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 03/13] ice: move vsi_type assignment from ice_vsi_alloc to ice_vsi_cfg Jacob Keller
2023-01-16 10:47   ` Michal Swiatkowski
2023-01-17 19:20     ` Jacob Keller
2023-01-18  5:37       ` Michal Swiatkowski [this message]
2023-01-18 20:50         ` Jacob Keller
2023-01-17 22:24     ` Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 04/13] ice: add helper function for checking VSI VF requirement Jacob Keller
2023-01-16 10:56   ` Michal Swiatkowski
2023-01-17 19:23     ` Jacob Keller
2023-01-18  5:24       ` Michal Swiatkowski
2023-01-18 20:49         ` Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 05/13] ice: Fix RDMA latency issue by allowing write-combining Jacob Keller
2023-01-14  0:37   ` kernel test robot
2023-01-14  0:37     ` kernel test robot
2023-01-14  1:58   ` kernel test robot
2023-01-14  1:58     ` kernel test robot
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 06/13] ice: move ice_vf_vsi_release into ice_vf_lib.c Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 07/13] ice: Pull common tasks into ice_vf_post_vsi_rebuild Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 08/13] ice: add a function to initialize vf entry Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 09/13] ice: introduce ice_vf_init_host_cfg function Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 10/13] ice: convert vf_ops .vsi_rebuild to .create_vsi Jacob Keller
2023-01-27  9:46   ` Szlosek, Marek
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 11/13] ice: introduce clear_reset_state operation Jacob Keller
2023-01-14  1:17   ` kernel test robot
2023-01-14  1:17     ` kernel test robot
2023-01-14  3:49   ` kernel test robot
2023-01-14  3:49     ` kernel test robot
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 12/13] ice: introduce .irq_close VF operation Jacob Keller
2023-01-13 22:37 ` [Intel-wired-lan] [PATCH net-next 13/13] ice: remove unnecessary virtchnl_ether_addr struct use Jacob Keller

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=Y8eFkqSXDbTOAaL4@localhost.localdomain \
    --to=michal.swiatkowski@linux.intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.