1. 05 Jun, 2015 1 commit
    • Anjali Singhai Jain's avatar
      i40e: start up in VEPA mode by default · fc60861e
      Anjali Singhai Jain authored
      
      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: default avatarAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: default avatarJim Young <james.m.young@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc60861e
  2. 15 Apr, 2015 1 commit
  3. 09 Mar, 2015 3 commits
  4. 26 Feb, 2015 1 commit
  5. 25 Feb, 2015 1 commit
    • Neerav Parikh's avatar
      i40e: Add support for getlink, setlink ndo ops · 51616018
      Neerav Parikh authored
      
      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: default avatarNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: default avatarJim Young <james.m.young@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      51616018
  6. 24 Feb, 2015 1 commit
  7. 16 Jan, 2015 1 commit
  8. 31 Dec, 2014 1 commit
  9. 06 Dec, 2014 2 commits
  10. 18 Nov, 2014 1 commit
  11. 03 Nov, 2014 1 commit
  12. 27 Aug, 2014 1 commit
  13. 03 Aug, 2014 1 commit
  14. 24 Jul, 2014 1 commit
  15. 26 Jun, 2014 1 commit
  16. 20 Jun, 2014 1 commit
  17. 09 Jun, 2014 1 commit
    • Mitch Williams's avatar
      i40e: allow for more VSIs · 505682cd
      Mitch Williams authored
      
      The number of VSIs that the firmware reports to us is a guaranteed
      minimum, not an absolute maximum. The hardware actually supports far
      more  than the reported value, which we often need.
      
      To allow for this, we allocate space for a larger number of VSIs than is
      guaranteed by the firmware, with the knowledge that we may fail to get
      them all in the future.
      
      Note that we are just allocating pointers here, the actual (much larger)
      VSI structures are allocated on demand.
      
      Change-ID: I6f4e535ce39d3bf417aef78306e04fbc7505140e
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      505682cd
  18. 05 Jun, 2014 1 commit
  19. 28 Apr, 2014 1 commit
  20. 28 Mar, 2014 1 commit
  21. 14 Mar, 2014 2 commits
  22. 07 Mar, 2014 1 commit
  23. 18 Jan, 2014 2 commits
  24. 17 Jan, 2014 1 commit
  25. 11 Jan, 2014 1 commit
  26. 09 Jan, 2014 2 commits
  27. 08 Jan, 2014 1 commit
  28. 06 Jan, 2014 1 commit
  29. 05 Jan, 2014 2 commits
  30. 18 Dec, 2013 4 commits