Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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