1. 29 10月, 2016 1 次提交
    • A
      i40e/i40evf: fix interrupt affinity bug · 96db776a
      Alan Brady 提交于
      There exists a bug in which a 'perfect storm' can occur and cause
      interrupts to fail to be correctly affinitized. This causes unexpected
      behavior and has a substantial impact on performance when it happens.
      
      The bug occurs if there is heavy traffic, any number of CPUs that have
      an i40e interrupt are pegged at 100%, and the interrupt afffinity for
      those CPUs is changed.  Instead of moving to the new CPU, the interrupt
      continues to be polled while there is heavy traffic.
      
      The bug is most readily realized as the driver is first brought up and
      all interrupts start on CPU0. If there is heavy traffic and the
      interrupt starts polling before the interrupt is affinitized, the
      interrupt will be stuck on CPU0 until traffic stops. The bug, however,
      can also be wrought out more simply by affinitizing all the interrupts
      to a single CPU and then attempting to move any of those interrupts off
      while there is heavy traffic.
      
      This patch fixes the bug by registering for update notifications from
      the kernel when the interrupt affinity changes. When that fires, we
      cache the intended affinity mask. Then, while polling, if the cpu is
      pegged at 100% and we failed to clean the rings, we check to make sure
      we have the correct affinity and stop polling if we're firing on the
      wrong CPU.  When the kernel successfully moves the interrupt, it will
      start polling on the correct CPU. The performance impact is minimal
      since the only time this section gets executed is when performance is
      already compromised by the CPU.
      
      Change-ID: I4410a880159b9dba1f8297aa72bef36dca34e830
      Signed-off-by: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      96db776a
  2. 18 10月, 2016 1 次提交
    • J
      ethernet/intel: use core min/max MTU checking · 91c527a5
      Jarod Wilson 提交于
      e100: min_mtu 68, max_mtu 1500
      - remove e100_change_mtu entirely, is identical to old eth_change_mtu,
        and no longer serves a purpose. No need to set min_mtu or max_mtu
        explicitly, as ether_setup() will already set them to 68 and 1500.
      
      e1000: min_mtu 46, max_mtu 16110
      
      e1000e: min_mtu 68, max_mtu varies based on adapter
      
      fm10k: min_mtu 68, max_mtu 15342
      - remove fm10k_change_mtu entirely, does nothing now
      
      i40e: min_mtu 68, max_mtu 9706
      
      i40evf: min_mtu 68, max_mtu 9706
      
      igb: min_mtu 68, max_mtu 9216
      - There are two different "max" frame sizes claimed and both checked in
        the driver, the larger value wasn't relevant though, so I've set max_mtu
        to the smaller of the two values here to retain identical behavior.
      
      igbvf: min_mtu 68, max_mtu 9216
      - Same issue as igb duplicated
      
      ixgb: min_mtu 68, max_mtu 16114
      - Also remove pointless old == new check, as that's done in dev_set_mtu
      
      ixgbe: min_mtu 68, max_mtu 9710
      
      ixgbevf: min_mtu 68, max_mtu dependent on hardware/firmware
      - Some hw can only handle up to max_mtu 1504 on a vf, others 9710
      
      CC: netdev@vger.kernel.org
      CC: intel-wired-lan@lists.osuosl.org
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91c527a5
  3. 25 9月, 2016 3 次提交
  4. 23 9月, 2016 3 次提交
  5. 20 8月, 2016 2 次提交
  6. 19 8月, 2016 2 次提交
  7. 22 7月, 2016 2 次提交
  8. 28 6月, 2016 2 次提交
  9. 21 5月, 2016 2 次提交
  10. 14 5月, 2016 1 次提交
  11. 06 5月, 2016 3 次提交
  12. 02 5月, 2016 2 次提交
  13. 28 4月, 2016 1 次提交
  14. 27 4月, 2016 1 次提交
  15. 26 4月, 2016 2 次提交
    • A
      i40e/i40evf: Add support for IPIP and SIT offloads · 577389a5
      Alexander Duyck 提交于
      Looking over the documentation it turns out enabling IPIP and SIT offloads
      for i40e is pretty straightforward.  As such I decided to enable them with
      this patch.  In my testing I am seeing an improvement of 8 to 10 Gb/s
      for IPIP and SIT tunnels with this offload enabled.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      577389a5
    • A
      i40e/i40evf: Clean up feature flags · b0fe3306
      Alexander Duyck 提交于
      The feature flags list for i40e and i40evf is beginning to become pretty
      massive.  I plan to add another 4 or so features to these drivers and
      duplicating the flags for each and every flags list is becoming a bit
      repetitive.
      
      The primary change here is that we now build our features list around
      hw_encap_features.  After that we assign that to vlan_features,
      hw_features, and finally map that onto features.  In addition we end up
      throwing features onto hw_encap_features that end up having no effect such
      as the Rx offloads and SCTP_CRC.  However that should have no impact and
      makes things a bit easier for us as hw_encap_features is one of the less
      updated features maps available.
      
      For i40evf I went through and sanity checked a few features as well.
      Specifically RXCSUM was being set as a read-only feature which didn't make
      much sense.  I have updated things so we can clear the NETIF_F_RXCSUM flag
      since that is really a software feature and not a hardware one anyway so
      disabling it is just a matter of ignoring the result from the hardware.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b0fe3306
  16. 07 4月, 2016 2 次提交
  17. 06 4月, 2016 6 次提交
  18. 05 4月, 2016 1 次提交
  19. 19 2月, 2016 2 次提交
  20. 18 2月, 2016 1 次提交