1. 10 3月, 2015 1 次提交
  2. 09 3月, 2015 2 次提交
  3. 26 2月, 2015 1 次提交
  4. 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
  5. 24 2月, 2015 1 次提交
  6. 16 1月, 2015 1 次提交
  7. 01 1月, 2015 1 次提交
  8. 06 12月, 2014 2 次提交
  9. 18 11月, 2014 1 次提交
  10. 03 11月, 2014 1 次提交
  11. 27 8月, 2014 1 次提交
  12. 03 8月, 2014 1 次提交
  13. 24 7月, 2014 1 次提交
  14. 26 6月, 2014 1 次提交
  15. 20 6月, 2014 1 次提交
  16. 09 6月, 2014 1 次提交
    • M
      i40e: allow for more VSIs · 505682cd
      Mitch Williams 提交于
      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: NMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      505682cd
  17. 05 6月, 2014 1 次提交
  18. 28 4月, 2014 1 次提交
  19. 28 3月, 2014 1 次提交
  20. 15 3月, 2014 2 次提交
  21. 07 3月, 2014 1 次提交
  22. 18 1月, 2014 2 次提交
  23. 17 1月, 2014 1 次提交
  24. 11 1月, 2014 1 次提交
  25. 09 1月, 2014 2 次提交
  26. 08 1月, 2014 1 次提交
  27. 06 1月, 2014 1 次提交
  28. 05 1月, 2014 2 次提交
  29. 18 12月, 2013 6 次提交