1. 30 4月, 2017 2 次提交
    • J
      i40e: use DECLARE_BITMAP for state fields · 0da36b97
      Jacob Keller 提交于
      Instead of assuming our flags fit within an unsigned long, use
      DECLARE_BITMAP which will ensure that we always allocate enough space.
      Additionally, use __I40E_STATE_SIZE__ markers as the last element of the
      enumeration so that the size of the BITMAP is compile-time assigned
      rather than programmer-time assigned. This ensures that potential future
      flag additions do not actually overrun the array. This is especially
      important as 32bit systems would only have 32bit longs instead of 64bit
      longs as we generally have assumed in the prior code.
      
      This change also removes a dereference of the state fields throughout
      the code, so it does have a bit of code churn. The conversions were
      automated using sed replacements with an alternation
      
        s/&(vsi->back|vsi|pf)->state/\1->state/
        s/&adapter->vsi.state/adapter->vsi.state/
      
      For debugfs, we modify the printing so that we can display chunks of the
      state value on new lines. This ensures that we can print the entire set
      of state values. Additionally, we now print them as 08lx to ensure that
      they display nicely.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0da36b97
    • J
      i40e: separate PF and VSI state flags · d19cb64b
      Jacob Keller 提交于
      Avoid using the same named flags for both vsi->state and pf->state. This
      makes code review easier, as it is more likely that future authors will
      use the correct state field when checking bits. Previous commits already
      found issues with at least one check, and possibly others may be
      incorrect.
      
      This reduces confusion as it is more clear what each flag represents,
      and which flags are valid for which state field.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d19cb64b
  2. 20 4月, 2017 2 次提交
  3. 08 4月, 2017 1 次提交
  4. 29 3月, 2017 2 次提交
  5. 15 3月, 2017 1 次提交
  6. 12 2月, 2017 1 次提交
  7. 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
  8. 25 9月, 2016 1 次提交
  9. 20 8月, 2016 2 次提交
  10. 14 5月, 2016 1 次提交
  11. 06 5月, 2016 2 次提交
  12. 28 4月, 2016 1 次提交
  13. 27 4月, 2016 1 次提交
  14. 26 4月, 2016 1 次提交
  15. 18 2月, 2016 1 次提交
  16. 04 2月, 2016 1 次提交
    • M
      i40evf: allow channel bonding of VFs · 209dc4da
      Mitch Williams 提交于
      In some modes, bonding would not enslave VF interfaces. This is due to
      bonding calling change_mtu and the immediately calling open. Because of
      the asynchronous nature of the admin queue mechanism, the VF returns
      -EBUSY to the open call, because it knows the previous operation hasn't
      finished yet. This causes bonding to fail with a less-than-useful error
      message.
      
      To fix this, remove the check for pending operations at the beginning of
      open. But this introduces a new bug where the driver will panic on a
      quick close/open cycle. To fix that, we add a new driver state,
      __I40EVF_DOWN_PENDING, that the driver enters when down is called. The
      driver finally transitions to a fully DOWN state when it receives
      confirmation from the PF driver that all the queues are disabled. This
      allows open to complete even if there is a pending mtu change, and
      bonding is finally happy.
      
      Change-ID: I06f4c7e435d5bacbfceaa7c3f209e0ff04be21cc
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      209dc4da
  17. 03 12月, 2015 1 次提交
  18. 02 12月, 2015 5 次提交
  19. 20 10月, 2015 1 次提交
  20. 16 10月, 2015 2 次提交
    • M
      i40evf: relax and stagger init timing a bit · 3f7e5c33
      Mitch Williams 提交于
      On some devices, in some systems, in some configurations, the VFs would
      fail to initialize the first time you loaded the driver.
      
      To correct this, increase the delay time for the init task slightly, and
      wait longer before giving up.
      
      If we enable VFs and load the VF driver in the same kernel as the PF
      driver, we can totally overwhelm the PF driver with AQ requests because
      all of the instances try to initialize at the same time.
      
      To help alleviate this, stagger the initial scheduling of the init task
      using the PCIe function as a multiplier. We mask off the function to
      only three bits so no instance has to wait too long.
      
      With these two changes, initializing 128 VFs on a single device goes
      from four minutes to just a few seconds.
      
      Change-ID: If3d8720c1c4e838ab36d8781d9ec295a62380936
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3f7e5c33
    • A
      i40e/i40evf: Drop useless "IN_NETPOLL" flag · 8b650359
      Alexander Duyck 提交于
      The code in i40e and i40evf is using an "IN_NETPOLL" flag that has never
      added any value due to the fact that the Rx clean-up is handled in NAPI.
      As such the flag was set, the queue was scheduled via NAPI, and then polled
      from the netpoll controller and if any Rx packets were processed the were
      processed in the wrong context.
      
      In addition the flag itself just added an unneeded conditional to the
      hot-path so it can safely be dropped and save us a few instructions.
      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>
      8b650359
  21. 14 10月, 2015 1 次提交
  22. 09 10月, 2015 2 次提交
  23. 06 8月, 2015 3 次提交
  24. 23 7月, 2015 3 次提交
  25. 26 6月, 2015 1 次提交