1. 01 11月, 2016 1 次提交
    • J
      i40e: drop is_vf and is_netdev fields in struct i40e_mac_filter · 1bc87e80
      Jacob Keller 提交于
      Originally the is_vf and is_netdev fields were added in order to
      distinguish between VF and netdev filters in a single VSI. However, it
      can be noted that we use separate VSI for SRIOV VFs and for netdev VSI.
      Thus, since a single VSI should only ever have one type of filter, we
      can simply remove the checks and remove the typing.
      
      In a similar fashion, we can note that the only remaining way to get
      multiple filters of a single type is through a debug command that was
      added to debugfs. This command is useless in practice, and results in
      causing bugs if we keep counter tracking but lose the is_vf and
      is_netdev protections as desired above.
      
      Since the only time we'd actually have a counter value besides 0 and
      1 is through use of this debugfs hook, we can remove this unnecessary
      command, and the entire counter logic it required.
      
      We vastly simplify mac filters by removing
      
      (a) the distinction between VF and netdev filters
      (b) counting logic
      (c) the ability to add and remove filters bypassing the stack via debugfs
      
      Change-ID: Idf916dd2a1159b1188ddbab5bef6b85ea6bf27d9
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1bc87e80
  2. 29 10月, 2016 1 次提交
    • A
      i40e: Clean up handling of msglevel flags and debug parameter · 5d4ca23e
      Alexander Duyck 提交于
      So the i40e driver had a really convoluted configuration for how to handle
      the debug flags contained in msg_level.  Part of the issue is that the
      driver has its own 32 bit mask that it was using to track a separate set of
      debug features.  From what I can tell it was trying to use the upper 4 bits
      to determine if the value was meant to represent a bit-mask or the numeric
      value provided by debug level.
      
      What this patch does is clean this up by compressing those 4 bits into bit
      31, as a result we just have to perform a check against the value being
      negative to determine if we are looking at a debug level (positive), or a
      debug mask (negative).  The debug level will populate the msg_level, and
      the debug mask will populate the debug_mask in the hardware struct.
      
      I added similar logic for ethtool.  If the value being provided has bit 31
      set we assume the value being provided is a debug mask, otherwise we assume
      it is a msg_enable mask.  For displaying we only provide the msg_enable,
      and if debug_mask is in use we will print it to the dmesg log.
      
      Lastly I removed the debugfs interface.  It is redundant with what we
      already have in ethtool and really doesn't belong anyway.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5d4ca23e
  3. 25 9月, 2016 1 次提交
  4. 23 9月, 2016 1 次提交
  5. 22 7月, 2016 1 次提交
    • M
      i40e: refactor Rx filter handling · c3c7ea27
      Mitch Williams 提交于
      Properly track filter adds and deletes so the driver doesn't lose filters
      during resets and up/down cycles. Add a tracking mechanism so that the
      driver knows when to enter and leave promiscuous mode.
      
      Implement a simple state machine so the driver can track the status of
      each filter throughout its lifecycle. Properly manage the overflow promiscuous
      state for the each VSI, and provide a way for the driver to detect when to exit
      overflow promiscuous mode.
      
      Remove all possible default MAC filters that the firmware may have set up so
      that the driver can manage these correctly, particularly when VLANs come into
      play. Remove the LAA flag for filters; instead just send whatever we get through
      set_mac to the firmware as the LAA for wakeup purposes.
      
      Finally, add the state of each filter to debugfs output so we can see what's
      going on inside the driver's pointy little head.
      
      Change-ID: I97c5e366fac2254fa01eaff4f65c0af61dcf2e1f
      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>
      c3c7ea27
  6. 06 5月, 2016 4 次提交
  7. 06 4月, 2016 1 次提交
  8. 20 2月, 2016 1 次提交
  9. 18 2月, 2016 6 次提交
  10. 17 2月, 2016 1 次提交
  11. 02 12月, 2015 1 次提交
  12. 24 11月, 2015 1 次提交
  13. 23 10月, 2015 1 次提交
  14. 15 10月, 2015 1 次提交
  15. 09 10月, 2015 1 次提交
  16. 30 9月, 2015 2 次提交
  17. 29 9月, 2015 1 次提交
    • A
      i40e: Fix for recursive RTNL lock during PROMISC change · 30e2561b
      Anjali Singhai 提交于
      The sync_vsi_filters function can be called directly under RTNL
      or through the timer subtask without one. This was causing a deadlock.
      
      If sync_vsi_filters is called from a thread which held the lock,
      and in another thread the PROMISC setting got changed we would
      be executing the PROMISC change in the thread which already held
      the lock alongside the other filter update. The PROMISC change
      requires a reset if we are on a VEB, which requires it to be called
      under RTNL.
      
      Earlier the driver would call reset for PROMISC change without
      checking if we were already under RTNL and would try to grab it
      causing a deadlock. This patch changes the flow to see if we are
      already under RTNL before trying to grab it.
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NKiran Patil <kiran.patil@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      30e2561b
  18. 23 7月, 2015 1 次提交
  19. 05 6月, 2015 1 次提交
    • A
      i40e: start up in VEPA mode by default · fc60861e
      Anjali Singhai Jain 提交于
      The patch fixes a bug in the default configuration which
      prevented a software bridge loaded on the PF interface from
      working correctly because broadcast packets are incorrectly
      looped back.
      
      Fix the general case, by loading the driver in VEPA mode Until a
      VF or VMDq VSI is added. This way loopback on the Main VSI is
      turned off until needed and can resolve the issue of unnecessary
      reflection for users that do not have VF or VMDq VSIs setup.
      
      The driver must now coordinate the loopback setting for the Flow
      Director (FDIR) VSI to make sure it is in sync with the current
      VEB or VEPA mode setting.
      
      The user can still switch bridge modes from the bridge commands and
      choose to be in VEPA mode with VF VSIs. Because of hardware
      requirements, the call to switch to VEB mode when no VF/VMDqs are
      present will be rejected.
      
      NOTE: This patch uses BIT_ULL as that is preferred going forward,
      a followup patch in the lower priority queue to net-next will fix
      up the remaining 1 << usages.
      
      Change-ID: Ib121ddb18fe4b3c4f52e9deda6fcbeb9105683d1
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc60861e
  20. 15 4月, 2015 1 次提交
  21. 10 3月, 2015 1 次提交
  22. 09 3月, 2015 2 次提交
  23. 26 2月, 2015 1 次提交
  24. 25 2月, 2015 1 次提交
    • N
      i40e: Add support for getlink, setlink ndo ops · 51616018
      Neerav Parikh 提交于
      Add support for bridge offload ndo_ops getlink and setlink to
      enable bridge hardware mode as per the mode set via IFLA_BRIDGE_MODE.
      The support is only enabled in case of a PF VSI and not available for
      any other VSI type.
      
      By default the i40e driver inserts a bridge as part of the bring-up
      when a FDIR type VSI and/or a FCoE VSI is created. This bridge is
      created in VEB mode by default i.e. after creating the bridge using
      "Add VEB" AQ command the loopback for the PF's default VSI is enabled.
      
      The patch adds capability where all the VSIs created as downlink to
      the bridge inherits the loopback property and enables loopback only
      if the uplink bridge is operating in VEB mode.
      Hence, there is no need to explicitly enable loopback as part of
      allocating resources for SR-IOV VFs and call to do that has been
      removed.
      
      In case a user-request is made either via "bridge" utility or using
      the bridge netlink interface that requires to change the hardware
      bridge mode then that would require a PF reset and rebuild of the
      switch hierarchy.
      
      Also update the copyright year.
      
      Change-ID: I4d78fc1c83158efda29ba7be92239b74f75d6d25
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      51616018
  25. 24 2月, 2015 1 次提交
  26. 16 1月, 2015 1 次提交
  27. 01 1月, 2015 1 次提交
  28. 06 12月, 2014 2 次提交
  29. 18 11月, 2014 1 次提交