Skip to content

cloud-kernel
cloud-kernel

_Walt / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 18 2月, 2016 1 次提交
  3. 17 2月, 2016 1 次提交
  5. 02 12月, 2015 1 次提交
  7. 24 11月, 2015 1 次提交
  9. 23 10月, 2015 1 次提交
  11. 15 10月, 2015 1 次提交
  13. 09 10月, 2015 1 次提交
  15. 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
  19. 23 7月, 2015 1 次提交
  21. 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
  23. 15 4月, 2015 1 次提交
  25. 10 3月, 2015 1 次提交
  27. 09 3月, 2015 2 次提交
  29. 26 2月, 2015 1 次提交
  31. 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
  33. 24 2月, 2015 1 次提交
  35. 16 1月, 2015 1 次提交
  37. 01 1月, 2015 1 次提交
  39. 06 12月, 2014 2 次提交
  41. 18 11月, 2014 1 次提交
  43. 03 11月, 2014 1 次提交
  45. 27 8月, 2014 1 次提交
  47. 03 8月, 2014 1 次提交
  49. 24 7月, 2014 1 次提交
  51. 26 6月, 2014 1 次提交
  53. 20 6月, 2014 1 次提交
  55. 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
  57. 05 6月, 2014 1 次提交
  59. 28 4月, 2014 1 次提交
  61. 28 3月, 2014 1 次提交
  63. 15 3月, 2014 2 次提交
  65. 07 3月, 2014 1 次提交
  67. 18 1月, 2014 2 次提交
  69. 17 1月, 2014 1 次提交