aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2018-02-15net/mlx5: EQ add/del CQ APISaeed Mahameed3-45/+53
Add API to add/del CQ to/from EQs CQ table to be used in cq.c upon CQ creation/destruction, as CQ table is now private to eq.c. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Gal Pressman <galp@mellanox.com>
2018-02-15net/mlx5: Add missing likely/unlikely hints to cq eventsSaeed Mahameed1-3/+3
If a hardware event is targeting a CQ, that CQ should exist. Add unlikely to error handling flows. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Gal Pressman <galp@mellanox.com>
2018-02-15net/mlx5: CQ Database per EQSaeed Mahameed3-35/+52
Before this patch the driver had one CQ database protected via one spinlock, this spinlock is meant to synchronize between CQ adding/removing and CQ IRQ interrupt handling. On a system with large number of CPUs and on a work load that requires lots of interrupts, this global spinlock becomes a very nasty hotspot and introduces a contention between the active cores, which will significantly hurt performance and becomes a bottleneck that prevents seamless cpu scaling. To solve this we simply move the CQ database and its spinlock to be per EQ (IRQ), thus per core. Tested with: system: 2 sockets, 14 cores per socket, hyperthreading, 2x14x2=56 cores netperf command: ./super_netperf 200 -P 0 -t TCP_RR -H <server> -l 30 -- -r 300,300 -o -s 1M,1M -S 1M,1M WITHOUT THIS PATCH: Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: all 4.32 0.00 36.15 0.09 0.00 34.02 0.00 0.00 0.00 25.41 Samples: 2M of event 'cycles:pp', Event count (approx.): 1554616897271 Overhead Command Shared Object Symbol + 14.28% swapper [kernel.vmlinux] [k] intel_idle + 12.25% swapper [kernel.vmlinux] [k] queued_spin_lock_slowpath + 10.29% netserver [kernel.vmlinux] [k] queued_spin_lock_slowpath + 1.32% netserver [kernel.vmlinux] [k] mlx5e_xmit WITH THIS PATCH: Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: all 4.27 0.00 34.31 0.01 0.00 18.71 0.00 0.00 0.00 42.69 Samples: 2M of event 'cycles:pp', Event count (approx.): 1498132937483 Overhead Command Shared Object Symbol + 23.33% swapper [kernel.vmlinux] [k] intel_idle + 1.69% netserver [kernel.vmlinux] [k] mlx5e_xmit Tested-by: Song Liu <songliubraving@fb.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Gal Pressman <galp@mellanox.com>
2018-02-14Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller9-92/+2133
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2018-02-14 This patch series enables the new mqprio hardware offload mechanism creating traffic classes on VFs for XL710 devices. The parameters needed to configure these traffic classes/queue channels are provides by the user via the tc tool. A maximum of four traffic classes can be created on each VF. This patch series also enables application of cloud filters to each of these traffic classes. The cloud filters are applied using the tc-flower classifier. Example: 1. tc qdisc add dev vf0 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev vf0 ingress 3. ethtool -K vf0 hw-tc-offload on 4. ip link set eth0 vf 0 spoofchk off 5. tc filter add dev vf0 protocol ip parent ffff: prio 1 flower dst_ip\ 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: phy: dp83867: Add binding for the CLK_OUT pin muxing optionWadim Egorov1-0/+19
The DP83867 has a muxing option for the CLK_OUT pin. It is possible to set CLK_OUT for different channels. Create a binding to select a specific clock for CLK_OUT pin. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14cxgb4: speed up on-chip memory readRahul Lakkireddy1-9/+28
Use readq() (via t4_read_reg64()) to read 64-bits at a time. Read residual in 32-bit multiples. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14cxgb4: rework on-chip memory readRahul Lakkireddy3-73/+192
Rework logic to read EDC and MC. Do 32-bit reads at a time. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14ibmvnic: Clean RX pool buffers during device closeThomas Falcon1-1/+30
During device close or reset, there were some cases of outstanding RX socket buffers not being freed. Include a function similar to the one that already exists to clean TX socket buffers in this case. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14ibmvnic: Free RX socket buffer in case of adapter errorThomas Falcon1-0/+1
If a RX buffer is returned to the client driver with an error, free the corresponding socket buffer before continuing. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14ibmvnic: Fix NAPI structures memory leakThomas Falcon1-0/+2
This memory is allocated during initialization but never freed, so do that now. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14ibmvnic: Fix login buffer memory leaksThomas Falcon1-0/+16
During device bringup, the driver exchanges login buffers with firmware. These buffers contain information such number of TX and RX queues alloted to the device, RX buffer size, etc. These buffers weren't being properly freed on device reset or close. We can free the buffer we send to firmware as soon as we get a response. There is information in the response buffer that the driver needs for normal operation so retain it until the next reset or removal. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add workaround for 6341 timestampingBrandon Streiff2-0/+22
88E6341 devices default to timestamping at the PHY, but due to a hardware issue, timestamps via this component are unreliable. For this family, configure the PTP hardware to force the timestamping to occur at the MAC. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add rx/tx timestamping supportBrandon Streiff7-4/+788
This patch implements RX/TX timestamping support. The Marvell PTP hardware supports RX timestamping individual message types, but for simplicity we only support the EVENT receive filter since few if any clients bother with the more specific filter types. checkpatch and reverse Christmas tree changes by Andrew Lunn. Re-factor duplicated code paths and avoid IfOk anti-pattern, use the common ptp worker thread from the class layer and time stamp UDP/IPv4 frames as well as Layer-2 frame by Richard Cochran. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add support for event captureBrandon Streiff3-2/+207
This patch adds support for configuring mv88e6xxx GPIO lines as PTP pins, so that they may be used for time stamping external events or for periodic output. Checkpatch and reverse Christmas tree fixes by Andrew Lunn Periodic output removed by Richard Cochran, until a better abstraction of a VCO is added to Linux in general. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add support for GPIO configurationBrandon Streiff6-0/+334
MV88E6352 and later switches support GPIO control through the "Scratch & Misc" global2 register. (Older switches do too, though with a slightly different register interface. Only the 6352-style is implemented here.) Add a new file, global2_scratch.c, for operations in the Scratch & Misc space. Additionally, add a GPIO operations structure to present an abstract view over GPIO manipulation. Reverse Christmas tree and unsigned has been replaced with unsigned int by Andrew Lunn. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: expose switch time as a PTP hardware clockBrandon Streiff6-0/+326
This patch adds basic support for exposing the 32-bit timestamp counter inside the mv88e6xxx switch as a ptp_clock. Adjfine implemented by Richard Cochran. Andrew Lunn: fix return value of PTP stub function. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: add accessors for PTP/TAI registersBrandon Streiff5-1/+251
This patch implements support for accessing the Precision Time Protocol and Time Application Interface registers via the AVB register interface in the Global 2 register. The register interface differs slightly between different models; older models use a 3-bit operations field, while newer models use a 2-bit field. The operations values and the special "global port" values are different between the two. This is a similar split to the differences in the "Ingress Rate" register between models, so, like in that case, we call the two variants "6352" and "6390" and create an ops structure to abstract between the two. checkpatch fixups by Andrew Lunn Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14net: dsa: mv88e6xxx: export g2 register accessorsBrandon Streiff2-4/+29
Let the mv88e6xxx_g2_* register accessor functions be accessible outside of global2.c. Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14ibmvnic: Wait until reset is complete to set carrier onThomas Falcon1-2/+2
Pushes back setting the carrier on until the end of the reset code. This resolves a bug where a watchdog timer was detecting that a TX queue had stalled before the adapter reset was complete. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14Revert "net: thunderx: Add support for xdp redirect"Jesper Dangaard Brouer3-94/+31
This reverts commit aa136d0c82fcd6af14535853c30e219e02b2692d. As I previously[1] pointed out this implementation of XDP_REDIRECT is wrong. XDP_REDIRECT is a facility that must work between different NIC drivers. Another NIC driver can call ndo_xdp_xmit/nicvf_xdp_xmit, but your driver patch assumes payload data (at top of page) will contain a queue index and a DMA addr, this is not true and worse will likely contain garbage. Given you have not fixed this in due time (just reached v4.16-rc1), the only option I see is a revert. [1] http://lkml.kernel.org/r/20171211130902.482513d3@redhat.com Cc: Sunil Goutham <sgoutham@cavium.com> Cc: Christina Jacob <cjacob@caviumnetworks.com> Cc: Aleksey Makarov <aleksey.makarov@cavium.com> Fixes: aa136d0c82fc ("net: thunderx: Add support for xdp redirect") Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-14i40e: Add and delete cloud filterAvinash Dayanand4-12/+470
This patch provides support to add or delete cloud filter for queue channels created for ADq on VF. We are using the HW's cloud filter feature and programming it to act as a TC filter applied to a group of queues. There are two possible modes for a VF when applying a cloud filter 1. Basic Mode: Intended to apply filters that don't need a VF to be Trusted. This would include the following Dest MAC + L4 port Dest MAC + VLAN + L4 port 2. Advanced Mode: This mode is only for filters with combination that requires VF to be Trusted. Dest IP + L4 port When cloud filters are applied on a trusted VF and for some reason the same VF is later made as untrusted then all cloud filters will be deleted. All cloud filters has to be re-applied in such a case. Cloud filters are also deleted when queue channel is deleted. Testing-Hints: ============= 1. Adding Basic Mode filter should be possible on a VF in Non-Trusted mode. 2. In Advanced mode all filters should be able to be created. Steps: ====== 1. Enable ADq and create TCs using TC mqprio command 2. Apply cloud filter. 3. Turn-off the spoof check. 4. Pass traffic. Example: ======== 1. tc qdisc add dev enp4s2 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev enp4s2 ingress 3. ethtool -K enp4s2 hw-tc-offload on 4. ip link set ens261f0 vf 0 spoofchk off 5. tc filter add dev enp4s2 protocol ip parent ffff: prio 1 flower\ dst_ip 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Add support to apply cloud filtersHarshitha Ramamurthy3-5/+810
This patch enables a tc filter to be applied as a cloud filter for the VF. This patch adds functions which parse the tc filter, extract the necessary fields needed to configure the filter and package them in a virtchnl message to be sent to the PF to apply them. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Service request to configure bandwidth for ADq on a VFAvinash Dayanand2-3/+54
This patch handles the request from ADq enabled VF to allocate bandwidth to each traffic class which means for each VSI. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Add support to configure bw via tc toolHarshitha Ramamurthy3-3/+67
This patch adds support to configure bandwidth for the traffic classes via tc tool. The required information is passed to the PF which is used in the process of setting up the traffic classes. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Delete queue channel for ADq on VFAvinash Dayanand1-0/+63
This patch takes care of freeing up all the VSIs, queues and other ADq related software and hardware resources, when a user requests for deletion of ADq on VF. Example command: tc qdisc del dev eth0 root Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Alloc queues for ADq on VFAvinash Dayanand2-0/+20
This patch allocates number of queues requested by the user as a part of TC command when ADq is enabled on a VF. In order to be consistent in design with PF implementation of ADq, don't allow to set channels via ethtool from VF when ADq is already enabled. This means the users will not be able to change the number of queues/channels via ethtool for a VF when ADq is ON. In order to be able to use set channels, users will be required to disable ADq first and then try setting the channels again. When ADq is enabled on VF, it goes through a reset during which VSIs and queues are re-configured. Meanwhile if we receive link status message from PF even before the queues are re-configured, just ignore this link up message. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40e: Enable ADq and create queue channel/s on VFAvinash Dayanand3-69/+379
This patch enables ADq and creates queue channels on a VF. An ADq enabled VF can have up to 4 VSIs and each one of them represents a traffic class and this is termed as a queue channel. Each of these VSIs can have up to 4 queues. This patch services the request for enabling ADq and adds queue channel based on the TC mqprio info provided by the user in the VF. Initially a check is made to see if spoof check is OFF, if not ADq will not be enabled. PF notifies VF for a reset in order to complete the creation of ADq resources i.e. creation of additional VSIs and allocation of queues as per TC information, all in the reset path. Steps: ====== 1. Turn off the spoof check 2. Enable ADq using tc mqprio command with or without rate limit. 3. Pass traffic. Example: ======== % ip link set dev eth0 vf 0 spoofchk off % tc qdisc add dev $iface root mqprio num_tc 4 map\ 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 queues\ 4@0 4@4 4@8 4@8 hw 1 mode channel Expected results: ================= 1. Total number of queues for the VF should be sum of queues of all TCs. 2. Traffic flow should be normal without errors. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: add ndo_setup_tc callback to i40evfHarshitha Ramamurthy3-1/+257
This patch introduces the callback to the ndo_setup_tc function in the VF driver. We add a wrapper function to make room for the upcoming cloud filter patches which add calls to different functions from setup_tc. First, we add support for capability exchange for ADQ between the PF and VF. Next, we add support to take in the mqprio configuration and configure queues as per the traffic classes, rate limit and the priorities specified by the user. This is done by passing the channel config to the PF driver through a virtchannel message. The flags and bits added, track if ADq is enabled, set max number of traffic classes to 4 and provide ability to negotiate capability with the PF. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-14i40evf: Fix link up issue when queues are disabledAvinash Dayanand3-8/+22
One of the previous patch fixes the link up issue by ignoring it if i40evf is not in __I40EVF_RUNNING state. However this doesn't fix the race condition when queues are disabled esp for ADq on VF. Hence check if all queues are enabled before starting all queues. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: Make VF reset warning message more clearHarshitha Ramamurthy1-1/+1
When the PF resets the VF, the VF puts out a warning message indicating that the VF received a reset message from the PF. Make this message more clear so that we do not mistakenly think that the PF is undergoing a reset. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: use __dev_[um]c_sync routines in .set_rx_modeJacob Keller1-39/+56
Similar to changes done to the PF driver in commit 6622f5cdbaf3 ("i40e: make use of __dev_uc_sync and __dev_mc_sync"), replace our home-rolled method for updating the internal status of MAC filters with __dev_uc_sync and __dev_mc_sync. These new functions use internal state within the netdev struct in order to efficiently break the question of "which filters in this list need to be added or removed" into singular "add this filter" and "delete this filter" requests. This vastly improves our handling of .set_rx_mode especially with large number of MAC filters being added to the device, and even results in a simpler .set_rx_mode handler. Under some circumstances, such as when attached to a bridge, we may receive a request to delete our own permanent address. Prevent deletion of this address during i40evf_addr_unsync so that we don't accidentally stop receiving traffic. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: i40e: Change ethtool check from MAC to HW flagDave Ertman3-10/+13
The MAC, FW Version and NPAR check used to determine if shutting off the FW LLDP engine is supported is not using the usual feature check mechanism. This patch fixes the problem by moving the feature check to i40e_sw_init in order to set a flag in pf->hw_features that ethtool will use for priv_flags disable operation. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: do not force filter failure in overflow promiscuousAlan Brady1-14/+1
Broadcast filters can now cause overflow promiscuous to trigger when adding "too many" VLANs to all the ports of a device and the driver needs a way to exit overflow promiscuous once triggered. Currently the driver looks to see if there are "too many" filters and/or we have any failed filters to determine when it is safe to exit overflow promiscuous. If we trigger overflow promiscuous with broadcast filters, any new filters added will be "auto-failed" until we exit overflow promiscuous. Since the user can't manually remove the failed broadcast filters for VLANs (nor should we expect the user to do such), there is no way to exit overflow promiscuous without reloading the driver. The easiest way to do this is to remove the shortcut to "auto-fail" filters in overflow promiscuous. If the user removes the VLANs, the failed filters will be removed and since we're no longer "auto-failing" new filters, we'll eventually get a good set of filters and exit overflow promiscuous. This has the side benefit of making filter state more explicit in that if a filter says it's failed we know for a fact it failed and not just assuming it will if we're in overflow promiscuous. This is nice because if the user removes some filters and then adds some, even if we're in overflow promiscuous, the filter might succeed; we were just assuming it won't because the user hasn't rectified other existing failed filters. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: refactor promisc_changed in i40e_sync_vsi_filtersAlan Brady1-22/+20
This code here is quite complex and easy to screw up. Let's see if we can't improve the readability and maintainability a bit. This refactors out promisc_changed into two variables 'old_overflow' and 'new_overflow' which makes it a bit clearer when we're concerned about when and how overflow promiscuous is changed. This also makes so that we no longer need to pass a boolean pointer to i40e_aqc_add_filters. Instead we can simply check if we changed the overflow promiscuous flag since the function start. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: Use an iterator of the same type as the listHarshitha Ramamurthy1-4/+7
When iterating through the linked list of VLAN filters, make the iterator the same type as that of the linked list. Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: broadcast filters can trigger overflow promiscuousAlan Brady1-2/+4
When adding a bunch of VLANs to all the ports on a device, it's possible to run out of space for broadcast filters. The driver should trigger overflow promiscuous in this circumstance to prevent traffic from being unexpectedly dropped. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: don't leak memory addressesMitch Williams2-41/+12
Could a Bad Person do Bad Things to a server if they found these addresses printed in the log? Who knows? But let's not take that risk. Remove pointers from a bunch of printks. In some cases, I was able to adjust the message to indicate whether or not the value was null. In others, I just removed the entire message as there was really no hope of saving it. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40evf: use GFP_ATOMIC under spin lockWei Yongjun1-4/+4
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 504398f0a78e ("i40evf: use spinlock to protect (mac|vlan)_filter_list") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: Make local function i40e_get_link_speed staticWei Yongjun1-1/+1
Fixes the following sparse warning: drivers/net/ethernet/intel/i40e/i40e_main.c:5440:5: warning: symbol 'i40e_get_link_speed' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13mlxsw: spectrum: Use NL_SET_ERR_MSG_MODArkadi Sharshevsky3-24/+16
Use NL_SET_ERR_MSG_MOD helper which adds the module name instead of specifying the prefix each time. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Move SPAN code to separate modulePetr Machata6-348/+433
For the upcoming work on SPAN, it makes sense to move the current code to a module of its own. It already has a well-defined API boundary to the mirror management (which is used from matchall and ACL code). A couple more functions need to be exported for the functions that spectrum.c needs to use for MTU handling and subsystem init/fini. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Drop struct span_entry.usedPetr Machata2-5/+2
The member ref_count already determines whether a given SPAN entry is used, and is as easy to use as a dedicated boolean. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Fix a coding style nitPetr Machata1-2/+2
Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum: Distinguish between IPv4/6 tunnelsPetr Machata3-91/+72
struct ip_tunnel_parm, where GRE and several other tunnel types hold information, is IPv4-specific. The current router / ipip code in mlxsw however uses it as if it were generic. Make it clear that it's not. Rename many functions from _params_ to _params4_. mlxsw_sp_ipip_parms_saddr() and _daddr() take a proto argument to dispatch on it. Move the dispatch logic to mlxsw_sp_ipip_netdev_saddr() and _daddr(), and replace with single-protocol functions. In struct mlxsw_sp_ipip_entry, move the "parms" field to a (for the time being, singleton) union. Update users throughout. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum_ipip: Add a forgotten includePetr Machata1-0/+1
struct ip_tunnel_parm, which is used in spectrum_ipip.h, is defined in if_tunnel.h. However, the former neglects to include the latter. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13mlxsw: spectrum_router: Fix error path in mlxsw_sp_vr_createJiri Pirko1-14/+18
Since mlxsw_sp_fib_create() and mlxsw_sp_mr_table_create() use ERR_PTR macro to propagate int err through return of a pointer, the return value is not NULL in case of failure. So if one of the calls fails, one of vr->fib4, vr->fib6 or vr->mr4_table is not NULL and mlxsw_sp_vr_is_used wrongly assumes that vr is in use which leads to crash like following one: [ 1293.949291] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c9 [ 1293.952729] IP: mlxsw_sp_mr_table_flush+0x15/0x70 [mlxsw_spectrum] Fix this by using local variables to hold the pointers and set vr->* only in case everything went fine. Fixes: 76610ebbde18 ("mlxsw: spectrum_router: Refactor virtual router handling") Fixes: a3d9bc506d64 ("mlxsw: spectrum_router: Extend virtual routers with IPv6 support") Fixes: d42b0965b1d4 ("mlxsw: spectrum_router: Add multicast routes notification handling functionality") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13dpaa_eth: fix incorrect commentJake Moroni1-1/+1
The comment stated that a thread was started, but that is not the case. Signed-off-by: Jake Moroni <mail@jakemoroni.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13net: Convert loopback_net_opsKirill Tkhai1-0/+1
These pernet_operations have only init() method. It allocates memory for net_device, calls register_netdev() and assigns net::loopback_dev. register_netdev() is allowed be used without additional locks, as it's synchronized on rtnl_lock(). There are many examples of using this functon directly from ioctl(). The only difference, compared to ioctl(), is that net is not completely alive at this moment. But it looks like, there is no way for parallel pernet_operations to dereference the net_device, as the most of struct net_device lists, where it's linked, are related to net, and the net is not liked. The exceptions are net_device::unreg_list, close_list, todo_list, used for unregistration, and ::link_watch_list, where net_device may be linked to global lists. Unregistration of loopback_dev obviously can't happen, when loopback_net_init() is executing, as the net as alive. It occurs in default_device_ops, which currently requires net_mutex, and it behaves as a barrier at the moment. It will be considered in next patch. Speaking about link_watch_list, it seems, there is no way for loopback_dev at time of registration to be linked in lweventlist and be available for another pernet_operations. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by: Andrei Vagin <avagin@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller12-457/+769
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2018-02-12 This series contains updates to i40e and i40evf. Alan fixes a spelling mistake in code comments. Fixes an issue on older firmware versions or NPAR enabled PFs which do not support the I40E_FLAG_DISABLE_FW_LLDP flag and would get into a situation where any attempt to change any priv flag would be forbidden. Alex got busy with the ITR code and made several cleanups and fixes so that we can more easily understand what is going on. The fixes included a computational fix when determining the register offset, as well as a fix for unnecessarily toggling the CLEARPBA bit which could lead to potential lost events if auto-masking is not enabled. Filip adds a necessary delay to recover after a EMP reset when using firmware version 4.33. Paweł adds a warning message for MFP devices when the link-down-on-close flag is set because it may affect other partitions. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12i40e/i40evf: Add support for new mechanism of updating adaptive ITRAlexander Duyck8-257/+528
This patch replaces the existing mechanism for determining the correct value to program for adaptive ITR with yet another new and more complicated approach. The basic idea from a 30K foot view is that this new approach will push the Rx interrupt moderation up so that by default it starts in low latency and is gradually pushed up into a higher latency setup as long as doing so increases the number of packets processed, if the number of packets drops to 4 to 1 per packet we will reset and just base our ITR on the size of the packets being received. For Tx we leave it floating at a high interrupt delay and do not pull it down unless we start processing more than 112 packets per interrupt. If we start exceeding that we will cut our interrupt rates in half until we are back below 112. The side effect of these patches are that we will be processing more packets per interrupt. This is both a good and a bad thing as it means we will not be blocking processing in the case of things like pktgen and XDP, but we will also be consuming a bit more CPU in the cases of things such as network throughput tests using netperf. One delta from this versus the ixgbe version of the changes is that I have made the interrupt moderation a bit more aggressive when we are in bulk mode by moving our "goldilocks zone" up from 48 to 96 to 56 to 112. The main motivation behind moving this is to address the fact that we need to update less frequently, and have more fine grained control due to the separate Tx and Rx ITR times. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>