1. 06 3月, 2018 3 次提交
  2. 28 2月, 2018 3 次提交
  3. 27 2月, 2018 20 次提交
  4. 15 2月, 2018 9 次提交
  5. 14 2月, 2018 5 次提交
    • H
      i40evf: Make VF reset warning message more clear · 693acdd0
      Harshitha Ramamurthy 提交于
      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: NHarshitha Ramamurthy <harshitha.ramamurthy@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      693acdd0
    • J
      i40evf: use __dev_[um]c_sync routines in .set_rx_mode · 8946b563
      Jacob Keller 提交于
      Similar to changes done to the PF driver in commit 6622f5cd ("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: 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>
      8946b563
    • D
      i40e: i40e: Change ethtool check from MAC to HW flag · 7b63435a
      Dave Ertman 提交于
      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: NDave Ertman <david.m.ertman@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7b63435a
    • A
      i40e: do not force filter failure in overflow promiscuous · 7363115e
      Alan Brady 提交于
      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: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7363115e
    • A
      i40e: refactor promisc_changed in i40e_sync_vsi_filters · cc6a96a4
      Alan Brady 提交于
      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: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cc6a96a4