From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, Jacob Keller <jacob.e.keller@intel.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next 07/17] fm10k: Fix multicast mode sync issues
Date: Wed, 20 Apr 2016 23:09:19 -0700 [thread overview]
Message-ID: <1461218969-68578-8-git-send-email-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <1461218969-68578-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Multicast mode checking is no longer a requirement to perform unicast
and multicast address syncs. Specifically, a device operating in
promiscuous and/or all multicast mode is not excluded. The issue occurs
when the netdev is pre-configured to either multicast mode and is
enabled for the first time. The multicast-group table in the Switch
Manager will be missing obvious multicast entries associated to this
netdev.
Changes were also made to disallow unicast and multicast syncs with
VLAN 0. The Switch Manager considers VLAN 0 to be an invalid entry.
Requests with VLAN 0 by the netdev are only generated when the driver is
freshly installed and the default VID is not set.
Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 32778dd..bf229d5 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -877,7 +877,7 @@ static int __fm10k_uc_sync(struct net_device *dev,
return -EADDRNOTAVAIL;
/* update table with current entries */
- for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 0;
+ for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
vid < VLAN_N_VID;
vid = fm10k_find_next_vlan(interface, vid)) {
err = hw->mac.ops.update_uc_addr(hw, glort, addr,
@@ -940,7 +940,7 @@ static int __fm10k_mc_sync(struct net_device *dev,
u16 vid, glort = interface->glort;
/* update table with current entries */
- for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 0;
+ for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
vid < VLAN_N_VID;
vid = fm10k_find_next_vlan(interface, vid)) {
hw->mac.ops.update_mc_addr(hw, glort, addr, vid, sync);
@@ -995,11 +995,8 @@ static void fm10k_set_rx_mode(struct net_device *dev)
}
/* synchronize all of the addresses */
- if (xcast_mode != FM10K_XCAST_MODE_PROMISC) {
- __dev_uc_sync(dev, fm10k_uc_sync, fm10k_uc_unsync);
- if (xcast_mode != FM10K_XCAST_MODE_ALLMULTI)
- __dev_mc_sync(dev, fm10k_mc_sync, fm10k_mc_unsync);
- }
+ __dev_uc_sync(dev, fm10k_uc_sync, fm10k_uc_unsync);
+ __dev_mc_sync(dev, fm10k_mc_sync, fm10k_mc_unsync);
fm10k_mbx_unlock(interface);
}
@@ -1037,7 +1034,7 @@ void fm10k_restore_rx_state(struct fm10k_intfc *interface)
hw->mac.ops.update_vlan(hw, 0, 0, true);
/* update table with current entries */
- for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 0;
+ for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
vid < VLAN_N_VID;
vid = fm10k_find_next_vlan(interface, vid)) {
hw->mac.ops.update_vlan(hw, vid, 0, true);
@@ -1049,11 +1046,8 @@ void fm10k_restore_rx_state(struct fm10k_intfc *interface)
hw->mac.ops.update_xcast_mode(hw, glort, xcast_mode);
/* synchronize all of the addresses */
- if (xcast_mode != FM10K_XCAST_MODE_PROMISC) {
- __dev_uc_sync(netdev, fm10k_uc_sync, fm10k_uc_unsync);
- if (xcast_mode != FM10K_XCAST_MODE_ALLMULTI)
- __dev_mc_sync(netdev, fm10k_mc_sync, fm10k_mc_unsync);
- }
+ __dev_uc_sync(netdev, fm10k_uc_sync, fm10k_uc_unsync);
+ __dev_mc_sync(netdev, fm10k_mc_sync, fm10k_mc_unsync);
fm10k_mbx_unlock(interface);
--
2.5.5
next prev parent reply other threads:[~2016-04-21 6:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 6:09 [net-next 00/17][pull request] 100GbE Intel Wired LAN Driver Updates 2016-04-20 Jeff Kirsher
2016-04-21 6:09 ` [net-next 01/17] fm10k: add helper functions to set strings and data for ethtool stats Jeff Kirsher
2016-04-21 6:09 ` [net-next 02/17] fm10k: remove debug-statistics support Jeff Kirsher
2016-04-21 6:09 ` [net-next 03/17] fm10k: Add support for bulk Tx cleanup & cleanup boolean logic Jeff Kirsher
2016-04-21 6:09 ` [net-next 04/17] fm10k: use DRV_SUMMARY to reduce code duplication Jeff Kirsher
2016-04-21 6:09 ` [net-next 05/17] fm10k: prevent RCU issues during AER events Jeff Kirsher
2016-04-21 6:09 ` [net-next 06/17] fm10k: drop 1588 support Jeff Kirsher
2016-04-21 6:09 ` Jeff Kirsher [this message]
2016-04-21 6:09 ` [net-next 08/17] fm10k: correctly handle LPORT_MAP error Jeff Kirsher
2016-04-21 6:09 ` [net-next 09/17] fm10k: do not disable PCI device in fm10k_io_error_detected Jeff Kirsher
2016-04-21 6:09 ` [net-next 10/17] fm10k: fix documentation of fm10k_tlv_parse_attr Jeff Kirsher
2016-04-21 6:09 ` [net-next 11/17] fm10k: use 8bit notation instead of 10bit notation for diagram Jeff Kirsher
2016-04-21 6:09 ` [net-next 12/17] fm10k: use different name than FM10K_VLAN_CLEAR for override bit Jeff Kirsher
2016-04-21 6:09 ` [net-next 13/17] fm10k: update comment regarding reserved bits check Jeff Kirsher
2016-04-21 6:09 ` [net-next 14/17] fm10k: Reset multicast mode when deleting lport Jeff Kirsher
2016-04-21 6:09 ` [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc Jeff Kirsher
2016-04-21 19:44 ` Keller, Jacob E
2016-04-21 19:47 ` David Miller
2016-04-21 19:48 ` Jeff Kirsher
2016-04-21 20:09 ` Keller, Jacob E
2016-04-21 6:09 ` [net-next 16/17] fm10k: consistently use Intel(R) for driver names Jeff Kirsher
2016-04-21 6:09 ` [net-next 17/17] fm10k: fix incorrect IPv6 extended header checksum Jeff Kirsher
2016-04-21 16:21 ` [net-next 00/17][pull request] 100GbE Intel Wired LAN Driver Updates 2016-04-20 David Miller
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=1461218969-68578-8-git-send-email-jeffrey.t.kirsher@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=jogreene@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ngai-mint.kwan@intel.com \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.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 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).