* [net 04/14] ice: Free VSI contexts during for unload
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem
Cc: Victor Raj, netdev, nhorman, sassmann, Anirudh Venkataramanan,
Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Victor Raj <victor.raj@intel.com>
In the unload path, all VSIs are freed. Also free the related VSI
contexts to prevent memory leaks.
Signed-off-by: Victor Raj <victor.raj@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_common.c | 3 +++
drivers/net/ethernet/intel/ice/ice_switch.c | 12 ++++++++++++
drivers/net/ethernet/intel/ice/ice_switch.h | 2 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index 8cd6a2401fd9..554fd707a6d6 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -811,6 +811,9 @@ void ice_deinit_hw(struct ice_hw *hw)
/* Attempt to disable FW logging before shutting down control queues */
ice_cfg_fw_log(hw, false);
ice_shutdown_all_ctrlq(hw);
+
+ /* Clear VSI contexts if not already cleared */
+ ice_clear_all_vsi_ctx(hw);
}
/**
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 33403f39f1b3..40c9c6558956 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -347,6 +347,18 @@ static void ice_clear_vsi_ctx(struct ice_hw *hw, u16 vsi_handle)
}
}
+/**
+ * ice_clear_all_vsi_ctx - clear all the VSI context entries
+ * @hw: pointer to the hw struct
+ */
+void ice_clear_all_vsi_ctx(struct ice_hw *hw)
+{
+ u16 i;
+
+ for (i = 0; i < ICE_MAX_VSI; i++)
+ ice_clear_vsi_ctx(hw, i);
+}
+
/**
* ice_add_vsi - add VSI context to the hardware and VSI handle list
* @hw: pointer to the hw struct
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h
index b88d96a1ef69..d5ef0bd58bf9 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.h
+++ b/drivers/net/ethernet/intel/ice/ice_switch.h
@@ -190,6 +190,8 @@ ice_update_vsi(struct ice_hw *hw, u16 vsi_handle, struct ice_vsi_ctx *vsi_ctx,
struct ice_sq_cd *cd);
bool ice_is_vsi_valid(struct ice_hw *hw, u16 vsi_handle);
struct ice_vsi_ctx *ice_get_vsi_ctx(struct ice_hw *hw, u16 vsi_handle);
+void ice_clear_all_vsi_ctx(struct ice_hw *hw);
+/* Switch config */
enum ice_status ice_get_initial_sw_cfg(struct ice_hw *hw);
/* Switch/bridge related commands */
--
2.19.1
^ permalink raw reply related
* [net 07/14] ice: Fix typo in error message
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem
Cc: Anirudh Venkataramanan, netdev, nhorman, sassmann,
Akeem G Abodunrin, Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Print should say "Enabling" instead of "Enaabling"
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 5bacad01f0c9..c604a44c8cfb 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1997,7 +1997,7 @@ int ice_cfg_vlan_pruning(struct ice_vsi *vsi, bool ena)
status = ice_update_vsi(&vsi->back->hw, vsi->idx, ctxt, NULL);
if (status) {
netdev_err(vsi->netdev, "%sabling VLAN pruning on VSI handle: %d, VSI HW ID: %d failed, err = %d, aq_err = %d\n",
- ena ? "Ena" : "Dis", vsi->idx, vsi->vsi_num, status,
+ ena ? "En" : "Dis", vsi->idx, vsi->vsi_num, status,
vsi->back->hw.adminq.sq_last_status);
goto err_out;
}
--
2.19.1
^ permalink raw reply related
* [net 06/14] ice: Fix flags for port VLAN
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem
Cc: Md Fahad Iqbal Polash, netdev, nhorman, sassmann,
Anirudh Venkataramanan, Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Md Fahad Iqbal Polash <md.fahad.iqbal.polash@intel.com>
According to the spec, whenever insert PVID field is set, the VLAN
driver insertion mode should be set to 01b which isn't done currently.
Fix it.
Signed-off-by: Md Fahad Iqbal Polash <md.fahad.iqbal.polash@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 9576b958622b..e71065f9d391 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -348,7 +348,7 @@ static int ice_vsi_set_pvid(struct ice_vsi *vsi, u16 vid)
struct ice_vsi_ctx ctxt = { 0 };
enum ice_status status;
- ctxt.info.vlan_flags = ICE_AQ_VSI_VLAN_MODE_TAGGED |
+ ctxt.info.vlan_flags = ICE_AQ_VSI_VLAN_MODE_UNTAGGED |
ICE_AQ_VSI_PVLAN_INSERT_PVID |
ICE_AQ_VSI_VLAN_EMOD_STR;
ctxt.info.pvid = cpu_to_le16(vid);
--
2.19.1
^ permalink raw reply related
* [net 05/14] ice: Remove duplicate addition of VLANs in replay path
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem; +Cc: Anirudh Venkataramanan, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
ice_restore_vlan and active_vlans were originally put in place to
reprogram VLAN filters in the replay path. This is now done as part
of the much broader VSI rebuild/replay framework. So remove both
ice_restore_vlan and active_vlans
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 1 -
drivers/net/ethernet/intel/ice/ice_main.c | 42 +++----------------
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 2 -
3 files changed, 6 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index e5b37fa60884..1639e955f158 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -191,7 +191,6 @@ struct ice_vsi {
u64 tx_linearize;
DECLARE_BITMAP(state, __ICE_STATE_NBITS);
DECLARE_BITMAP(flags, ICE_VSI_FLAG_NBITS);
- unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
unsigned int current_netdev_flags;
u32 tx_restart;
u32 tx_busy;
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index aee22f11a41a..338abb1b9233 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1622,7 +1622,6 @@ static int ice_vlan_rx_add_vid(struct net_device *netdev,
{
struct ice_netdev_priv *np = netdev_priv(netdev);
struct ice_vsi *vsi = np->vsi;
- int ret;
if (vid >= VLAN_N_VID) {
netdev_err(netdev, "VLAN id requested %d is out of range %d\n",
@@ -1635,7 +1634,8 @@ static int ice_vlan_rx_add_vid(struct net_device *netdev,
/* Enable VLAN pruning when VLAN 0 is added */
if (unlikely(!vid)) {
- ret = ice_cfg_vlan_pruning(vsi, true);
+ int ret = ice_cfg_vlan_pruning(vsi, true);
+
if (ret)
return ret;
}
@@ -1644,12 +1644,7 @@ static int ice_vlan_rx_add_vid(struct net_device *netdev,
* needed to continue allowing all untagged packets since VLAN prune
* list is applied to all packets by the switch
*/
- ret = ice_vsi_add_vlan(vsi, vid);
-
- if (!ret)
- set_bit(vid, vsi->active_vlans);
-
- return ret;
+ return ice_vsi_add_vlan(vsi, vid);
}
/**
@@ -1677,8 +1672,6 @@ static int ice_vlan_rx_kill_vid(struct net_device *netdev,
if (status)
return status;
- clear_bit(vid, vsi->active_vlans);
-
/* Disable VLAN pruning when VLAN 0 is removed */
if (unlikely(!vid))
status = ice_cfg_vlan_pruning(vsi, false);
@@ -2515,31 +2508,6 @@ static int ice_vsi_vlan_setup(struct ice_vsi *vsi)
return ret;
}
-/**
- * ice_restore_vlan - Reinstate VLANs when vsi/netdev comes back up
- * @vsi: the VSI being brought back up
- */
-static int ice_restore_vlan(struct ice_vsi *vsi)
-{
- int err;
- u16 vid;
-
- if (!vsi->netdev)
- return -EINVAL;
-
- err = ice_vsi_vlan_setup(vsi);
- if (err)
- return err;
-
- for_each_set_bit(vid, vsi->active_vlans, VLAN_N_VID) {
- err = ice_vlan_rx_add_vid(vsi->netdev, htons(ETH_P_8021Q), vid);
- if (err)
- break;
- }
-
- return err;
-}
-
/**
* ice_vsi_cfg - Setup the VSI
* @vsi: the VSI being configured
@@ -2552,7 +2520,9 @@ static int ice_vsi_cfg(struct ice_vsi *vsi)
if (vsi->netdev) {
ice_set_rx_mode(vsi->netdev);
- err = ice_restore_vlan(vsi);
+
+ err = ice_vsi_vlan_setup(vsi);
+
if (err)
return err;
}
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 45f10f8f01dc..9576b958622b 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -2171,7 +2171,6 @@ static int ice_vc_process_vlan_msg(struct ice_vf *vf, u8 *msg, bool add_v)
if (!ice_vsi_add_vlan(vsi, vid)) {
vf->num_vlan++;
- set_bit(vid, vsi->active_vlans);
/* Enable VLAN pruning when VLAN 0 is added */
if (unlikely(!vid))
@@ -2190,7 +2189,6 @@ static int ice_vc_process_vlan_msg(struct ice_vf *vf, u8 *msg, bool add_v)
*/
if (!ice_vsi_kill_vlan(vsi, vid)) {
vf->num_vlan--;
- clear_bit(vid, vsi->active_vlans);
/* Disable VLAN pruning when removing VLAN 0 */
if (unlikely(!vid))
--
2.19.1
^ permalink raw reply related
* [net 03/14] ice: Fix dead device link issue with flow control
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem
Cc: Akeem G Abodunrin, netdev, nhorman, sassmann,
Anirudh Venkataramanan, Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Setting Rx or Tx pause parameter currently results in link loss on the
interface, requiring the platform/host to be cold power cycled. Fix it.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 96923580f2a6..648acdb4c644 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -1517,10 +1517,15 @@ ice_set_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *pause)
}
if (!test_bit(__ICE_DOWN, pf->state)) {
- /* Give it a little more time to try to come back */
+ /* Give it a little more time to try to come back. If still
+ * down, restart autoneg link or reinitialize the interface.
+ */
msleep(75);
if (!test_bit(__ICE_DOWN, pf->state))
return ice_nway_reset(netdev);
+
+ ice_down(vsi);
+ ice_up(vsi);
}
return err;
--
2.19.1
^ permalink raw reply related
* [net 01/14] ice: Set carrier state and start/stop queues in rebuild
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem; +Cc: Anirudh Venkataramanan, netdev, nhorman, sassmann, Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Set the carrier state post rebuild by querying the link status. Also
start/stop queues based on link status.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 05993451147a..6d31ffb64940 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3296,7 +3296,7 @@ static void ice_rebuild(struct ice_pf *pf)
struct device *dev = &pf->pdev->dev;
struct ice_hw *hw = &pf->hw;
enum ice_status ret;
- int err;
+ int err, i;
if (test_bit(__ICE_DOWN, pf->state))
goto clear_recovery;
@@ -3370,6 +3370,22 @@ static void ice_rebuild(struct ice_pf *pf)
}
ice_reset_all_vfs(pf, true);
+
+ for (i = 0; i < pf->num_alloc_vsi; i++) {
+ bool link_up;
+
+ if (!pf->vsi[i] || pf->vsi[i]->type != ICE_VSI_PF)
+ continue;
+ ice_get_link_status(pf->vsi[i]->port_info, &link_up);
+ if (link_up) {
+ netif_carrier_on(pf->vsi[i]->netdev);
+ netif_tx_wake_all_queues(pf->vsi[i]->netdev);
+ } else {
+ netif_carrier_off(pf->vsi[i]->netdev);
+ netif_tx_stop_all_queues(pf->vsi[i]->netdev);
+ }
+ }
+
/* if we get here, reset flow is successful */
clear_bit(__ICE_RESET_FAILED, pf->state);
return;
--
2.19.1
^ permalink raw reply related
* [net 02/14] ice: Check for reset in progress during remove
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem
Cc: Anirudh Venkataramanan, netdev, nhorman, sassmann, Dave Ertman,
Jeff Kirsher
In-Reply-To: <20181107191631.5072-1-jeffrey.t.kirsher@intel.com>
From: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
The remove path does not currently check to see if a
reset is in progress before proceeding. This can cause
a resource collision resulting in various types of errors.
Check for reset in progress and wait for a reasonable
amount of time before allowing the remove to progress.
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 2 ++
drivers/net/ethernet/intel/ice/ice_main.c | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index 4c4b5717a627..e5b37fa60884 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -76,6 +76,8 @@ extern const char ice_drv_ver[];
#define ICE_MIN_INTR_PER_VF (ICE_MIN_QS_PER_VF + 1)
#define ICE_DFLT_INTR_PER_VF (ICE_DFLT_QS_PER_VF + 1)
+#define ICE_MAX_RESET_WAIT 20
+
#define ICE_VSIQF_HKEY_ARRAY_SIZE ((VSIQF_HKEY_MAX_INDEX + 1) * 4)
#define ICE_DFLT_NETIF_M (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 6d31ffb64940..aee22f11a41a 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2182,6 +2182,12 @@ static void ice_remove(struct pci_dev *pdev)
if (!pf)
return;
+ for (i = 0; i < ICE_MAX_RESET_WAIT; i++) {
+ if (!ice_is_reset_in_progress(pf->state))
+ break;
+ msleep(100);
+ }
+
set_bit(__ICE_DOWN, pf->state);
ice_service_task_stop(pf);
--
2.19.1
^ permalink raw reply related
* [net 00/14][pull request] Intel Wired LAN Driver Updates 2018-11-07
From: Jeff Kirsher @ 2018-11-07 19:16 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains fixes to igb, i40e and ice drivers.
Anirudh fixes an issue during rebuild of the ice driver, where we need
to set the carrier state, as well as start or stop the queues all based
on the link status. Removed functions that were duplicating current
functionality in the VSI rebuild/replay framework.
Dave fixes a potential resource collision during the remove path, so add
a check to see if we are in the middle of a reset. Fixed the remove
path to ensure we call netif_napi_del() to free vectors before we set
vsi->netdev to NULL.
Akeem fixes an issue when the receive or transmit pause parameter is
set, results in link loss on the interface. Fixed the spelling of
"Enabling" in error message.
Victor fixes potential memory leak by also freeing the related VSI
contexts in the unload path.
Md Fahad fixes a flag during port VLAN insertion, which was not being
set properly.
Brett fixes a transmit timeout during stress due to the hardware tail
and software tail were incorrectly out of sync.
Miroslav Lichvar fixes the igb PHC timecounter update interval to be
sure the timecounter is updated in time.
Chinh fixes the req_speeds variable to be u16 instead of u8 so that it
can handle all the link speeds.
Jake fixes i40e to add back the missing feature flags, which was causing
IP-in-IP offloads to be reported as not supported.
The following are changes since commit 042cb56478152b31c50bea8a784fc826891eb38e:
net: phy: Allow BCM54616S PHY to setup internal TX/RX clock delay
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 100GbE
Akeem G Abodunrin (1):
ice: Fix dead device link issue with flow control
Anirudh Venkataramanan (4):
ice: Set carrier state and start/stop queues in rebuild
ice: Check for reset in progress during remove
ice: Remove duplicate addition of VLANs in replay path
ice: Fix typo in error message
Brett Creeley (2):
ice: Fix tx_timeout in PF driver
ice: Fix the bytecount sent to netdev_tx_sent_queue
Chinh T Cao (1):
ice: Change req_speeds to be u16
Dave Ertman (1):
ice: Fix napi delete calls for remove
Jacob Keller (2):
i40e: restore NETIF_F_GSO_IPXIP[46] to netdev features
i40e: enable NETIF_F_NTUPLE and NETIF_F_HW_TC at driver load
Md Fahad Iqbal Polash (1):
ice: Fix flags for port VLAN
Miroslav Lichvar (1):
igb: shorten maximum PHC timecounter update interval
Victor Raj (1):
ice: Free VSI contexts during for unload
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +-
drivers/net/ethernet/intel/ice/ice.h | 4 +-
drivers/net/ethernet/intel/ice/ice_common.c | 3 +
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 +-
.../net/ethernet/intel/ice/ice_hw_autogen.h | 2 +
drivers/net/ethernet/intel/ice/ice_lib.c | 3 +-
drivers/net/ethernet/intel/ice/ice_main.c | 86 +++++++++++--------
drivers/net/ethernet/intel/ice/ice_switch.c | 12 +++
drivers/net/ethernet/intel/ice/ice_switch.h | 2 +
drivers/net/ethernet/intel/ice/ice_txrx.c | 11 +--
drivers/net/ethernet/intel/ice/ice_txrx.h | 17 +++-
drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 4 +-
drivers/net/ethernet/intel/igb/igb_ptp.c | 12 +--
14 files changed, 113 insertions(+), 60 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: [PATCH net-next v5 9/9] ipv6: do not drop vrf udp multicast packets
From: David Ahern @ 2018-11-07 19:08 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Dewi Morgan
In-Reply-To: <20181107153610.7526-10-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> From: Dewi Morgan <morgand@vyatta.att-mail.com>
>
> For bound udp sockets in a vrf, also check the sdif to get the index
> for ingress devices enslaved to an l3mdev.
>
> Signed-off-by: Dewi Morgan <morgand@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> net/ipv6/udp.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 8/9] ipv6: handling of multicast packets received in VRF
From: David Ahern @ 2018-11-07 19:08 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Dewi Morgan
In-Reply-To: <20181107153610.7526-9-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> If the skb for multicast packets marked as enslaved to a VRF are
> received, then the secondary device index should be used to obtain
> the real device. And verify the multicast address against the
> enslaved rather than the l3mdev device.
>
> Signed-off-by: Dewi Morgan <morgand@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> net/ipv6/ip6_input.c | 35 ++++++++++++++++++++++++++++++++---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 7/9] ipv6: allow ping to link-local address in VRF
From: David Ahern @ 2018-11-07 19:07 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <20181107153610.7526-8-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> If link-local packets are marked as enslaved to a VRF, then to allow
> ping to the link-local from a vrf, the error handling for IPV6_PKTINFO
> needs to be relaxed to also allow the pkt ipi6_ifindex to be that of a
> slave device to the vrf.
>
> Note that the real device also needs to be retrieved in icmp6_iif()
> to set the ipv6 flow oif to this for icmp echo reply handling. The
> recent commit 24b711edfc34 ("net/ipv6: Fix linklocal to global address
> with VRF") takes care of this, so the sdif does not need checking here.
>
> This fix makes ping to link-local consistent with that to global
> addresses, in that this can now be done from within the same VRF that
> the address is in.
>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> net/ipv6/ipv6_sockglue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 6/9] vrf: mark skb for multicast or link-local as enslaved to VRF
From: David Ahern @ 2018-11-07 19:07 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <20181107153610.7526-7-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> The skb for packets that are multicast or to a link-local address are
> not marked as being enslaved to a VRF, if they are received on a socket
> bound to the VRF. This is needed for ND and it is preferable for the
> kernel not to have to deal with the additional use-cases if ll or mcast
> packets are handled as enslaved. However, this does not allow service
> instances listening on unbound and bound to VRF sockets to distinguish
> the VRF used, if packets are sent as multicast or to a link-local
> address. The fix is for the VRF driver to also mark these skb as being
> enslaved to the VRF.
>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> drivers/net/vrf.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 5/9] net: fix raw socket lookup device bind matching with VRFs
From: David Ahern @ 2018-11-07 19:07 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Duncan Eastoe
In-Reply-To: <20181107153610.7526-6-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> From: Duncan Eastoe <deastoe@vyatta.att-mail.com>
>
> When there exist a pair of raw sockets one unbound and one bound
> to a VRF but equal in all other respects, when a packet is received
> in the VRF context, __raw_v4_lookup() matches on both sockets.
>
> This results in the packet being delivered over both sockets,
> instead of only the raw socket bound to the VRF. The bound device
> checks in __raw_v4_lookup() are replaced with a call to
> raw_sk_bound_dev_eq() which correctly handles whether the packet
> should be delivered over the unbound socket in such cases.
>
> In __raw_v6_lookup() the match on the device binding of the socket is
> similarly updated to use raw_sk_bound_dev_eq() which matches the
> handling in __raw_v4_lookup().
>
> Importantly raw_sk_bound_dev_eq() takes the raw_l3mdev_accept sysctl
> into account.
>
> Signed-off-by: Duncan Eastoe <deastoe@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> include/net/raw.h | 13 ++++++++++++-
> net/ipv4/raw.c | 3 +--
> net/ipv6/raw.c | 5 ++---
> 3 files changed, 15 insertions(+), 6 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 4/9] net: provide a sysctl raw_l3mdev_accept for raw socket lookup with VRFs
From: David Ahern @ 2018-11-07 19:07 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <20181107153610.7526-5-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> Add a sysctl raw_l3mdev_accept to control raw socket lookup in a manner
> similar to use of tcp_l3mdev_accept for stream and of udp_l3mdev_accept
> for datagram sockets. Have this default to enabled for reasons of
> backwards compatibility. This is so as to specify the output device
> with cmsg and IP_PKTINFO, but using a socket not bound to the
> corresponding VRF. This allows e.g. older ping implementations to be
> run with specifying the device but without executing it in the VRF.
> If the option is disabled, packets received in a VRF context are only
> handled by a raw socket bound to the VRF, and correspondingly packets
> in the default VRF are only handled by a socket not bound to any VRF.
>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> Documentation/networking/ip-sysctl.txt | 12 ++++++++++++
> Documentation/networking/vrf.txt | 13 +++++++++++++
> include/net/netns/ipv4.h | 3 +++
> include/net/raw.h | 1 +
> net/ipv4/af_inet.c | 2 ++
> net/ipv4/raw.c | 28 ++++++++++++++++++++++++++--
> net/ipv4/sysctl_net_ipv4.c | 11 +++++++++++
> 7 files changed, 68 insertions(+), 2 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 3/9] net: ensure unbound datagram socket to be chosen when not in a VRF
From: David Ahern @ 2018-11-07 19:06 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <20181107153610.7526-4-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> Ensure an unbound datagram skt is chosen when not in a VRF. The check
> for a device match in compute_score() for UDP must be performed when
> there is no device match. For this, a failure is returned when there is
> no device match. This ensures that bound sockets are never selected,
> even if there is no unbound socket.
>
> Allow IPv6 packets to be sent over a datagram skt bound to a VRF. These
> packets are currently blocked, as flowi6_oif was set to that of the
> master vrf device, and the ipi6_ifindex is that of the slave device.
> Allow these packets to be sent by checking the device with ipi6_ifindex
> has the same L3 scope as that of the bound device of the skt, which is
> the master vrf device. Note that this check always succeeds if the skt
> is unbound.
>
> Even though the right datagram skt is now selected by compute_score(),
> a different skt is being returned that is bound to the wrong vrf. The
> difference between these and stream sockets is the handling of the skt
> option for SO_REUSEPORT. While the handling when adding a skt for reuse
> correctly checks that the bound device of the skt is a match, the skts
> in the hashslot are already incorrect. So for the same hash, a skt for
> the wrong vrf may be selected for the required port. The root cause is
> that the skt is immediately placed into a slot when it is created,
> but when the skt is then bound using SO_BINDTODEVICE, it remains in the
> same slot. The solution is to move the skt to the correct slot by
> forcing a rehash.
>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> include/net/udp.h | 11 +++++++++++
> net/core/sock.c | 2 ++
> net/ipv4/udp.c | 15 ++++++---------
> net/ipv6/datagram.c | 10 +++++++---
> net/ipv6/udp.c | 14 +++++---------
> 5 files changed, 31 insertions(+), 21 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 2/9] net: ensure unbound stream socket to be chosen when not in a VRF
From: David Ahern @ 2018-11-07 19:06 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <20181107153610.7526-3-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> The commit a04a480d4392 ("net: Require exact match for TCP socket
> lookups if dif is l3mdev") only ensures that the correct socket is
> selected for packets in a VRF. However, there is no guarantee that
> the unbound socket will be selected for packets when not in a VRF.
> By checking for a device match in compute_score() also for the case
> when there is no bound device and attaching a score to this, the
> unbound socket is selected. And if a failure is returned when there
> is no device match, this ensures that bound sockets are never selected,
> even if there is no unbound socket.
>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> include/net/inet_hashtables.h | 11 +++++++++++
> include/net/inet_sock.h | 8 ++++++++
> net/ipv4/inet_hashtables.c | 14 ++++++--------
> net/ipv6/inet6_hashtables.c | 14 ++++++--------
> 4 files changed, 31 insertions(+), 16 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v5 1/9] net: allow binding socket in a VRF when there's an unbound socket
From: David Ahern @ 2018-11-07 19:06 UTC (permalink / raw)
To: Mike Manning, netdev; +Cc: Robert Shearman
In-Reply-To: <20181107153610.7526-2-mmanning@vyatta.att-mail.com>
On 11/7/18 8:36 AM, Mike Manning wrote:
> From: Robert Shearman <rshearma@vyatta.att-mail.com>
>
> Change the inet socket lookup to avoid packets arriving on a device
> enslaved to an l3mdev from matching unbound sockets by removing the
> wildcard for non sk_bound_dev_if and instead relying on check against
> the secondary device index, which will be 0 when the input device is
> not enslaved to an l3mdev and so match against an unbound socket and
> not match when the input device is enslaved.
>
> Change the socket binding to take the l3mdev into account to allow an
> unbound socket to not conflict sockets bound to an l3mdev given the
> datapath isolation now guaranteed.
>
> Signed-off-by: Robert Shearman <rshearma@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
> Documentation/networking/vrf.txt | 9 +++++----
> include/net/inet6_hashtables.h | 5 ++---
> include/net/inet_hashtables.h | 13 ++++++-------
> include/net/inet_sock.h | 13 +++++++++++++
> net/ipv4/inet_connection_sock.c | 13 ++++++++++---
> net/ipv4/inet_hashtables.c | 20 +++++++++++++++-----
> 6 files changed, 51 insertions(+), 22 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] devlink: Add fw_version_check generic parameter
From: Jakub Kicinski @ 2018-11-07 19:05 UTC (permalink / raw)
To: Ido Schimmel
Cc: Ido Schimmel, netdev@vger.kernel.org, davem@davemloft.net,
Jiri Pirko, Shalom Toledo, Moshe Shemesh, dsahern@gmail.com,
andrew@lunn.ch, f.fainelli@gmail.com, mlxsw
In-Reply-To: <20181107101132.GA8943@splinter.mtl.com>
On Wed, 7 Nov 2018 12:11:32 +0200, Ido Schimmel wrote:
> On Tue, Nov 06, 2018 at 02:47:13PM -0800, Jakub Kicinski wrote:
> > On Tue, 6 Nov 2018 22:37:51 +0200, Ido Schimmel wrote:
> > > On Tue, Nov 06, 2018 at 12:19:13PM -0800, Jakub Kicinski wrote:
> > > > We have a FW loading policy for NFP, too, so it'd be good to see if we
> > > > can find a common ground.
> > >
> > > If the parameter is set, then device runs with whatever firmware version
> > > was last flashed (via ethtool, for example). Otherwise, the driver will
> > > flash a version according to its policy. In mlxsw, it is a specific
> > > version.
> > >
> > > Will that work for you?
> >
> > Our FW is always backward compatible so there is no need to downgrade.
> >
> > What we have is this more along these lines: there are two images one
> > on disk and second in the flash. The FW loading policy can decide
> > which of those should be preferred, or should the versions be compared
> > and the newer one win (default). But we don't flash the newer FW, just
> > potentially load it from disk today.
>
> Not sure I understand. You have a currently flashed firmware and another
> firmware image on disk.
Correct.
> You potentially load the firmware from the disk, but never flash it?
You can flash it if you want, but default is to load the
linux-firmware/disk one when system boots.
Flashing is useful for example if you have some super special FW that
you prefer over whatever comes from linux-firmware updates, or (most
commonly) if distributing FWs is hard in your provisioning system (ugh).
> If so, why load it?
We need to load some FW..
> > I'm not sure whether 'fw_version_check' describes the general behaviour
> > of not updating the FW in flash. The policy of updating the FW in the
> > flash if the one on disk is newer seems to be something we could adopt
> > as well. Can we come up with a more general parameter which could
> > select FW loading policy that'd for both cases?
> >
> > Would values like these make any sense to you?
> > - driver preferred (your default behaviour, we don't support since
> > driver doesn't care);
> > - newest (our default, device compares images and picks newer);
> > - always disk (always run with what's on the disk, regardless of
> > versions);
> > - always flash (always run with what's already in flash, don't look at
> > disk);
> >
> > Separate bool parameter 'fw_flash_auto_update' would decide whether the
> > selected FW should be flashed to the device (always true for you AFAIU).
> >
> > Let me know if that makes sense, it would be nice if we could converge
> > on a common solution, or at least name our parameters sufficiently
> > distinctly to avoid confusion :)
>
> I think that the above scheme is a bit too complicated and I'm not sure
> this is warranted. I'll try to better explain the motivation for this
> parameter and where we are coming from.
Certainly, let me know if what I wrote above helps to understand the
motivation.
> We want to keep things as simple as possible. This means we don't want
> users to fiddle with devlink parameter unless they have to. Things
> should just work.
100% agree, you can choose the default for the parameter to be whatever
you want, nobody will have to touch it in normal operation.
I'm just proposing widening the values of the parameter so it works for
others (given you propose it as generic).
> This parameter should only be used in exceptional cases.
>
> For example, when user reports a problem with current firmware version
> enforced by the driver. Assuming we have a new firmware version with a
> fix, we would like the user to try it and confirm bug was fixed.
> Ideally, the user would do something like this:
>
> 1. Flash new firmware via ethtool
> 2. Perform a reset via devlink to have changes take effect
>
> Problem is that after the reset the driver's init sequence will run and
> overwrite the new firmware version with the one specified in its source
> as a compatible version. The driver needs to enforce a specific version
> because newer versions are not necessarily backward compatible.
>
> Therefore, we added this new parameter that gives the user the ability
> to explicitly run with a different version than what was specified as
> compatible. New sequence is therefore:
>
> 1. Flash new firmware via ethtool
> 2. Toggle devlink parameter
> 3. Perform a reset via devlink to have changes take effect
>
> Firmware loading policy is basically always go with what the driver is
> enforcing (it knows best), unless user specified he/she knows better.
Thanks, got it.
> I think this is both generic and simple, but I possibly didn't
> understand the full scope of your use cases.
I agree, it is simple, but the semantics of the parameter you're adding
unnecessarily involve firmware flashing, which is mlxsw quirk. My
impression (mostly from my WiFi driver days) is that the FW is either in
flash or in /lib/firmware, but rarely /lib/firmware autofeeds the flash.
The commit message says "Many drivers checking the device's firmware
version during the initialization flow and flashing a compatible
version if the current version is not." Do Ethernet drivers do that
or some other drivers?
To reiterate I think the definition of the flag unnecessarily involves
flashing. It may make sense to mlxsw users, but I'd postulate it won't
to almost everyone else :)
Therefore AFAICS we could make one of two improvements:
- make this a full-fledged flash update policy with clear operational
semantics which others can reuse; or
- remove the flashing part and leave it unmentioned - definition of the
parameter becomes in a nutshell "ignore all FW version
incompatibilities"; the limitation of mlxsw having to flash a FW
image to load it is then an implementation detail.
^ permalink raw reply
* RE: [PATCH] e1000e: Change watchdog task to be delayed work
From: Brown, Aaron F @ 2018-11-08 4:16 UTC (permalink / raw)
To: Robert Eshleman
Cc: Kirsher, Jeffrey T, David S. Miller,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1541290645-25033-1-git-send-email-bobbyeshleman@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Robert Eshleman
> Sent: Saturday, November 3, 2018 5:17 PM
> Cc: Robert Eshleman <bobbyeshleman@gmail.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; David S. Miller <davem@davemloft.net>;
> intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] e1000e: Change watchdog task to be delayed work
>
> This completes a pending TODO to use queue_delayed_work() instead of
> schedule_work().
>
> Signed-off-by: Robert Eshleman <bobbyeshleman@gmail.com>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
This patch is causing my test systems to either completely freeze or panic with a trace and lock up when an e1000e interface is brought up (with our without an address.) I was able to capture the following trace via a serial console:
u1462:[ttyS1]/root> modprobe e1000e
u1462:[ttyS1]/root> ifconfig eth1 u1462-1
u1462:[ttyS1]/ro[ 413.151204] WARNING: CPU: 3 PID: 0 at kernel/workqueue.c:1511 __queue_delayed_work+0x66/0x90
ot> [ 413.267388] Modules linked in: e1000e xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod coretemp kvm_intel kvm irqbypass iTCO_wdt iTCO_vendor_support i2c_i801 gpio_ich i5000_edac pcspkr lpc_ich sg i5k_amb acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sr_mod sd_mod cdrom ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix drm libata e1000 i2c_core serio_raw
[ 413.990294] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.20.0-rc1_next-queue_regress-00129-g712ce5c #14
[ 414.101676] Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008
[ 414.179780] RIP: 0010:__queue_delayed_work+0x66/0x90
[ 414.239164] Code: f5 00 89 42 50 48 01 f1 3d 00 20 00 00 48 89 4a 30 75 27 e9 9c 3f 06 00 89 c7 e9 25 fa ff ff 0f 0b 0f 1f 00 eb cc 0f 0b eb bb <0f> 0b 0f 1f 84 00 00 00 00 00 eb a8 0f 0b eb 9a 89 c6 0f 1f 84 00
[ 414.463907] RSP: 0018:ffff9a1dbdac3eb0 EFLAGS: 00010003
[ 414.526412] RAX: 0000000000002000 RBX: 0000000000000206 RCX: 0000000000000001
[ 414.611796] RDX: ffff9a1db3d10918 RSI: ffff9a1db4330000 RDI: ffff9a1db3d10938
[ 414.697180] RBP: ffff9a1db3d10880 R08: ffff9a1dbdac3ef8 R09: ffff9a1dbdac3ef8
[ 414.782563] R10: 0000000000000004 R11: 0000000000000005 R12: 0000000000000100
[ 414.867947] R13: ffffffffc0ab8660 R14: 0000000000000000 R15: 0000000000000000
[ 414.953332] FS: 0000000000000000(0000) GS:ffff9a1dbdac0000(0000) knlGS:0000000000000000
[ 415.050156] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 415.118899] CR2: 00007fbf928ea000 CR3: 000000001a00a000 CR4: 00000000000006e0
[ 415.204284] Call Trace:
[ 415.233510] <IRQ>
[ 415.257532] queue_delayed_work_on+0x24/0x40
[ 415.308599] call_timer_fn+0x2b/0x140
[ 415.352381] run_timer_softirq+0x1df/0x430
[ 415.401366] ? enqueue_hrtimer+0x38/0x90
[ 415.448267] ? __hrtimer_run_queues+0x129/0x260
[ 415.502453] __do_softirq+0xd0/0x29d
[ 415.545199] irq_exit+0xdb/0xf0
[ 415.582740] smp_apic_timer_interrupt+0x68/0x130
[ 415.637964] apic_timer_interrupt+0xf/0x20
[ 415.686949] </IRQ>
[ 415.712012] RIP: 0010:mwait_idle+0x72/0x1c0
[ 415.762037] Code: 01 00 0f ae 38 0f ae f0 31 d2 65 48 8b 04 25 80 5c 01 00 48 89 d1 0f 01 c8 48 8b 00 a8 08 0f 85 23 01 00 00 31 c0 fb 0f 01 c9 <65> 8b 2d 67 c2 c6 73 66 66 66 66 90 65 48 8b 04 25 80 5c 01 00 f0
[ 415.986780] RSP: 0018:ffffae7e0039beb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[ 416.077364] RAX: 0000000000000000 RBX: ffff9a1d4f4bd700 RCX: 0000000000000000
[ 416.162748] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000005e259b5f9b
[ 416.248132] RBP: 0000000000000003 R08: 0000000000000002 R09: fffffff33a143210
[ 416.333516] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 416.418901] R13: 0000000000000000 R14: ffff9a1d4f4bd700 R15: ffff9a1d4f4bd700
[ 416.504286] do_idle+0x19a/0x290
[ 416.542868] cpu_startup_entry+0x19/0x20
[ 416.589774] start_secondary+0x18c/0x1e0
[ 416.636676] secondary_startup_64+0xa4/0xb0
[ 416.686702] ---[ end trace 3c61674d52e0a694 ]---
[ 416.741927] WARNING: CPU: 3 PID: 0 at kernel/workqueue.c:1512 __queue_delayed_work+0x62/0x90
[ 416.842907] Modules linked in: e1000e xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod coretemp kvm_intel kvm irqbypass iTCO_wdt iTCO_vendor_support i2c_i801 gpio_ich i5000_edac pcspkr lpc_ich sg i5k_amb acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sr_mod sd_mod cdrom ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix drm libata e1000 i2c_core serio_raw
[ 417.561653] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G W 4.20.0-rc1_next-queue_regress-00129-g712ce5c #14
[ 417.689675] Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008
[ 417.767780] RIP: 0010:__queue_delayed_work+0x62/0x90
[ 417.827165] Code: 8b 35 22 b1 f5 00 89 42 50 48 01 f1 3d 00 20 00 00 48 89 4a 30 75 27 e9 9c 3f 06 00 89 c7 e9 25 fa ff ff 0f 0b 0f 1f 00 eb cc <0f> 0b eb bb 0f 0b 0f 1f 84 00 00 00 00 00 eb a8 0f 0b eb 9a 89 c6
[ 418.051907] RSP: 0018:ffff9a1dbdac3eb0 EFLAGS: 00010002
[ 418.114412] RAX: 0000000000002000 RBX: 0000000000000206 RCX: 0000000000000001
[ 418.199796] RDX: ffff9a1db3d10918 RSI: ffff9a1db4330000 RDI: ffff9a1db3d10938
[ 418.285181] RBP: ffff9a1db3d10880 R08: ffff9a1dbdac3ef8 R09: ffff9a1dbdac3ef8
[ 418.370563] R10: 0000000000000004 R11: 0000000000000005 R12: 0000000000000100
[ 418.455948] R13: ffffffffc0ab8660 R14: 0000000000000000 R15: 0000000000000000
[ 418.541333] FS: 0000000000000000(0000) GS:ffff9a1dbdac0000(0000) knlGS:0000000000000000
[ 418.638156] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 418.706901] CR2: 00007fbf928ea000 CR3: 000000001a00a000 CR4: 00000000000006e0
[ 418.792283] Call Trace:
[ 418.821507] <IRQ>
[ 418.845532] queue_delayed_work_on+0x24/0x40
[ 418.896598] call_timer_fn+0x2b/0x140
[ 418.940380] run_timer_softirq+0x1df/0x430
[ 418.989366] ? enqueue_hrtimer+0x38/0x90
[ 419.036267] ? __hrtimer_run_queues+0x129/0x260
[ 419.090453] __do_softirq+0xd0/0x29d
[ 419.133197] irq_exit+0xdb/0xf0
[ 419.170742] smp_apic_timer_interrupt+0x68/0x130
[ 419.225964] apic_timer_interrupt+0xf/0x20
[ 419.274947] </IRQ>
[ 419.300013] RIP: 0010:mwait_idle+0x72/0x1c0
[ 419.350037] Code: 01 00 0f ae 38 0f ae f0 31 d2 65 48 8b 04 25 80 5c 01 00 48 89 d1 0f 01 c8 48 8b 00 a8 08 0f 85 23 01 00 00 31 c0 fb 0f 01 c9 <65> 8b 2d 67 c2 c6 73 66 66 66 66 90 65 48 8b 04 25 80 5c 01 00 f0
[ 419.574779] RSP: 0018:ffffae7e0039beb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[ 419.665363] RAX: 0000000000000000 RBX: ffff9a1d4f4bd700 RCX: 0000000000000000
[ 419.750748] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000005e259b5f9b
[ 419.836132] RBP: 0000000000000003 R08: 0000000000000002 R09: fffffff33a143210
[ 419.921516] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 420.006900] R13: 0000000000000000 R14: ffff9a1d4f4bd700 R15: ffff9a1d4f4bd700
[ 420.092285] do_idle+0x19a/0x290
[ 420.130868] cpu_startup_entry+0x19/0x20
[ 420.177773] start_secondary+0x18c/0x1e0
[ 420.224677] secondary_startup_64+0xa4/0xb0
[ 420.274700] ---[ end trace 3c61674d52e0a695 ]---
[ 420.329926] ------------[ cut here ]------------
[ 420.385147] kernel BUG at kernel/time/timer.c:1137!
[ 420.443497] invalid opcode: 0000 [#1] SMP PTI
[ 420.495596] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G W 4.20.0-rc1_next-queue_regress-00129-g712ce5c #14
[ 420.623620] Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008
[ 420.701726] RIP: 0010:add_timer+0x1c9/0x1f0
[ 420.751748] Code: 48 89 de ff d0 48 8b 45 00 48 85 c0 75 e4 e9 43 ff ff ff 49 01 d5 44 8b 73 20 e9 e1 fe ff ff 49 89 ed 4d 89 ef e9 27 ff ff ff <0f> 0b 0f 0b e8 ce 07 f8 ff 4c 89 ef e8 b5 08 00 00 e9 0d ff ff ff
[ 420.976492] RSP: 0018:ffff9a1dbdac3e70 EFLAGS: 00010002
[ 421.038997] RAX: 0000000000000000 RBX: ffff9a1db3d10938 RCX: 000000010001a1a7
[ 421.124381] RDX: ffff9a1db3d10918 RSI: 000000010001a1a6 RDI: ffff9a1db3d10938
[ 421.209765] RBP: ffff9a1db3d10880 R08: ffff9a1db3d10920 R09: ffff9a1db3d10920
[ 421.295149] R10: 0000000000000004 R11: 0000000000000005 R12: 0000000000000100
[ 421.380532] R13: ffffffffc0ab8660 R14: 0000000000000000 R15: 0000000000000000
[ 421.465918] FS: 0000000000000000(0000) GS:ffff9a1dbdac0000(0000) knlGS:0000000000000000
[ 421.562741] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 421.631486] CR2: 00007fbf928ea000 CR3: 000000001a00a000 CR4: 00000000000006e0
[ 421.716869] Call Trace:
[ 421.746091] <IRQ>
[ 421.770129] ? e1000e_downshift_workaround+0x20/0x20 [e1000e]
[ 421.838862] queue_delayed_work_on+0x24/0x40
[ 421.889925] call_timer_fn+0x2b/0x140
[ 421.933710] run_timer_softirq+0x1df/0x430
[ 421.982692] ? enqueue_hrtimer+0x38/0x90
[ 422.029597] ? __hrtimer_run_queues+0x129/0x260
[ 422.083781] __do_softirq+0xd0/0x29d
[ 422.126524] irq_exit+0xdb/0xf0
[ 422.164068] smp_apic_timer_interrupt+0x68/0x130
[ 422.219293] apic_timer_interrupt+0xf/0x20
[ 422.268277] </IRQ>
[ 422.293341] RIP: 0010:mwait_idle+0x72/0x1c0
[ 422.343364] Code: 01 00 0f ae 38 0f ae f0 31 d2 65 48 8b 04 25 80 5c 01 00 48 89 d1 0f 01 c8 48 8b 00 a8 08 0f 85 23 01 00 00 31 c0 fb 0f 01 c9 <65> 8b 2d 67 c2 c6 73 66 66 66 66 90 65 48 8b 04 25 80 5c 01 00 f0
[ 422.568109] RSP: 0018:ffffae7e0039beb8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[ 422.658693] RAX: 0000000000000000 RBX: ffff9a1d4f4bd700 RCX: 0000000000000000
[ 422.744076] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000005e259b5f9b
[ 422.829460] RBP: 0000000000000003 R08: 0000000000000002 R09: fffffff33a143210
[ 422.914843] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 423.000229] R13: 0000000000000000 R14: ffff9a1d4f4bd700 R15: ffff9a1d4f4bd700
[ 423.085615] do_idle+0x19a/0x290
[ 423.124197] cpu_startup_entry+0x19/0x20
[ 423.171101] start_secondary+0x18c/0x1e0
[ 423.218006] secondary_startup_64+0xa4/0xb0
[ 423.268028] Modules linked in: e1000e xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log dm_mod coretemp kvm_intel kvm irqbypass iTCO_wdt iTCO_vendor_support i2c_i801 gpio_ich i5000_edac pcspkr lpc_ich sg i5k_amb acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sr_mod sd_mod cdrom ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix drm libata e1000 i2c_core serio_raw
[ 423.986779] ---[ end trace 3c61674d52e0a696 ]---
[ 424.041999] RIP: 0010:add_timer+0x1c9/0x1f0
[ 424.092021] Code: 48 89 de ff d0 48 8b 45 00 48 85 c0 75 e4 e9 43 ff ff ff 49 01 d5 44 8b 73 20 e9 e1 fe ff ff 49 89 ed 4d 89 ef e9 27 ff ff ff <0f> 0b 0f 0b e8 ce 07 f8 ff 4c 89 ef e8 b5 08 00 00 e9 0d ff ff ff
[ 424.316765] RSP: 0018:ffff9a1dbdac3e70 EFLAGS: 00010002
[ 424.379268] RAX: 0000000000000000 RBX: ffff9a1db3d10938 RCX: 000000010001a1a7
[ 424.464652] RDX: ffff9a1db3d10918 RSI: 000000010001a1a6 RDI: ffff9a1db3d10938
[ 424.550037] RBP: ffff9a1db3d10880 R08: ffff9a1db3d10920 R09: ffff9a1db3d10920
[ 424.635420] R10: 0000000000000004 R11: 0000000000000005 R12: 0000000000000100
[ 424.720804] R13: ffffffffc0ab8660 R14: 0000000000000000 R15: 0000000000000000
[ 424.806190] FS: 0000000000000000(0000) GS:ffff9a1dbdac0000(0000) knlGS:0000000000000000
[ 424.903012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 424.971757] CR2: 00007fbf928ea000 CR3: 000000001a00a000 CR4: 00000000000006e0
[ 425.057140] Kernel panic - not syncing: Fatal exception in interrupt
[ 425.133170] Kernel Offset: 0xac00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 425.261191] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
^ permalink raw reply
* [PATCH net-next 3/3] nfp: flower: include geneve as supported offload tunnel type
From: John Hurley @ 2018-11-07 18:32 UTC (permalink / raw)
To: netdev, davem, oss-drivers, jakub.kicinski; +Cc: John Hurley
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
Offload of geneve decap rules is supported in NFP. Include geneve in the
check for supported types.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
index 8e5bec0..170f314 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
@@ -190,6 +190,8 @@ static bool nfp_tun_is_netdev_to_offload(struct net_device *netdev)
return true;
if (netif_is_vxlan(netdev))
return true;
+ if (netif_is_geneve(netdev))
+ return true;
return false;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/3] nfp: flower: use geneve and vxlan helpers
From: John Hurley @ 2018-11-07 18:32 UTC (permalink / raw)
To: netdev, davem, oss-drivers, jakub.kicinski; +Cc: John Hurley
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
Make use of the recently added VXLAN and geneve helper functions to
determine the type of the netdev from its rtnl_link_ops.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/action.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/action.c b/drivers/net/ethernet/netronome/nfp/flower/action.c
index 244dc26..2f67cd55 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@ -11,6 +11,7 @@
#include <net/tc_act/tc_pedit.h>
#include <net/tc_act/tc_vlan.h>
#include <net/tc_act/tc_tunnel_key.h>
+#include <net/vxlan.h>
#include "cmsg.h"
#include "main.h"
@@ -94,13 +95,10 @@ nfp_fl_pre_lag(struct nfp_app *app, const struct tc_action *action,
static bool nfp_fl_netdev_is_tunnel_type(struct net_device *out_dev,
enum nfp_flower_tun_type tun_type)
{
- if (!out_dev->rtnl_link_ops)
- return false;
-
- if (!strcmp(out_dev->rtnl_link_ops->kind, "vxlan"))
+ if (netif_is_vxlan(out_dev))
return tun_type == NFP_FL_TUNNEL_VXLAN;
- if (!strcmp(out_dev->rtnl_link_ops->kind, "geneve"))
+ if (netif_is_geneve(out_dev))
return tun_type == NFP_FL_TUNNEL_GENEVE;
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/3] net: add netif_is_geneve()
From: John Hurley @ 2018-11-07 18:32 UTC (permalink / raw)
To: netdev, davem, oss-drivers, jakub.kicinski; +Cc: John Hurley
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
Add a helper function to determine if the type of a netdev is geneve based
on its rtnl_link_ops. This allows drivers that may wish to offload tunnels
to check the underlying type of the device.
A recent patch added a similar helper to vxlan.h
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/net/geneve.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/net/geneve.h b/include/net/geneve.h
index a7600ed..fc6a7e0 100644
--- a/include/net/geneve.h
+++ b/include/net/geneve.h
@@ -60,6 +60,12 @@ struct genevehdr {
struct geneve_opt options[];
};
+static inline bool netif_is_geneve(const struct net_device *dev)
+{
+ return dev->rtnl_link_ops &&
+ !strcmp(dev->rtnl_link_ops->kind, "geneve");
+}
+
#ifdef CONFIG_INET
struct net_device *geneve_dev_create_fb(struct net *net, const char *name,
u8 name_assign_type, u16 dst_port);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/3] nfp: add and use tunnel netdev helpers
From: John Hurley @ 2018-11-07 18:32 UTC (permalink / raw)
To: netdev, davem, oss-drivers, jakub.kicinski; +Cc: John Hurley
A recent patch introduced the function netif_is_vxlan() to verify the
tunnel type of a given netdev as vxlan.
Add a similar function to detect geneve netdevs and make use of this
function in the NFP driver. Also make use of the vxlan helper where
applicable.
John Hurley (3):
net: add netif_is_geneve()
nfp: flower: use geneve and vxlan helpers
nfp: flower: include geneve as supported offload tunnel type
drivers/net/ethernet/netronome/nfp/flower/action.c | 8 +++-----
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 2 ++
include/net/geneve.h | 6 ++++++
3 files changed, 11 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 2/2] net/mlx5: Fix offsets of ifc reserved fields
From: Gal Pressman @ 2018-11-07 18:31 UTC (permalink / raw)
To: Saeed Mahameed, David Miller; +Cc: netdev, Gal Pressman
In-Reply-To: <20181107183137.16774-1-pressmangal@gmail.com>
Fix wrong offsets of reserved fields in ifc file.
Issues found using pahole.
Signed-off-by: Gal Pressman <pressmangal@gmail.com>
---
include/linux/mlx5/mlx5_ifc.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index dbff9ff28f2c..79b77fc62271 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -349,7 +349,7 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
u8 reformat_l3_tunnel_to_l2[0x1];
u8 reformat_l2_to_l3_tunnel[0x1];
u8 reformat_and_modify_action[0x1];
- u8 reserved_at_14[0xb];
+ u8 reserved_at_15[0xb];
u8 reserved_at_20[0x2];
u8 log_max_ft_size[0x6];
u8 log_max_modify_header_context[0x8];
@@ -586,7 +586,7 @@ struct mlx5_ifc_flow_table_eswitch_cap_bits {
u8 fdb_multi_path_to_table[0x1];
u8 reserved_at_1d[0x1];
u8 multi_fdb_encap[0x1];
- u8 reserved_at_1e[0x1e1];
+ u8 reserved_at_1f[0x1e1];
struct mlx5_ifc_flow_table_prop_layout_bits flow_table_properties_nic_esw_fdb;
@@ -829,7 +829,7 @@ struct mlx5_ifc_vector_calc_cap_bits {
struct mlx5_ifc_calc_op calc2;
struct mlx5_ifc_calc_op calc3;
- u8 reserved_at_e0[0x720];
+ u8 reserved_at_c0[0x720];
};
enum {
@@ -5566,7 +5566,7 @@ struct mlx5_ifc_modify_nic_vport_context_out_bits {
struct mlx5_ifc_modify_nic_vport_field_select_bits {
u8 reserved_at_0[0x12];
u8 affiliation[0x1];
- u8 reserved_at_e[0x1];
+ u8 reserved_at_13[0x1];
u8 disable_uc_local_lb[0x1];
u8 disable_mc_local_lb[0x1];
u8 node_guid[0x1];
@@ -9024,7 +9024,7 @@ struct mlx5_ifc_dcbx_param_bits {
u8 dcbx_cee_cap[0x1];
u8 dcbx_ieee_cap[0x1];
u8 dcbx_standby_cap[0x1];
- u8 reserved_at_0[0x5];
+ u8 reserved_at_3[0x5];
u8 port_number[0x8];
u8 reserved_at_10[0xa];
u8 max_application_table_size[6];
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 1/2] net/mlx5e: Cleanup unused defines
From: Gal Pressman @ 2018-11-07 18:31 UTC (permalink / raw)
To: Saeed Mahameed, David Miller; +Cc: netdev, Gal Pressman
Remove couple of defines that are no longer used.
Signed-off-by: Gal Pressman <pressmangal@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index d7fbd5b6ac95..c49c87615686 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -147,9 +147,6 @@ struct page_pool;
MLX5_UMR_MTT_ALIGNMENT))
#define MLX5E_UMR_WQEBBS \
(DIV_ROUND_UP(MLX5E_UMR_WQE_INLINE_SZ, MLX5_SEND_WQE_BB))
-#define MLX5E_ICOSQ_MAX_WQEBBS MLX5E_UMR_WQEBBS
-
-#define MLX5E_NUM_MAIN_GROUPS 9
#define MLX5E_MSG_LEVEL NETIF_MSG_LINK
--
2.14.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox