- 29 Feb, 2016 40 commits
-
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The X550EM_x revision check needs to check a value, not just a bit. Use a mask and check the value. Also remove the redundant check inside the ixgbe_enter_lplu_t_x550em, because it can only be called when both the mac type and revision check pass. Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 3ca2b250) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 X550 allows for up to 64 RSS queues, but the driver can have max of 63 (-1 MSIX vector for link). On systems with >= 64 CPUs the driver will set the redirection table for all 64 queues which will result in packets being dropped. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Clean up minor redundancy in the setting of hw_enc_features that makes it appears that X550 uniquely has more encapsulation features than other devices. The driver only supports one more feature, so make it look that way. No longer set NETIF_F_SG since that is set by the register_netdev call. Thanks to Alex Duyck for noticing this slight confusion. Reported-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Veola Nazareth authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Ethtool reports backplane type interfaces as 1000/10000baseT link modes. This has been corrected to report the media as KR, KX or KX4 based on the backplane interface present. Signed-off-by:
Veola Nazareth <veola.nazareth@intel.com> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Add missing QSFP PHY types to allow for more accurate reporting of port settings. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 adapter->rx_itr_setting is not a mask so check it with == instead of & do not default to 12K interrupts in ixgbevf_set_itr() There should be no functional effect from these changes. Signed-off-by:
-
William Dauchy authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This is the same patch as for ixgbe but applied differently according to busy polling. See commit 5d6002b7 ("ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector") Signed-off-by:
William Dauchy <william@gandi.net> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Some X550 devices can connect at 2.5Gbps during fail-over, but only with certain link partners. Also setting the advertised speed will not work so we do not report it as supported to avoid confusion. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch guarantees that the VFs do not have access to VLANs that they were not supposed to. What this patch does is add code so that we delete the previous port VLAN after adding a new one, and if we reset the VF we clear all of the filters associated with it. Previously the code was leaving all previous VLANs mapped to the VF and they didn't get deleted unless the VF specifically requested it or if the PF itself was reset. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch makes certain that we clear the pool mappings added when we configure default MAC addresses for the interface. Without this we run the risk of leaking an address into pool 0 which really belongs to VF 0 when SR-IOV is enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is a follow-on for enabling VLAN promiscuous and allowing the PF to add VLANs without adding a VLVF entry. What this patch does is go through and free the VLVF registers if they are not needed as the VLAN belongs only to the PF which is the default pool. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for VLAN promiscuous with SR-IOV enabled. The code prior to this patch was only adding the PF to VLANs that the VF had added. As such enabling promiscuous mode would actually not add any additional VLAN filters so visibility was limited. This lead to a number of issues as the bridge and OVS would expect us to accept all VLAN tagged packets when promiscuous mode was enabled, and instead we would filter out most if not all depending on the configuration of the PF. With this patch what we do is set all the bits in the VFTA and all of the VLVF bits associated with the pool belonging to the PF. By doing this the PF is guaranteed to receive all VLAN tagged traffic associated with the RAR filters assigned to the PF. In addition we will clean up those same bits in the event of promiscuous mode being disabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is meant to reduce the complexity of the search function used for finding a VLVF entry associated with a given VLAN ID. The previous code was searching from bottom to top. I reordered it to search from top to bottom. In addition I pulled an AND statement out of the loop and instead replaced it with an OR statement outside the loop. This should help to reduce the overall size and complexity of the function. There was also some formatting I cleaned up in regards to whitespace and such. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for bypassing the VLVF entry creation when the PF is adding a new VLAN. The advantage to doing this is that we can then save the VLVF entries for the VFs which must have them in order to function, versus the PF which can fall back on the default pool entry. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch addresses several issues within the VLVF and VLVFB configuration First was the fact that code was overly complicated with multiple conditional paths depending on if we adding or removing and which bit we were going to add or remove. Instead of messing with all that I have simplified it by using (vid / 32) and (1 - vid / 32) to identify our register and the other vlvfb register. Second was the fact that we were likely leaking a few packets into the PF in cases where we were deleting an entry and the VFTA filter for that entry as the ordering was such that we deleted the pool and then the VLAN filter instead of the other way around. I have updated that by adding a check for no bits being set and if that occurs we clear things up in the proper order. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In order to clear the way for upcoming work I thought it best to drop the level of indent in the ixgbe_set_vfta_generic function. Most of the code is held in the virtualization specific section. So the easiest approach is to just add a jump label and jump past the bulk of the code if it is not enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch simplifies the logic for setting the VFTA register by removing the number of conditional checks needed. Instead we just use some boolean logic to generate vfta_delta, and if that is set then we xor the vfta by that value and write it back. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The code for checking the PF bit in ixgbe_set_vf_vlan_msg was using the wrong offset and as a result it was pulling the VLAN off of the PF even if there were VFs numbered greater than 40 that still had the VLAN enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Add a check to make certain mac_table was actually allocated and is not NULL. If it is NULL return -ENOMEM and allow the probe routine to fail rather then causing a NULL pointer dereference further down the line. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check for and handle IPv6 extended headers so that Tx checksum offload can be done. Also use skb_checksum_help for unexpected cases. Thanks to Tom Herbert for noticing these problems. Thanks to Alexander Duyck for seeing how to coalesce the error handling into one location. Reported-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
Darin Miller <darin.j.miller@intel.com> Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Instead of inhibiting PHY power control when manageability is present, only inhibit turning PHY power off when manageability is present. Consequently, PHY power will always be turned on when requested. Without this patch, some systems with X540 or X550 devices in some conditions will never get link. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check for and handle IPv6 extended headers so that Tx checksum offload can be done. Also use skb_checksum_help for unexpected cases. Thanks to Tom Herbert for noticing these problems. Thanks to Alexander Duyck for recognizing problems with the first version of this patch and recognizing how to coalesce error conditions into a single location. Reported-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Save VF device pointers and take references to speed accesses used to monitor the device behavior to avoid slot resets. The saved information avoids lock contention during the search used to access each of the VFs. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 According to the datasheets, the driver should wait for the master disable bit to read as being set before checking the status register for master disable. Reported-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The ixgbe driver was violating the specification in the datasheet by not waiting 1ms before checking for the reset bit clearing. This is called out for devices supported by ixgbe, so implement the required delay. Reported-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The X550EM_x devices handle clocking differently, so update the PTP implementation to accommodate them. This involves significant changes to ixgbe's PTP code to accommodate the new range of behaviors including things like non-power-of-2 clock wrapping. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This change makes it so that we allow the PF to make use of all free RAR entries for FDB use if needed. Previously the code limited us to 16 unicast entries, however this was shared between MACVLAN which wasn't limited and the FDB code which was. So instead of treating the FDB code as a second class citizen I have updated it so that it has access to just as many entries as the MACVLAN filters. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This change replaces the ixgbe_write_uc_addr_list call in ixgbe_set_rx_mode with a call to __dev_uc_sync instead. This works much better with the MAC addr list code that was already in place and solves an issue in which you couldn't remove an FDB address without having to reset the port. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In the process of tracking down a memory leak when adding/removing FDB entries I had to go through the MAC address configuration code for ixgbe. In the process of doing so I found a number of issues that impacted readability and performance. This change updates the code in general to clean it up so it becomes clear what each step is doing. From what I can tell there a couple of bugs cleaned up in this code. First is the fact that the MAC addresses were being double counted for the PF. As a result once entries up to 63 had been used you could no longer add additional filters. A simple test case for this: for i in `seq 0 96` do ip link add link ens8 name mv$i type macvlan ip link set dev mv$i up done Test script: ethregs -s 0:8.0 | grep -e "RAH" | grep 8000....$ When things are working correctly RAL/H registers 1 - 97 will be consumed. In the failing case it will stop at 63 and prevent any further filters from being added. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Make some minor cleanups, such as simplifying return paths, deleting unneeded initializations, return values more directly and so forth. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Use a private workqueue to avoid hangs that were otherwise possible when performing stress tests, such as creating and destroying many VFS repeatedly. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Use a private workqueue to avoid hangs that were otherwise possible when performing stress tests, such as creating and destroying many VFS repeatedly. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The newer copper PHY implementation used with newer X550EM_x devices uses a different thermal alarm type than the earlier one. Make changes to support both types. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch removes KR PHY reset from ixgbe_init_phy_ops_x550em, since this function is meant to initialize function pointers for the detected PHY type. Internal PHY reset was moved to ixgbe_setup_internal_phy_t_x550em which will now detect which mode the internal PHY operates in and set it up as required. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 If ixgbevf is loaded while the corresponding PF interface is down and the driver assigns a random MAC address, that address can be overwritten with the value of hw->mac.perm_addr, which would be 0 at that point. To avoid this case we init hw->mac.perm_addr to the randomly generated address and do not set it unless we receive ACK from ixgbe. Reported-by:
John Greene <jogreene@redhat.com> Signed-off-by:
Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 replace some instances of memcpy for setting up the mac address with ether_addr_copy() Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Testing has now shown that the diagnostic code used with the CS4227 is no longer needed, so remove it. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The ixgbe_intr and ixgbe/ixgbevf_msix_clean_rings functions run from hard interrupt context or with interrupts already disabled in netpoll. They can use napi_schedule_irqoff() instead of napi_schedule() Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is the ixgbevf version of commit 8ac34f10 "ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K" The same logic applies here as well as the same results since a netperf test will starve for memory in the time from one Tx interrupt to the next. As a result the ixgbevf driver underperformed when compared to vhost_net. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 KR auto-neg mode is what we will be using going forward. The SW interface for this mode is different that what was used for iXFI. Signed-off-by:
-
