fm10k: conditionally compile DCB and DebugFS support
Subsystems (2)
PATCH v5 1/17 fm10k: conditionally compile DCB and DebugFS support
Rather than wrapping fm10k_dcbnl.c and fm10k_debugfs.c support with
#ifdef blocks, just conditionally include the .o files in the Makefile.
Also, since we're modifying it, update the copyright year on the Makefile.
--- drivers/net/ethernet/intel/fm10k/Makefile | 20 +++++++++++++++----- drivers/net/ethernet/intel/fm10k/fm10k.h | 4 ++++ drivers/net/ethernet/intel/fm10k/fm10k_dcbnl.c | 4 ---- drivers/net/ethernet/intel/fm10k/fm10k_debugfs.c | 4 ---- 4 files changed, 19 insertions(+), 13 deletions(-)
drivers/net/ethernet/intel/fm10k/Makefile +15 -5
@@ -1,7 +1,7 @@ ################################################################################ # # Intel Ethernet Switch Host Interface Driver -# Copyright(c) 2013 - 2014 Intel Corporation. +# Copyright(c) 2013 - 2015 Intel Corporation. # # This program is free software; you can redistribute it and/or modify it # under the terms and conditions of the GNU General Public License,
@@ -27,7 +27,17 @@ obj-$(CONFIG_FM10K) += fm10k.o -fm10k-objs := fm10k_main.o fm10k_common.o fm10k_pci.o \ - fm10k_netdev.o fm10k_ethtool.o fm10k_pf.o fm10k_vf.o \ - fm10k_mbx.o fm10k_iov.o fm10k_tlv.o \ - fm10k_debugfs.o fm10k_ptp.o fm10k_dcbnl.o +fm10k-y := fm10k_main.o \ + fm10k_common.o \ + fm10k_pci.o \ + fm10k_ptp.o \ + fm10k_netdev.o \ + fm10k_ethtool.o \ + fm10k_pf.o \ + fm10k_vf.o \ + fm10k_mbx.o \ + fm10k_iov.o \ + fm10k_tlv.o + +fm10k-$(CONFIG_DEBUG_FS) += fm10k_debugfs.o +fm10k-$(CONFIG_DCB) += fm10k_dcbnl.o
drivers/net/ethernet/intel/fm10k/fm10k.h +4 -0
@@ -551,5 +551,9 @@ int fm10k_get_ts_config(struct net_device *netdev, struct ifreq *ifr);int fm10k_set_ts_config (struct net_device *netdev,struct ifreq *ifr);/* DCB */ +#ifdef CONFIG_DCB void fm10k_dcbnl_set_ops (struct net_device *dev); +#else +static inline void fm10k_dcbnl_set_ops (void ) {} +#endif #endif /* _FM10K_H_ */
drivers/net/ethernet/intel/fm10k/fm10k_dcbnl.c +0 -4
@@ -20,7 +20,6 @@#include "fm10k.h" -#ifdef CONFIG_DCB /** * fm10k_dcbnl_ieee_getets - get the ETS configuration for the device * @dev: netdev interface for the device
@@ -155,7 +154,6 @@ static const struct dcbnl_rtnl_ops fm10k_dcbnl_ops = { .setdcbx = fm10k_dcbnl_setdcbx, }; -#endif /* CONFIG_DCB */ /** * fm10k_dcbnl_set_ops - Configures dcbnl ops pointer for netdev * @dev: netdev interface for the device
@@ -164,11 +162,9 @@ static const struct dcbnl_rtnl_ops fm10k_dcbnl_ops = {**/ void fm10k_dcbnl_set_ops (struct net_device *dev) { -#ifdef CONFIG_DCB struct fm10k_intfc *interface =netdev_priv (dev);struct fm10k_hw *hw = &interface->hw;if (hw->mac.type == fm10k_mac_pf) dev->dcbnl_ops = &fm10k_dcbnl_ops; -#endif /* CONFIG_DCB */ }
drivers/net/ethernet/intel/fm10k/fm10k_debugfs.c +0 -4
@@ -18,8 +18,6 @@* Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 */ -#ifdef CONFIG_DEBUG_FS -#include "fm10k.h" #include <linux/debugfs.h>
@@ -258,5 +256,3 @@ void fm10k_dbg_exit(void)debugfs_remove_recursive (dbg_root); dbg_root =NULL ; } - -#endif /* CONFIG_DEBUG_FS */
Signature · 1 line
2.6.1.264.gbab76a9
PATCH v5 2/17 fm10k: set netdev features in one location
Don't change netdev hw_features later in fm10k_probe, instead set all values inside fm10k_alloc_netdev. To do so, we need to know the MAC type (whether it is PF or VF) in order to determine what to do. This helps ensure that all logic regarding features is co-located.
--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 +- drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 31 +++++++++++++++---------- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 9 +------ 3 files changed, 21 insertions(+), 21 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k.h +1 -1
@@ -484,7 +484,7 @@ void fm10k_netpoll(struct net_device *netdev);#endif /* Netdev */ -struct net_device *fm10k_alloc_netdev (void ); +struct net_device *fm10k_alloc_netdev (const struct fm10k_info *info);int fm10k_setup_rx_resources (struct fm10k_ring *);int fm10k_setup_tx_resources (struct fm10k_ring *);void fm10k_free_rx_resources (struct fm10k_ring *);
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +19 -12
@@ -1391,8 +1391,9 @@ static const struct net_device_ops fm10k_netdev_ops = {#define DEFAULT_DEBUG_LEVEL_SHIFT 3 -struct net_device *fm10k_alloc_netdev (void ) +struct net_device *fm10k_alloc_netdev (const struct fm10k_info *info) { +netdev_features_t hw_features;struct fm10k_intfc *interface;struct net_device *dev;
@@ -1415,27 +1416,31 @@ struct net_device *fm10k_alloc_netdev(void)NETIF_F_TSO |NETIF_F_TSO6 |NETIF_F_TSO_ECN | -NETIF_F_GSO_UDP_TUNNEL |NETIF_F_RXHASH |NETIF_F_RXCSUM ; +/* Only the PF can support VXLAN and NVGRE tunnel offloads */ +if (info->mac == fm10k_mac_pf) { + dev->hw_enc_features =NETIF_F_IP_CSUM | +NETIF_F_TSO | +NETIF_F_TSO6 | +NETIF_F_TSO_ECN | +NETIF_F_GSO_UDP_TUNNEL | +NETIF_F_IPV6_CSUM | +NETIF_F_SG ; + + dev->features |=NETIF_F_GSO_UDP_TUNNEL ; + } +/* all features defined to this point should be changeable */ - dev->hw_features |= dev->features; + hw_features = dev->features;/* allow user to enable L2 forwarding acceleration */ - dev->hw_features |=NETIF_F_HW_L2FW_DOFFLOAD ; + hw_features |=NETIF_F_HW_L2FW_DOFFLOAD ;/* configure VLAN features */ dev->vlan_features |= dev->features; -/* configure tunnel offloads */ - dev->hw_enc_features |=NETIF_F_IP_CSUM | -NETIF_F_TSO | -NETIF_F_TSO6 | -NETIF_F_TSO_ECN | -NETIF_F_GSO_UDP_TUNNEL | -NETIF_F_IPV6_CSUM ; -/* we want to leave these both on as we cannot disable VLAN tag * insertion or stripping on the hardware since it is contained * in the FTAG and not in the frame itself.
@@ -1446,5 +1451,7 @@ struct net_device *fm10k_alloc_netdev(void) dev->priv_flags |=IFF_UNICAST_FLT ; + dev->hw_features |= hw_features; +return dev; }
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +1 -8
@@ -1722,13 +1722,6 @@ static int fm10k_sw_init(struct fm10k_intfc *interface, pci_resource_len(pdev, 4)); hw->sw_addr = interface->sw_addr; -/* Only the PF can support VXLAN and NVGRE offloads */ -if (hw->mac.type != fm10k_mac_pf) { - netdev->hw_enc_features =0 ; - netdev->features &= ~NETIF_F_GSO_UDP_TUNNEL ; - netdev->hw_features &= ~NETIF_F_GSO_UDP_TUNNEL ; - } -/* initialize DCBNL interface */ fm10k_dcbnl_set_ops (netdev);
@@ -1894,7 +1887,7 @@ static int fm10k_probe(struct pci_dev *pdev,pci_set_master (pdev);pci_save_state (pdev); - netdev =fm10k_alloc_netdev (); + netdev =fm10k_alloc_netdev (fm10k_info_tbl[ent->driver_data]);if (!netdev) { err = -ENOMEM ; goto err_alloc_netdev;
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 2/17 fm10k: set netdev features in one location
Quoted 14 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 02/17] fm10k: set netdev features in one locationDon't change netdev
hw_featureslater infm10k_probe, instead set all values insidefm10k_alloc_netdev. To do so, we need to know the MAC type
(whether it is PF or VF) in order to determine what to do. This helps ensure that all logic regarding features is co-located.
Quoted 7 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 +- drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 31 +++++++++++++++---------- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 9 +------ 3 files changed, 21 insertions(+), 21 deletions(-)
Singh
PATCH v5 2/17 fm10k: set netdev features in one location
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 02/17] fm10k: set netdev features in one location
Don't change netdev hw_features later in fm10k_probe, instead set all values inside fm10k_alloc_netdev. To do so, we need to know the MAC type (whether it is PF or VF) in order to determine what to do. This helps ensure that all logic regarding features is co-located.
---
PATCH v5 3/17 fm10k: reset max_queues on init_hw_vf failure
In reply to Jacob KellerVF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at init_hw_vf time. However, the code flow did not reset hw->mac.max_queues to 0. In some cases, such as during reinit flows, we call init_hw_vf without clearing the previous value of hw->mac.max_queues. Due to this, when init_hw_vf errors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing the hw->mac.max_queues on exit due to errors.
--- drivers/net/ethernet/intel/fm10k/fm10k_vf.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_vf.c +10 -3
@@ -105,8 +105,10 @@ static s32 fm10k_init_hw_vf(struct fm10k_hw *hw)/* verify we have at least 1 queue */ if (!~fm10k_read_reg (hw,FM10K_TXQCTL (0 )) || - !~fm10k_read_reg (hw,FM10K_RXQCTL (0 ))) -return FM10K_ERR_NO_RESOURCES ; + !~fm10k_read_reg (hw,FM10K_RXQCTL (0 ))) { + err =FM10K_ERR_NO_RESOURCES ; + goto reset_max_queues; + }/* determine how many queues we have */ for (i =1 ; tqdloc0 && (i <FM10K_MAX_QUEUES_POOL ); i++) {
@@ -124,7 +126,7 @@ static s32 fm10k_init_hw_vf(struct fm10k_hw *hw)/* shut down queues we own and reset DMA configuration */ err =fm10k_disable_queues_generic (hw, i);if (err) -return err; + goto reset_max_queues;/* record maximum queue count */ hw->mac.max_queues = i;
@@ -134,6 +136,11 @@ static s32 fm10k_init_hw_vf(struct fm10k_hw *hw) FM10K_TXQCTL_VID_MASK) >> FM10K_TXQCTL_VID_SHIFT;return 0 ; + +reset_max_queues: + hw->mac.max_queues =0 ; + +return err; }/* This structure defines the attibutes to be parsed below */
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 3/17 fm10k: reset max_queues on init_hw_vf failure
Quoted 21 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 03/17] fm10k: resetmax_queuesoninit_hw_vffailureVF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at
init_hw_vftime. However, the code flow did not reset hw-Quoted 1 line
mac.max_queues
to 0. In some cases, such as during reinit flows, we call
init_hw_vfwithout clearing the previous value ofhw->mac.max_queues. Due to this, wheninit_hw_vferrors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing thehw->mac.max_queueson exit due to errors.
Quoted 4 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_vf.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
Singh
PATCH v5 3/17 fm10k: reset max_queues on init_hw_vf failure
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 03/17] fm10k: reset max_queues on init_hw_vf failure
VF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at init_hw_vf time. However, the code flow did not reset hw->mac.max_queues to 0. In some cases, such as during reinit flows, we call init_hw_vf without clearing the previous value of hw->mac.max_queues. Due to this, when init_hw_vf errors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing the hw->mac.max_queues on exit due to errors.
---
PATCH v5 4/17 fm10k: always check init_hw for errors
In reply to Jacob KellerA recent change modified init_hw in some flows the function may fail on VF devices. For example, if a VF doesn't yet own its own queues. However, many callers of init_hw didn't bother to check the error code. Other callers checked but only displayed diagnostic messages without actually handling the consequences.
Fix this by (a) always returning and preventing the netdevice from going up, and (b) printing the diagnostic in every flow for consistency. This should resolve an issue where VF drivers would attempt to come up before the PF has finished assigning queues.
In addition, change the dmesg output to explicitly show the actual function that failed, instead of combining reset_hw and init_hw into a single check, to help for future debugging.
--- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 34 ++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 5 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +29 -5
@@ -163,9 +163,17 @@ static void fm10k_reinit(struct fm10k_intfc *interface) interface->last_reset = jiffies + (10 *HZ );/* reset and initialize the hardware so it is in a known state */ - err = hw->mac.ops.reset_hw (hw) ? : hw->mac.ops.init_hw (hw); -if (err) + err = hw->mac.ops.reset_hw (hw); +if (err) { +dev_err (&interface->pdev->dev,"reset_hw failed: %d\n" , err); + goto reinit_err; + } + + err = hw->mac.ops.init_hw (hw); +if (err) {dev_err (&interface->pdev->dev,"init_hw failed: %d\n" , err); + goto reinit_err; + }/* reassociate interrupts */ fm10k_mbx_request_irq (interface);
@@ -193,6 +201,10 @@ static void fm10k_reinit(struct fm10k_intfc *interface)fm10k_iov_resume (interface->pdev); +reinit_err: +if (err) +netif_device_detach (netdev); +rtnl_unlock ();clear_bit (__FM10K_RESETTING, &interface->state);
@@ -1684,7 +1696,13 @@ static int fm10k_sw_init(struct fm10k_intfc *interface, interface->last_reset = jiffies + (10 *HZ );/* reset and initialize the hardware so it is in a known state */ - err = hw->mac.ops.reset_hw (hw) ? : hw->mac.ops.init_hw (hw); + err = hw->mac.ops.reset_hw (hw); +if (err) { +dev_err (&pdev->dev,"reset_hw failed: %d\n" , err); +return err; + } + + err = hw->mac.ops.init_hw (hw);if (err) {dev_err (&pdev->dev,"init_hw failed: %d\n" , err);return err;
@@ -2064,8 +2082,10 @@ static int fm10k_resume(struct pci_dev *pdev)/* reset hardware to known state */ err = hw->mac.ops.init_hw (&interface->hw); -if (err) +if (err) { +dev_err (&pdev->dev,"init_hw failed: %d\n" , err);return err; + }/* reset statistics starting values */ hw->mac.ops.rebind_hw_stats (hw, &interface->stats);
@@ -2241,7 +2261,11 @@ static void fm10k_io_resume(struct pci_dev *pdev)int err =0 ;/* reset hardware to known state */ - hw->mac.ops.init_hw (&interface->hw); + err = hw->mac.ops.init_hw (&interface->hw); +if (err) { +dev_err (&pdev->dev,"init_hw failed: %d\n" , err); +return ; + }/* reset statistics starting values */ hw->mac.ops.rebind_hw_stats (hw, &interface->stats);
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 4/17 fm10k: always check init_hw for errors
Quoted 23 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 04/17] fm10k: always checkinit_hwfor errorsA recent change modified
init_hwin some flows the function may fail on VF devices. For example, if a VF doesn't yet own its own queues. However, many callers ofinit_hwdidn't bother to check the error code. Other callers checked but only displayed diagnostic messages without actually handling the consequences.Fix this by (a) always returning and preventing the netdevice from going up, and (b) printing the diagnostic in every flow for consistency. This should resolve an issue where VF drivers would attempt to come up before the PF has finished assigning queues.
In addition, change the dmesg output to explicitly show the actual function that failed, instead of combining
reset_hwandinit_hwinto a single check, to help for future debugging.
Quoted 6 lines
Fixes 1d568b0f6424 ("fm10k: do not assume VF always has 1 queue")Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 34 ++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 5 deletions(-)
PATCH v5 5/17 fm10k: reinitialize queuing scheme after calling init_hw
In reply to Jacob KellerThe init_hw function may fail, and in the case of VFs, it might change the number of maximum queues available. Thus, for every flow which checks init_hw, we need to ensure that we clear the queue scheme before, and initialize it after. The fm10k_io_slot_reset path will end up triggering a reset so fm10k_reinit needs this change. The fm10k_io_error_detected and fm10k_io_resume also need to properly clear and reinitialize the queue scheme.
--- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +18 -0
@@ -159,6 +159,9 @@ static void fm10k_reinit(struct fm10k_intfc *interface)fm10k_mbx_free_irq (interface); +/* free interrupts */ +fm10k_clear_queueing_scheme (interface); +/* delay any future reset requests */ interface->last_reset = jiffies + (10 *HZ );
@@ -175,6 +178,12 @@ static void fm10k_reinit(struct fm10k_intfc *interface) goto reinit_err; } + err =fm10k_init_queueing_scheme (interface); +if (err) { +dev_err (&interface->pdev->dev,"init_queueing_scheme failed: %d\n" , err); + goto reinit_err; + } +/* reassociate interrupts */ fm10k_mbx_request_irq (interface);
@@ -2198,6 +2207,9 @@ static pci_ers_result_t fm10k_io_error_detected(struct pci_dev *pdev,if (netif_running (netdev))fm10k_close (netdev); +/* free interrupts */ +fm10k_clear_queueing_scheme (interface); +fm10k_mbx_free_irq (interface);pci_disable_device (pdev);
@@ -2270,6 +2282,12 @@ static void fm10k_io_resume(struct pci_dev *pdev)/* reset statistics starting values */ hw->mac.ops.rebind_hw_stats (hw, &interface->stats); + err =fm10k_init_queueing_scheme (interface); +if (err) { +dev_err (&interface->pdev->dev,"init_queueing_scheme failed: %d\n" , err); +return ; + } +/* reassociate interrupts */ fm10k_mbx_request_irq (interface);
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 5/17 fm10k: reinitialize queuing scheme after calling init_hw
Quoted 17 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 05/17] fm10k: reinitialize queuing scheme after callinginit_hwThe
init_hwfunction may fail, and in the case of VFs, it might change the number of maximum queues available. Thus, for every flow which checksinit_hw, we need to ensure that we clear the queue scheme before, and initialize it after. Thefm10k_io_slot_resetpath will end up triggering a reset sofm10k_reinitneeds this change. Thefm10k_io_error_detectedandfm10k_io_resumealso need to properly clear
and reinitialize the queue scheme.
Quoted 4 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
Singh
PATCH v5 5/17 fm10k: reinitialize queuing scheme after calling init_hw
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 05/17] fm10k: reinitialize queuing scheme after calling init_hw
The init_hw function may fail, and in the case of VFs, it might change the number of maximum queues available. Thus, for every flow which checks init_hw, we need to ensure that we clear the queue scheme before, and initialize it after. The fm10k_io_slot_reset path will end up triggering a reset so fm10k_reinit needs this change. The fm10k_io_error_detected and fm10k_io_resume also need to properly clear and reinitialize the queue scheme.
---
PATCH v5 6/17 fm10k: Correct typecast in fm10k_update_xc_addr_pf
In reply to Jacob KellerSince the resultant data type of the mac_update.mac_upper field is u16, it does not make sense to typecast u8 variables to u32 first. Since we're modifying fm10k_pf.c, also update the copyright year.
--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_pf.c +3 -3
@@ -1,5 +1,5 @@/* Intel Ethernet Switch Host Interface Driver -* Copyright(c) 2013 - 2014 Intel Corporation. +* Copyright(c) 2013 - 2015 Intel Corporation. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License,
@@ -334,8 +334,8 @@ static s32 fm10k_update_xc_addr_pf(struct fm10k_hw *hw, u16 glort, ((u32 )mac[3 ] <<16 ) | ((u32 )mac[4 ] <<8 ) | ((u32)mac[5])); - mac_update.mac_upper =cpu_to_le16 (((u32 )mac[0 ] <<8 ) | - ((u32 )mac[1 ])); + mac_update.mac_upper =cpu_to_le16 (((u16 )mac[0 ] <<8 ) | + ((u16 )mac[1 ])); mac_update.vlan =cpu_to_le16 (vid); mac_update.glort =cpu_to_le16 (glort); mac_update.action = add ?0 :1 ;
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 6/17 fm10k: Correct typecast in fm10k_update_xc_addr_pf
Quoted 12 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 06/17] fm10k: Correct typecast infm10k_update_xc_addr_pfSince the resultant data type of the mac_update.mac_upper field is u16, it does not make sense to typecast u8 variables to u32 first. Since we're modifying
fm10k_pf.c, also update the copyright year.
Quoted 5 lines
Reported-by Matthew Vick <[email protected]>Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Singh
PATCH v5 6/17 fm10k: Correct typecast in fm10k_update_xc_addr_pf
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Allan, Bruce W
Sent: Friday, October 16, 2015 4:41 PM
To: Keller, Jacob E <[email protected]>; Intel Wired LAN <[email protected]>
Subject: Re: [Intel-wired-lan] [next-queue v5 06/17] fm10k: Correct typecast in fm10k_update_xc_addr_pf
Quoted 13 lines
-----Original Message-----
From: Intel-wired-lan
[mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 06/17] fm10k: Correct typecast infm10k_update_xc_addr_pfSince the resultant data type of the mac_update.mac_upper field is u16, it does not make sense to typecast u8 variables to u32 first. Since we're modifying
fm10k_pf.c, also update the copyright year.
Quoted 5 lines
Reported-by Matthew Vick <[email protected]>Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
PATCH v5 7/17 fm10k: explicitly typecast vlan values to u16
In reply to Jacob Keller--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_pf.c +3 -3
@@ -1212,7 +1212,7 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results, set = !(vid &FM10K_VLAN_CLEAR ); vid &= ~FM10K_VLAN_CLEAR ; - err =fm10k_iov_select_vid (vf_info, vid); + err =fm10k_iov_select_vid (vf_info, (u16 )vid);if (err <0 )return err;else
@@ -1242,7 +1242,7 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results,if (err <0 )return err;else - vlan = err; + vlan = (u16 )err;/* notify switch of request for new unicast address */ err = hw->mac.ops.update_uc_addr(hw, vf_info->glort,
@@ -1268,7 +1268,7 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 **results,if (err <0 )return err;else - vlan = err; + vlan = (u16 )err;/* notify switch of request for new multicast address */ err = hw->mac.ops.update_mc_addr(hw, vf_info->glort,
Signature · 1 line
2.6.1.264.gbab76a9
Singh
PATCH v5 7/17 fm10k: explicitly typecast vlan values to u16
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 07/17] fm10k: explicitly typecast vlan values to u16
---
PATCH v5 8/17 fm10k: add statistics for actual DWORD count of mbmem mailbox
In reply to Jacob KellerA previous bug was uncovered by addition of a debug stat to indicate the actual number of DWORDS we pulled from the mbmem. It turned out this was not the same as the tx_dwords counter. While the previous bug fix should have corrected this in all cases, add some debug stats that count the number of DWORDs pushed or pulled from the mbmem. A future debugger may take advantage of this statistic for debugging purposes. Since we're modifying fm10k_mbx.h, update the copyright year as well.
--- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 4 ++++ drivers/net/ethernet/intel/fm10k/fm10k_mbx.h | 4 +++- 3 files changed, 9 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +2 -0
@@ -114,9 +114,11 @@ static const struct fm10k_stats fm10k_gstrings_mbx_stats[] = {FM10K_MBX_STAT ("mbx_tx_oversized" , tx_dropped),FM10K_MBX_STAT ("mbx_tx_messages" , tx_messages),FM10K_MBX_STAT ("mbx_tx_dwords" , tx_dwords), +FM10K_MBX_STAT ("mbx_tx_mbmem_pulled" , tx_mbmem_pulled),FM10K_MBX_STAT ("mbx_rx_messages" , rx_messages),FM10K_MBX_STAT ("mbx_rx_dwords" , rx_dwords),FM10K_MBX_STAT ("mbx_rx_parse_err" , rx_parse_err), + FM10K_MBX_STAT("mbx_rx_mbmem_pushed", rx_mbmem_pushed), };#define FM10K_GLOBAL_STATS_LEN ARRAY_SIZE(fm10k_gstrings_global_stats)
drivers/net/ethernet/intel/fm10k/fm10k_mbx.c +4 -0
@@ -375,6 +375,8 @@ static void fm10k_mbx_write_copy(struct fm10k_hw *hw,if (!tail) tail++; + mbx->tx_mbmem_pulled++; +/* write message to hardware FIFO */ fm10k_write_reg (hw, mbmem + tail++, *(head++)); }while (--len && --end);
@@ -459,6 +461,8 @@ static void fm10k_mbx_read_copy(struct fm10k_hw *hw,if (!head) head++; + mbx->rx_mbmem_pushed++; +/* read message from hardware FIFO */ *(tail++) =fm10k_read_reg (hw, mbmem + head++); }while (--len && --end);
drivers/net/ethernet/intel/fm10k/fm10k_mbx.h +3 -1
@@ -1,5 +1,5 @@/* Intel Ethernet Switch Host Interface Driver -* Copyright(c) 2013 - 2014 Intel Corporation. +* Copyright(c) 2013 - 2015 Intel Corporation. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License,
@@ -291,8 +291,10 @@ struct fm10k_mbx_info {u64 tx_dropped;u64 tx_messages;u64 tx_dwords; +u64 tx_mbmem_pulled;u64 rx_messages;u64 rx_dwords; +u64 rx_mbmem_pushed;u64 rx_parse_err;/* Buffer to store messages */
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 8/17 fm10k: add statistics for actual DWORD count of mbmem mailbox
Quoted 18 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 08/17] fm10k: add statistics for actual DWORD count of mbmem mailboxA previous bug was uncovered by addition of a debug stat to indicate the actual number of DWORDS we pulled from the mbmem. It turned out this was
not the same as thetx_dwordscounter. While the previous bug fix should have corrected this in all cases, add some debug stats that count the number of DWORDs pushed or pulled from the mbmem. A future debugger may
take advantage of this statistic for debugging purposes. Since we're modifyingfm10k_mbx.h, update the copyright year as well.
Quoted 6 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 4 ++++ drivers/net/ethernet/intel/fm10k/fm10k_mbx.h | 4 +++- 3 files changed, 9 insertions(+), 1 deletion(-)
Singh
PATCH v5 8/17 fm10k: add statistics for actual DWORD count of mbmem mailbox
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 08/17] fm10k: add statistics for actual DWORD count of mbmem mailbox
A previous bug was uncovered by addition of a debug stat to indicate the actual number of DWORDS we pulled from the mbmem. It turned out this was not the same as the tx_dwords counter. While the previous bug fix should have corrected this in all cases, add some debug stats that count the number of DWORDs pushed or pulled from the mbmem. A future debugger may take advantage of this statistic for debugging purposes. Since we're modifying fm10k_mbx.h, update the copyright year as well.
---
PATCH v5 9/17 fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped
In reply to Jacob KellerOriginally this statistic was renamed because the method of dropping was called "drop_oversized_messages", but this logic has changed much, and this counter does actually represent messages which we failed to transmit for a number of reasons. Rename the counter back to tx_dropped since this is when it will increment, and it is less confusing.
--- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +1 -1
@@ -111,7 +111,7 @@ static const struct fm10k_stats fm10k_gstrings_pf_stats[] = {static const struct fm10k_stats fm10k_gstrings_mbx_stats[] = {FM10K_MBX_STAT ("mbx_tx_busy" , tx_busy), -FM10K_MBX_STAT ("mbx_tx_oversized" , tx_dropped), +FM10K_MBX_STAT ("mbx_tx_dropped" , tx_dropped),FM10K_MBX_STAT ("mbx_tx_messages" , tx_messages),FM10K_MBX_STAT ("mbx_tx_dwords" , tx_dwords),FM10K_MBX_STAT ("mbx_tx_mbmem_pulled" , tx_mbmem_pulled),
Signature · 1 line
2.6.1.264.gbab76a9
Singh
PATCH v5 9/17 fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 09/17] fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped
Originally this statistic was renamed because the method of dropping was called "drop_oversized_messages", but this logic has changed much, and this counter does actually represent messages which we failed to transmit for a number of reasons. Rename the counter back to tx_dropped since this is when it will increment, and it is less confusing.
---
PATCH v5 10/17 fm10k: add TEB check to fm10k_gre_is_nvgre
In reply to Jacob KellerThe NVGRE protocol should be run over transparent ethernet bridge protocol, so we should verify this in our check whether the GRE tunnel is NVGRE. While we're touching fm10k_main.c, update the copyright year.
--- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k_main.c +5 -1
@@ -1,5 +1,5 @@/* Intel Ethernet Switch Host Interface Driver -* Copyright(c) 2013 - 2014 Intel Corporation. +* Copyright(c) 2013 - 2015 Intel Corporation. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License,
@@ -708,6 +708,10 @@ static struct ethhdr *fm10k_gre_is_nvgre(struct sk_buff *skb)if (nvgre_hdr->flags &FM10K_NVGRE_RESERVED0_FLAGS )return NULL ; +/* verify protocol is transparent Ethernet bridging */ +if (nvgre_hdr->proto !=htons (ETH_P_TEB )) +return NULL ; +/* report start of ethernet header */ if (nvgre_hdr->flags &NVGRE_TNI )return (struct ethhdr *)(nvgre_hdr +1 );
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 10/17 fm10k: add TEB check to fm10k_gre_is_nvgre
Quoted 8 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 10/17] fm10k: add TEB check tofm10k_gre_is_nvgre
Quoted 8 lines
The NVGRE protocol should be run over transparent ethernet bridge protocol, so we should verify this in our check whether the GRE tunnel is NVGRE. While we're touching
fm10k_main.c, update the copyright year.Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Singh
PATCH v5 10/17 fm10k: add TEB check to fm10k_gre_is_nvgre
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 10/17] fm10k: add TEB check to fm10k_gre_is_nvgre
The NVGRE protocol should be run over transparent ethernet bridge protocol, so we should verify this in our check whether the GRE tunnel is NVGRE. While we're touching fm10k_main.c, update the copyright year.
---
PATCH v5 11/17 fm10k: Add support for ITR scaling based on PCIe link speed
In reply to Jacob KellerThe Intel Ethernet Switch FM10000 Host Interface interrupt throttle timers are based on the PCIe link speed. Because of this, the value being programmed into the ITR registers must be scaled accordingly.
For the PF, this is as simple as reading the PCIe link speed and storing the result. However, in the case of SR-IOV, the VF's interrupt throttle timers are based on the link speed of the PF. However, the VF is unable to get the link speed information from its configuration space, so the PF must inform it of what scale to use.
Rather than pass this scale via mailbox message, take advantage of unused bits in the TDLEN register to pass the scale. It is the responsibility of the PF to program this for the VF while setting up the VF queues and the responsibility of the VF to get the information accordingly. This is preferable because it allows the VF to set up the interrupts properly during initialization and matches how the MAC address is passed in the TDBAL/TDBAH registers.
Since we're modifying fm10k_type.h, we may as well also update the copyright year.
--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 22 +++++++++++++++++++++- drivers/net/ethernet/intel/fm10k/fm10k_type.h | 17 ++++++++++++++++- drivers/net/ethernet/intel/fm10k/fm10k_vf.c | 20 ++++++++++++++++++-- 3 files changed, 55 insertions(+), 4 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_pf.c +21 -1
@@ -150,19 +150,26 @@ static s32 fm10k_init_hw_pf(struct fm10k_hw *hw) FM10K_TPH_RXCTRL_HDR_WROEN); } -/* set max hold interval to align with 1.024 usec in all modes */ +/* set max hold interval to align with 1.024 usec in all modes and +* store ITR scale +*/ switch (hw->bus.speed) {case fm10k_bus_speed_2500: dma_ctrl =FM10K_DMA_CTRL_MAX_HOLD_1US_GEN1 ; + hw->mac.itr_scale =FM10K_TDLEN_ITR_SCALE_GEN1 ;break ;case fm10k_bus_speed_5000: dma_ctrl =FM10K_DMA_CTRL_MAX_HOLD_1US_GEN2 ; + hw->mac.itr_scale =FM10K_TDLEN_ITR_SCALE_GEN2 ;break ;case fm10k_bus_speed_8000: dma_ctrl =FM10K_DMA_CTRL_MAX_HOLD_1US_GEN3 ; + hw->mac.itr_scale =FM10K_TDLEN_ITR_SCALE_GEN3 ;break ;default : dma_ctrl =0 ; +/* just in case, assume Gen3 ITR scale */ + hw->mac.itr_scale =FM10K_TDLEN_ITR_SCALE_GEN3 ;break ; }
@@ -903,6 +910,13 @@ static s32 fm10k_iov_assign_default_mac_vlan_pf(struct fm10k_hw *hw,fm10k_write_reg (hw,FM10K_TDBAL (vf_q_idx), tdbal);fm10k_write_reg (hw,FM10K_TDBAH (vf_q_idx), tdbah); +/* Provide the VF the ITR scale, using software-defined fields in TDLEN +* to pass the information during VF initialization. See definition of +* FM10K_TDLEN_ITR_SCALE_SHIFT for more details. +*/ +fm10k_write_reg (hw,FM10K_TDLEN (vf_q_idx), hw->mac.itr_scale << +FM10K_TDLEN_ITR_SCALE_SHIFT ); + err_out:/* configure Queue control register */ txqctl = ((u32)vf_vid << FM10K_TXQCTL_VID_SHIFT) &
@@ -1035,6 +1049,12 @@ static s32 fm10k_iov_reset_resources_pf(struct fm10k_hw *hw,for (i = queues_per_pool; i--;) {fm10k_write_reg (hw,FM10K_TDBAL (vf_q_idx + i), tdbal);fm10k_write_reg (hw,FM10K_TDBAH (vf_q_idx + i), tdbah); +/* See definition of FM10K_TDLEN_ITR_SCALE_SHIFT for an +* explanation of how TDLEN is used. +*/ +fm10k_write_reg (hw,FM10K_TDLEN (vf_q_idx + i), + hw->mac.itr_scale << +FM10K_TDLEN_ITR_SCALE_SHIFT );fm10k_write_reg (hw,FM10K_TQMAP (qmap_idx + i), vf_q_idx + i);fm10k_write_reg (hw,FM10K_RQMAP (qmap_idx + i), vf_q_idx + i); }
drivers/net/ethernet/intel/fm10k/fm10k_type.h +16 -1
@@ -1,5 +1,5 @@/* Intel Ethernet Switch Host Interface Driver -* Copyright(c) 2013 - 2014 Intel Corporation. +* Copyright(c) 2013 - 2015 Intel Corporation. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License,
@@ -272,6 +272,20 @@ struct fm10k_hw;#define FM10K_TDBAL (_n) ((0x40 * (_n)) + 0x8000)#define FM10K_TDBAH (_n) ((0x40 * (_n)) + 0x8001)#define FM10K_TDLEN (_n) ((0x40 * (_n)) + 0x8002) +/* When fist initialized, VFs need to know the Interrupt Throttle Rate (ITR) +* scale which is based on the PCIe speed but the speed information in the PCI +* configuration space may not be accurate. The PF already knows the ITR scale +* but there is no defined method to pass that information from the PF to the +* VF. This is accomplished during VF initialization by temporarily co-opting +* the yet-to-be-used TDLEN register to have the PF store the ITR shift for +* the VF to retrieve before the VF needs to use the TDLEN register for its +* intended purpose, i.e. before the Tx resources are allocated. +*/ +#define FM10K_TDLEN_ITR_SCALE_SHIFT 9 +#define FM10K_TDLEN_ITR_SCALE_MASK 0x00000E00 +#define FM10K_TDLEN_ITR_SCALE_GEN1 2 +#define FM10K_TDLEN_ITR_SCALE_GEN2 1 +#define FM10K_TDLEN_ITR_SCALE_GEN3 0#define FM10K_TPH_TXCTRL (_n) ((0x40 * (_n)) + 0x8003)#define FM10K_TPH_TXCTRL_DESC_TPHEN 0x00000020#define FM10K_TPH_TXCTRL_DESC_RROEN 0x00000200
@@ -560,6 +574,7 @@ struct fm10k_mac_info {bool get_host_state;bool tx_ready;u32 dglort_map; +u8 itr_scale; };struct fm10k_swapi_table_info {
drivers/net/ethernet/intel/fm10k/fm10k_vf.c +18 -2
@@ -28,7 +28,7 @@static s32 fm10k_stop_hw_vf (struct fm10k_hw *hw) {u8 *perm_addr = hw->mac.perm_addr; -u32 bal =0 , bah =0 ; +u32 bal =0 , bah =0 , tdlen;s32 err;u16 i;
@@ -48,6 +48,9 @@ static s32 fm10k_stop_hw_vf(struct fm10k_hw *hw) ((u32 )perm_addr[2 ]); } +/* restore default itr_scale for next VF initialization */ + tdlen = hw->mac.itr_scale <<FM10K_TDLEN_ITR_SCALE_SHIFT ; +/* The queues have already been disabled so we just need to * update their base address registers */
@@ -56,6 +59,12 @@ static s32 fm10k_stop_hw_vf(struct fm10k_hw *hw)fm10k_write_reg (hw,FM10K_TDBAH (i), bah);fm10k_write_reg (hw,FM10K_RDBAL (i), bal);fm10k_write_reg (hw,FM10K_RDBAH (i), bah); +/* Restore ITR scale in software-defined mechanism in TDLEN +* for next VF initialization. See definition of +* FM10K_TDLEN_ITR_SCALE_SHIFT for more details on the use of +* TDLEN here. +*/ +fm10k_write_reg (hw,FM10K_TDLEN (i), tdlen); }return 0 ;
@@ -131,9 +140,16 @@ static s32 fm10k_init_hw_vf(struct fm10k_hw *hw)/* record maximum queue count */ hw->mac.max_queues = i; -/* fetch default VLAN */ +/* fetch default VLAN and ITR scale */ hw->mac.default_vid = (fm10k_read_reg (hw,FM10K_TXQCTL (0 )) &FM10K_TXQCTL_VID_MASK ) >>FM10K_TXQCTL_VID_SHIFT ; +/* Read the ITR scale from TDLEN. See the definition of +* FM10K_TDLEN_ITR_SCALE_SHIFT for more information about how TDLEN is +* used here. +*/ + hw->mac.itr_scale = (fm10k_read_reg (hw,FM10K_TDLEN (0 )) & +FM10K_TDLEN_ITR_SCALE_MASK ) >> +FM10K_TDLEN_ITR_SCALE_SHIFT ;return 0 ;
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 11/17 fm10k: Add support for ITR scaling based on PCIe link speed
Quoted 31 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 11/17] fm10k: Add support for ITR scaling based on PCIe link speedThe Intel Ethernet Switch FM10000 Host Interface interrupt throttle timers are based on the PCIe link speed. Because of this, the value being programmed into the ITR registers must be scaled accordingly.
For the PF, this is as simple as reading the PCIe link speed and storing the result. However, in the case of SR-IOV, the VF's interrupt throttle timers are based on the link speed of the PF. However, the VF is unable to get the link speed information from its configuration space, so the PF must inform it of what scale to use.
Rather than pass this scale via mailbox message, take advantage of unused bits in the TDLEN register to pass the scale. It is the responsibility of the PF to program this for the VF while setting up the VF queues and the responsibility of the VF to get the information accordingly. This is preferable because it allows the VF to set up the interrupts properly during initialization and matches how the MAC address is passed in the TDBAL/TDBAH registers.
Since we're modifying
fm10k_type.h, we may as well also update the copyright year.Reported-by Matthew Vick <[email protected]>Signed-off-by Jacob Keller <[email protected]>
Quoted 8 lines
--- drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 22 +++++++++++++++++++++- drivers/net/ethernet/intel/fm10k/fm10k_type.h | 17 ++++++++++++++++- drivers/net/ethernet/intel/fm10k/fm10k_vf.c | 20 ++++++++++++++++++-- 3 files changed, 55 insertions(+), 4 deletions(-)
Singh
PATCH v5 11/17 fm10k: Add support for ITR scaling based on PCIe link speed
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 11/17] fm10k: Add support for ITR scaling based on PCIe link speed
The Intel Ethernet Switch FM10000 Host Interface interrupt throttle timers are based on the PCIe link speed. Because of this, the value being programmed into the ITR registers must be scaled accordingly.
For the PF, this is as simple as reading the PCIe link speed and storing the result. However, in the case of SR-IOV, the VF's interrupt throttle timers are based on the link speed of the PF. However, the VF is unable to get the link speed information from its configuration space, so the PF must inform it of what scale to use.
Rather than pass this scale via mailbox message, take advantage of unused bits in the TDLEN register to pass the scale. It is the responsibility of the PF to program this for the VF while setting up the VF queues and the responsibility of the VF to get the information accordingly. This is preferable because it allows the VF to set up the interrupts properly during initialization and matches how the MAC address is passed in the TDBAL/TDBAH registers.
Since we're modifying fm10k_type.h, we may as well also update the copyright year.
---
PATCH v5 12/17 fm10k: introduce ITR_IS_ADAPTIVE macro
In reply to Jacob KellerDefine a macro for identifying when the itr value is dynamic or adaptive. The concept was taken from i40e. This helps make clear what the check is, and reduces the line length to something more reasonable in a few places.
--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 6 ++---- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k.h +2 -0
@@ -172,6 +172,8 @@ struct fm10k_ring_container {#define FM10K_ITR_20K 50/* 50us */ #define FM10K_ITR_ADAPTIVE 0x8000/* adaptive interrupt moderation flag */ +#define ITR_IS_ADAPTIVE (itr) (!!(itr & FM10K_ITR_ADAPTIVE)) +#define FM10K_ITR_ENABLE (FM10K_ITR_AUTOMASK | FM10K_ITR_MASK_CLEAR)static inline struct netdev_queue *txring_txq (const struct fm10k_ring *ring)
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +2 -4
@@ -705,12 +705,10 @@ static int fm10k_get_coalesce(struct net_device *dev, {struct fm10k_intfc *interface =netdev_priv (dev); - ec->use_adaptive_tx_coalesce = - !!(interface->tx_itr &FM10K_ITR_ADAPTIVE ); + ec->use_adaptive_tx_coalesce =ITR_IS_ADAPTIVE (interface->tx_itr); ec->tx_coalesce_usecs = interface->tx_itr & ~FM10K_ITR_ADAPTIVE ; - ec->use_adaptive_rx_coalesce = - !!(interface->rx_itr &FM10K_ITR_ADAPTIVE ); + ec->use_adaptive_rx_coalesce =ITR_IS_ADAPTIVE (interface->rx_itr); ec->rx_coalesce_usecs = interface->rx_itr & ~FM10K_ITR_ADAPTIVE ;return 0 ;
drivers/net/ethernet/intel/fm10k/fm10k_main.c +1 -1
@@ -1370,7 +1370,7 @@ static void fm10k_update_itr(struct fm10k_ring_container *ring_container)unsigned int avg_wire_size, packets;/* Only update ITR if we are using adaptive setting */ -if (!(ring_container->itr &FM10K_ITR_ADAPTIVE )) +if (!ITR_IS_ADAPTIVE (ring_container->itr)) goto clear_counts; packets = ring_container->total_packets;
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 12/17 fm10k: introduce ITR_IS_ADAPTIVE macro
Quoted 13 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 12/17] fm10k: introduceITR_IS_ADAPTIVEmacroDefine a macro for identifying when the itr value is dynamic or adaptive. The concept was taken from i40e. This helps make clear what the check is, and reduces the line length to something more reasonable in a few places.
Quoted 6 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 6 ++---- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
Singh
PATCH v5 12/17 fm10k: introduce ITR_IS_ADAPTIVE macro
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 12/17] fm10k: introduce ITR_IS_ADAPTIVE macro
Define a macro for identifying when the itr value is dynamic or adaptive. The concept was taken from i40e. This helps make clear what the check is, and reduces the line length to something more reasonable in a few places.
---
PATCH v5 13/17 fm10k: Update adaptive ITR algorithm
In reply to Jacob KellerThe existing adaptive ITR algorithm is overly restrictive. It throttles incorrectly for various traffic rates, and does not produce good performance. The algorithm now allows for more interrupts per second, and does some calculation to help improve for smaller packet loads. In addition, take into account the new itr_scale from the hardware which indicates how much to scale due to PCIe link speed.
--- drivers/net/ethernet/intel/fm10k/fm10k.h | 1 + drivers/net/ethernet/intel/fm10k/fm10k_main.c | 52 ++++++++++++++++++++------- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 ++-- 3 files changed, 45 insertions(+), 14 deletions(-)
Changes in v5:
* fix comment to 250k ints/sec, instead of 333k, as math for this was incorrect.
drivers/net/ethernet/intel/fm10k/fm10k.h +1 -0
@@ -164,6 +164,7 @@ struct fm10k_ring_container {unsigned int total_packets;/* total packets processed this int */ u16 work_limit;/* total work allowed per interrupt */ u16 itr;/* interrupt throttle rate value */ +u8 itr_scale;/* ITR adjustment scaler based on PCI speed */ u8 count;/* total number of rings in vector */ };
drivers/net/ethernet/intel/fm10k/fm10k_main.c +40 -12
77 lines not on this page · raw message
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +4 -2
@@ -880,7 +880,8 @@ static irqreturn_t fm10k_msix_mbx_vf(int __always_unused irq, void *data)/* re-enable mailbox interrupt and indicate 20us delay */ fm10k_write_reg (hw,FM10K_VFITR (FM10K_MBX_VECTOR ), -FM10K_ITR_ENABLE |FM10K_MBX_INT_DELAY ); +FM10K_ITR_ENABLE | (FM10K_MBX_INT_DELAY >> + hw->mac.itr_scale));/* service upstream mailbox */ if (fm10k_mbx_trylock (interface)) {
@@ -1111,7 +1112,8 @@ static irqreturn_t fm10k_msix_mbx_pf(int __always_unused irq, void *data)/* re-enable mailbox interrupt and indicate 20us delay */ fm10k_write_reg (hw,FM10K_ITR (FM10K_MBX_VECTOR ), -FM10K_ITR_ENABLE |FM10K_MBX_INT_DELAY ); +FM10K_ITR_ENABLE | (FM10K_MBX_INT_DELAY >> + hw->mac.itr_scale));return IRQ_HANDLED ; }
Signature · 1 line
2.6.1.264.gbab76a9
Singh
PATCH v5 13/17 fm10k: Update adaptive ITR algorithm
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 13/17] fm10k: Update adaptive ITR algorithm
The existing adaptive ITR algorithm is overly restrictive. It throttles incorrectly for various traffic rates, and does not produce good performance. The algorithm now allows for more interrupts per second, and does some calculation to help improve for smaller packet loads. In addition, take into account the new itr_scale from the hardware which indicates how much to scale due to PCIe link speed.
---
PATCH v5 14/17 fm10k: use macro for default Tx and Rx ITR values
In reply to Jacob Keller--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 4 ++-- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k.h +2 -0
@@ -175,6 +175,8 @@ struct fm10k_ring_container {#define ITR_IS_ADAPTIVE (itr) (!!(itr & FM10K_ITR_ADAPTIVE)) +#define FM10K_TX_ITR_DEFAULT FM10K_ITR_10K +#define FM10K_RX_ITR_DEFAULT FM10K_ITR_20K#define FM10K_ITR_ENABLE (FM10K_ITR_AUTOMASK | FM10K_ITR_MASK_CLEAR)static inline struct netdev_queue *txring_txq (const struct fm10k_ring *ring)
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +2 -2
@@ -733,10 +733,10 @@ static int fm10k_set_coalesce(struct net_device *dev,/* set initial values for adaptive ITR */ if (ec->use_adaptive_tx_coalesce) - tx_itr =FM10K_ITR_ADAPTIVE |FM10K_ITR_10K ; + tx_itr =FM10K_ITR_ADAPTIVE |FM10K_TX_ITR_DEFAULT ;if (ec->use_adaptive_rx_coalesce) - rx_itr =FM10K_ITR_ADAPTIVE |FM10K_ITR_20K ; + rx_itr =FM10K_ITR_ADAPTIVE |FM10K_RX_ITR_DEFAULT ;/* update interface */ interface->tx_itr = tx_itr;
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +2 -2
@@ -1771,8 +1771,8 @@ static int fm10k_sw_init(struct fm10k_intfc *interface, interface->rx_ring_count =FM10K_DEFAULT_RXD ;/* set default interrupt moderation */ - interface->tx_itr =FM10K_ITR_10K ; - interface->rx_itr =FM10K_ITR_ADAPTIVE |FM10K_ITR_20K ; + interface->tx_itr =FM10K_TX_ITR_DEFAULT ; + interface->rx_itr =FM10K_ITR_ADAPTIVE |FM10K_RX_ITR_DEFAULT ;/* initialize vxlan_port list */ INIT_LIST_HEAD (&interface->vxlan_port);
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 14/17 fm10k: use macro for default Tx and Rx ITR values
Quoted 8 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 14/17] fm10k: use macro for default Tx and Rx ITR values
Quoted 6 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/fm10k.h | 2 ++ drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 4 ++-- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-)
Singh
PATCH v5 14/17 fm10k: use macro for default Tx and Rx ITR values
In reply to Jacob Keller-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 14/17] fm10k: use macro for default Tx and Rx ITR values
---
PATCH v5 15/17 fm10k: change default Tx ITR to 25usec
In reply to Jacob KellerThe current default ITR for Tx is overly restrictive. Using a simple netperf TCP_STREAM test, we top out at about 10Gb/s for a single thread when running using 1500 byte frames. By reducing the ITR value to 25usec (up to 40K interrupts a second from 10K), we are able to achieve 36Gb/s for a single thread TCP stream test.
--- drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k.h +2 -1
@@ -171,11 +171,12 @@ struct fm10k_ring_container {#define FM10K_ITR_MAX 0x0FFF/* maximum value for ITR */ #define FM10K_ITR_10K 100/* 100us */ #define FM10K_ITR_20K 50/* 50us */ +#define FM10K_ITR_40K 25/* 25us */ #define FM10K_ITR_ADAPTIVE 0x8000/* adaptive interrupt moderation flag */ #define ITR_IS_ADAPTIVE (itr) (!!(itr & FM10K_ITR_ADAPTIVE)) -#define FM10K_TX_ITR_DEFAULT FM10K_ITR_10K +#define FM10K_TX_ITR_DEFAULT FM10K_ITR_40K#define FM10K_RX_ITR_DEFAULT FM10K_ITR_20K#define FM10K_ITR_ENABLE (FM10K_ITR_AUTOMASK | FM10K_ITR_MASK_CLEAR)
Signature · 1 line
2.6.1.264.gbab76a9
Singh
PATCH v5 15/17 fm10k: change default Tx ITR to 25usec
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 15/17] fm10k: change default Tx ITR to 25usec
The current default ITR for Tx is overly restrictive. Using a simple netperf TCP_STREAM test, we top out at about 10Gb/s for a single thread when running using 1500 byte frames. By reducing the ITR value to 25usec (up to 40K interrupts a second from 10K), we are able to achieve 36Gb/s for a single thread TCP stream test.
---
PATCH v5 16/17 fm10k: TRIVIAL fix typo of hardware
In reply to Jacob Keller--- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +2 -2
@@ -584,7 +584,7 @@ static void fm10k_configure_tx_ring(struct fm10k_intfc *interface,/* store tail pointer */ ring->tail = &interface->uc_addr[FM10K_TDT (reg_idx)]; -/* reset ntu and ntc to place SW in sync with hardwdare */ +/* reset ntu and ntc to place SW in sync with hardware */ ring->next_to_clean =0 ; ring->next_to_use =0 ;
@@ -690,7 +690,7 @@ static void fm10k_configure_rx_ring(struct fm10k_intfc *interface,/* store tail pointer */ ring->tail = &interface->uc_addr[FM10K_RDT (reg_idx)]; -/* reset ntu and ntc to place SW in sync with hardwdare */ +/* reset ntu and ntc to place SW in sync with hardware */ ring->next_to_clean =0 ; ring->next_to_use =0 ; ring->next_to_alloc =0 ;
Signature · 1 line
2.6.1.264.gbab76a9
Singh
PATCH v5 16/17 fm10k: TRIVIAL fix typo of hardware
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [next-queue v5 16/17] fm10k: TRIVIAL fix typo of hardware
---
PATCH v5 17/17 fm10k: TRIVIAL cleanup order at top of fm10k_xmit_frame
In reply to Jacob Keller--- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_main.c +4 -4
@@ -1098,11 +1098,11 @@ static void fm10k_tx_map(struct fm10k_ring *tx_ring,netdev_tx_t fm10k_xmit_frame_ring (struct sk_buff *skb,struct fm10k_ring *tx_ring) { -struct fm10k_tx_buffer *first; -int tso; -u32 tx_flags =0 ; -unsigned short f;u16 count =TXD_USE_COUNT (skb_headlen (skb)); +struct fm10k_tx_buffer *first; +unsigned short f; +u32 tx_flags =0 ; +int tso;/* need: 1 descriptor per page * PAGE_SIZE/FM10K_MAX_DATA_PER_TXD, * + 1 desc for skb_headlen/FM10K_MAX_DATA_PER_TXD,
Signature · 1 line
2.6.1.264.gbab76a9
Allan
PATCH v5 1/17 fm10k: conditionally compile DCB and DebugFS support
In reply to Jacob KellerQuoted 13 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, October 16, 2015 10:57 AM
To: Intel Wired LAN
Subject: [Intel-wired-lan] [next-queue v5 01/17] fm10k: conditionally compile DCB and DebugFS supportRather than wrapping
fm10k_dcbnl.candfm10k_debugfs.csupport with
#ifdef blocks, just conditionally include the .o files in theMakefile.
Also, since we're modifying it, update the copyright year on theMakefile.
Quoted 8 lines
Signed-off-by Jacob Keller <[email protected]>--- drivers/net/ethernet/intel/fm10k/Makefile | 20 +++++++++++++++---- - drivers/net/ethernet/intel/fm10k/fm10k.h | 4 ++++ drivers/net/ethernet/intel/fm10k/fm10k_dcbnl.c | 4 ---- drivers/net/ethernet/intel/fm10k/fm10k_debugfs.c | 4 ---- 4 files changed, 19 insertions(+), 13 deletions(-)