From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH S33 04/15] ice: Don't modify stripping for add/del VLANs on VF
Date: Fri, 8 Nov 2019 06:23:20 -0800 [thread overview]
Message-ID: <20191108142331.10221-4-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20191108142331.10221-1-anthony.l.nguyen@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
Currently when adding/deleting vlans in ice_vc_process_vlan_msg()
we are calling ice_vsi_manage_vlan_stripping() to enable/disable
when adding and deleting a VLAN respectively. This is wrong
because adding/deleting VLANs has nothing to do with configuring
VLAN stripping. VLAN stripping is configured through the
following VIRTCHNL operations:
VIRTCHNL_OP_ENABLE_VLAN_STRIPPING
VIRTCHNL_OP_DISABLE_VLAN_STRIPPING
Unfortunately we can't just remove this because then stripping
will never be configured on VF initialization. Fix this by
adding a new function that initializes (disables/enables) VLAN
stripping for the VF based on the device supported capabilities.
This allows us to remove the call to
ice_vsi_manage_vlan_stripping() in ice_vc_process_vlan_msg().
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
---
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 39 +++++++++++++++----
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 3cb394bdfe51..fd419230a6c0 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -2735,14 +2735,6 @@ static int ice_vc_process_vlan_msg(struct ice_vf *vf, u8 *msg, bool add_v)
goto error_param;
}
- if (ice_vsi_manage_vlan_stripping(vsi, add_v)) {
- dev_err(&pf->pdev->dev,
- "%sable VLAN stripping failed for VSI %i\n",
- add_v ? "en" : "dis", vsi->vsi_num);
- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
- goto error_param;
- }
-
if (test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) ||
test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states))
vlan_promisc = true;
@@ -2933,6 +2925,33 @@ static int ice_vc_dis_vlan_stripping(struct ice_vf *vf)
v_ret, NULL, 0);
}
+/**
+ * ice_vf_init_vlan_stripping - enable/disable VLAN stripping on initialization
+ * @vf: VF to enable/disable VLAN stripping for on initialization
+ *
+ * If the VIRTCHNL_VF_OFFLOAD_VLAN flag is set enable VLAN stripping, else if
+ * the flag is cleared then we want to disable stripping. For example, the flag
+ * will be cleared when port VLANs are configured by the administrator before
+ * passing the VF to the guest or if the AVF driver doesn't support VLAN
+ * offloads.
+ */
+static int ice_vf_init_vlan_stripping(struct ice_vf *vf)
+{
+ struct ice_vsi *vsi = vf->pf->vsi[vf->lan_vsi_idx];
+
+ if (!vsi)
+ return -EINVAL;
+
+ /* don't modify stripping if port VLAN is configured */
+ if (vsi->info.pvid)
+ return 0;
+
+ if (ice_vf_vlan_offload_ena(vf->driver_caps))
+ return ice_vsi_manage_vlan_stripping(vsi, true);
+ else
+ return ice_vsi_manage_vlan_stripping(vsi, false);
+}
+
/**
* ice_vc_process_vf_msg - Process request from VF
* @pf: pointer to the PF structure
@@ -2987,6 +3006,10 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
break;
case VIRTCHNL_OP_GET_VF_RESOURCES:
err = ice_vc_get_vf_res_msg(vf, msg);
+ if (ice_vf_init_vlan_stripping(vf))
+ dev_err(&pf->pdev->dev,
+ "Failed to initialize VLAN stripping for VF %d\n",
+ vf->vf_id);
ice_vc_notify_vf_link_state(vf);
break;
case VIRTCHNL_OP_RESET_VF:
--
2.20.1
next prev parent reply other threads:[~2019-11-08 14:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 14:23 [Intel-wired-lan] [PATCH S33 01/15] ice: Store number of functions for the device Tony Nguyen
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 02/15] ice: Correct capabilities reporting of max TCs Tony Nguyen
2019-11-12 19:30 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 03/15] ice: Disallow VF VLAN opcodes if VLAN offloads disabled Tony Nguyen
2019-11-12 19:31 ` Bowers, AndrewX
2019-11-08 14:23 ` Tony Nguyen [this message]
2019-11-12 19:32 ` [Intel-wired-lan] [PATCH S33 04/15] ice: Don't modify stripping for add/del VLANs on VF Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 05/15] ice: fix stack leakage Tony Nguyen
2019-11-12 19:32 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 06/15] ice: Only disable VF state when freeing each VF resources Tony Nguyen
2019-11-12 19:33 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 07/15] ice: Fix setting coalesce to handle DCB configuration Tony Nguyen
2019-11-12 19:33 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 08/15] ice: Refactor removal of VLAN promiscuous rules Tony Nguyen
2019-11-12 19:34 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 09/15] ice: Do not use devm* functions for local uses Tony Nguyen
2019-11-12 19:34 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 10/15] ice: Add ice_pf_to_dev(pf) macro Tony Nguyen
2019-11-12 19:35 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 11/15] ice: add helpers for virtchnl Tony Nguyen
2019-11-12 19:35 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 12/15] ice: implement VF stats NDO Tony Nguyen
2019-11-12 19:35 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 13/15] ice: Implement ethtool ops for channels Tony Nguyen
2019-11-12 19:36 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 14/15] ice: remove pointless NULL check of port_info Tony Nguyen
2019-11-12 19:36 ` Bowers, AndrewX
2019-11-08 14:23 ` [Intel-wired-lan] [PATCH S33 15/15] ice: Update FW API minor version Tony Nguyen
2019-11-12 19:37 ` Bowers, AndrewX
2019-11-12 19:30 ` [Intel-wired-lan] [PATCH S33 01/15] ice: Store number of functions for the device Bowers, AndrewX
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=20191108142331.10221-4-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@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