From: Alexander Duyck <aduyck@mirantis.com>
To: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
Cc: jeffrey.t.kirsher@intel.com
Subject: [next PATCH 04/11] ixgbe: Reduce VT code indent in set_vfta by introducing jump label
Date: Mon, 02 Nov 2015 17:09:48 -0800 [thread overview]
Message-ID: <20151103010948.28233.88958.stgit@localhost.localdomain> (raw)
In-Reply-To: <20151103005850.28233.63113.stgit@localhost.localdomain>
In order to clear the way for upcoming work I thought it best to drop the
level of indent in the ixgbe_set_vfta_generic function. Most of the code
is held in the virtualization specific section. So the easiest approach is
to just add a jump label and jump past the bulk of the code if it is not
enabled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 142 +++++++++++------------
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 027c1ad3e8cb..f608973ae73e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -3051,8 +3051,8 @@ s32 ixgbe_set_vfta_generic(struct ixgbe_hw *hw, u32 vlan, u32 vind,
bool vlan_on)
{
u32 regidx, vfta_delta, vfta;
+ s32 vlvf_index;
u32 bits;
- u32 vt;
if (vlan > 4095)
return IXGBE_ERR_PARAM;
@@ -3088,83 +3088,81 @@ s32 ixgbe_set_vfta_generic(struct ixgbe_hw *hw, u32 vlan, u32 vind,
* Or !vlan_on
* clear the pool bit and possibly the vind
*/
- vt = IXGBE_READ_REG(hw, IXGBE_VT_CTL);
- if (vt & IXGBE_VT_CTL_VT_ENABLE) {
- s32 vlvf_index;
-
- vlvf_index = ixgbe_find_vlvf_slot(hw, vlan);
- if (vlvf_index < 0)
- return vlvf_index;
-
- if (vlan_on) {
- /* set the pool bit */
- if (vind < 32) {
- bits = IXGBE_READ_REG(hw,
- IXGBE_VLVFB(vlvf_index*2));
- bits |= (1 << vind);
- IXGBE_WRITE_REG(hw,
- IXGBE_VLVFB(vlvf_index*2),
- bits);
- } else {
- bits = IXGBE_READ_REG(hw,
- IXGBE_VLVFB((vlvf_index*2)+1));
- bits |= (1 << (vind-32));
- IXGBE_WRITE_REG(hw,
- IXGBE_VLVFB((vlvf_index*2)+1),
- bits);
- }
+ if (!(IXGBE_READ_REG(hw, IXGBE_VT_CTL) & IXGBE_VT_CTL_VT_ENABLE))
+ goto vfta_update;
+
+ vlvf_index = ixgbe_find_vlvf_slot(hw, vlan);
+ if (vlvf_index < 0)
+ return vlvf_index;
+
+ if (vlan_on) {
+ /* set the pool bit */
+ if (vind < 32) {
+ bits = IXGBE_READ_REG(hw,
+ IXGBE_VLVFB(vlvf_index*2));
+ bits |= (1 << vind);
+ IXGBE_WRITE_REG(hw,
+ IXGBE_VLVFB(vlvf_index*2),
+ bits);
} else {
- /* clear the pool bit */
- if (vind < 32) {
- bits = IXGBE_READ_REG(hw,
- IXGBE_VLVFB(vlvf_index*2));
- bits &= ~(1 << vind);
- IXGBE_WRITE_REG(hw,
- IXGBE_VLVFB(vlvf_index*2),
- bits);
- bits |= IXGBE_READ_REG(hw,
- IXGBE_VLVFB((vlvf_index*2)+1));
- } else {
- bits = IXGBE_READ_REG(hw,
- IXGBE_VLVFB((vlvf_index*2)+1));
- bits &= ~(1 << (vind-32));
- IXGBE_WRITE_REG(hw,
- IXGBE_VLVFB((vlvf_index*2)+1),
- bits);
- bits |= IXGBE_READ_REG(hw,
- IXGBE_VLVFB(vlvf_index*2));
- }
+ bits = IXGBE_READ_REG(hw,
+ IXGBE_VLVFB((vlvf_index*2)+1));
+ bits |= (1 << (vind-32));
+ IXGBE_WRITE_REG(hw,
+ IXGBE_VLVFB((vlvf_index*2)+1),
+ bits);
}
-
- /*
- * If there are still bits set in the VLVFB registers
- * for the VLAN ID indicated we need to see if the
- * caller is requesting that we clear the VFTA entry bit.
- * If the caller has requested that we clear the VFTA
- * entry bit but there are still pools/VFs using this VLAN
- * ID entry then ignore the request. We're not worried
- * about the case where we're turning the VFTA VLAN ID
- * entry bit on, only when requested to turn it off as
- * there may be multiple pools and/or VFs using the
- * VLAN ID entry. In that case we cannot clear the
- * VFTA bit until all pools/VFs using that VLAN ID have also
- * been cleared. This will be indicated by "bits" being
- * zero.
- */
- if (bits) {
- IXGBE_WRITE_REG(hw, IXGBE_VLVF(vlvf_index),
- (IXGBE_VLVF_VIEN | vlan));
-
- /* if someone wants to clear the vfta entry but
- * some pools/VFs are still using it. Ignore it.
- */
- if (!vlan_on)
- vfta_delta = 0;
+ } else {
+ /* clear the pool bit */
+ if (vind < 32) {
+ bits = IXGBE_READ_REG(hw,
+ IXGBE_VLVFB(vlvf_index*2));
+ bits &= ~(1 << vind);
+ IXGBE_WRITE_REG(hw,
+ IXGBE_VLVFB(vlvf_index*2),
+ bits);
+ bits |= IXGBE_READ_REG(hw,
+ IXGBE_VLVFB((vlvf_index*2)+1));
} else {
- IXGBE_WRITE_REG(hw, IXGBE_VLVF(vlvf_index), 0);
+ bits = IXGBE_READ_REG(hw,
+ IXGBE_VLVFB((vlvf_index*2)+1));
+ bits &= ~(1 << (vind-32));
+ IXGBE_WRITE_REG(hw,
+ IXGBE_VLVFB((vlvf_index*2)+1),
+ bits);
+ bits |= IXGBE_READ_REG(hw,
+ IXGBE_VLVFB(vlvf_index*2));
}
}
+ /* If there are still bits set in the VLVFB registers
+ * for the VLAN ID indicated we need to see if the
+ * caller is requesting that we clear the VFTA entry bit.
+ * If the caller has requested that we clear the VFTA
+ * entry bit but there are still pools/VFs using this VLAN
+ * ID entry then ignore the request. We're not worried
+ * about the case where we're turning the VFTA VLAN ID
+ * entry bit on, only when requested to turn it off as
+ * there may be multiple pools and/or VFs using the
+ * VLAN ID entry. In that case we cannot clear the
+ * VFTA bit until all pools/VFs using that VLAN ID have also
+ * been cleared. This will be indicated by "bits" being
+ * zero.
+ */
+ if (bits) {
+ IXGBE_WRITE_REG(hw, IXGBE_VLVF(vlvf_index),
+ (IXGBE_VLVF_VIEN | vlan));
+
+ /* if someone wants to clear the vfta entry but
+ * some pools/VFs are still using it. Ignore it.
+ */
+ if (!vlan_on)
+ vfta_delta = 0;
+ } else {
+ IXGBE_WRITE_REG(hw, IXGBE_VLVF(vlvf_index), 0);
+ }
+
+vfta_update:
if (vfta_delta)
IXGBE_WRITE_REG(hw, IXGBE_VFTA(regidx), vfta);
next prev parent reply other threads:[~2015-11-03 1:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 1:09 [next PATCH 00/11] ixgbe: Add support for mixed PF/VF virtualization Alexander Duyck
2015-11-03 1:09 ` [next PATCH 01/11] ixgbe: Return error on failure to allocate mac_table Alexander Duyck
2015-12-10 22:51 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:09 ` [next PATCH 02/11] ixgbe: Fix SR-IOV VLAN pool configuration Alexander Duyck
2015-12-10 22:52 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:09 ` [next PATCH 03/11] ixgbe: Simplify definitions for regidx and bit in set_vfta Alexander Duyck
2015-12-10 22:52 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:09 ` Alexander Duyck [this message]
2015-12-10 22:52 ` [Intel-wired-lan] [next PATCH 04/11] ixgbe: Reduce VT code indent in set_vfta by introducing jump label Schmitt, Phillip J
2015-11-03 1:09 ` [next PATCH 05/11] ixgbe: Simplify configuration of setting VLVF and VLVFB Alexander Duyck
2015-12-10 22:52 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 06/11] ixgbe: Add support for adding/removing VLAN on PF bypassing the VLVF Alexander Duyck
2015-12-10 22:52 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 07/11] ixgbe: Reorder search to work from the top down instead of bottom up Alexander Duyck
2015-12-10 22:53 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 08/11] ixgbe: Add support for VLAN promiscuous with SR-IOV Alexander Duyck
2015-12-10 22:53 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 09/11] ixgbe: Fix VLAN promisc in relation to SR-IOV Alexander Duyck
2015-12-10 22:53 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 10/11] ixgbe: Clear stale pool mappings Alexander Duyck
2015-12-10 22:53 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 1:10 ` [next PATCH 11/11] ixgbe: Clean stale VLANs when changing port vlan or resetting Alexander Duyck
2015-12-10 22:54 ` [Intel-wired-lan] " Schmitt, Phillip J
2015-11-03 12:38 ` [next PATCH 00/11] ixgbe: Add support for mixed PF/VF virtualization Jeff Kirsher
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=20151103010948.28233.88958.stgit@localhost.localdomain \
--to=aduyck@mirantis.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).