Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 7月, 2020 1 次提交
  3. 29 5月, 2020 1 次提交
  5. 26 4月, 2020 4 次提交
    • J
      net: hns3: optimize the filter table entries handling when resetting · 039ba863
      由 Jian Shen 提交于 
      Currently, the PF driver removes all (including its VFs') MAC/VLAN
flow director table entries when resetting, and restores them after
reset completed.

In fact, the hardware will clear all table entries only in IMP
reset and global reset. So driver only needs to restore the table
entries in these cases, and needs do nothing when PF reset, FLR
or other function level reset.

This patch optimizes it by removing unnecessary table entries clear
and restoring handling in the reset flow, and doing the restoring
after reset completed.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      039ba863
    • J
      net: hns3: use mutex vport_lock instead of mutex umv_lock · 7d0b3451
      由 Jian Shen 提交于 
      Currently, the driver use mutex umv_lock to protect the variable
vport->share_umv_size. And there is already a mutex vport_lock
being defined in the driver, which is designed to protect the
resource of vport. So we can use vport_lock instead of umv_lock.

Furthermore, there is a time window for protect share_umv_size
between checking UMV space and doing MAC configuration in the
lin function hclge_add_uc_addr_common(). It should be extended.

This patch uses mutex vport_lock intead of spin lock umv_lock to
protect share_umv_size, and adjusts the mutex's range.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d0b3451
    • J
      net: hns3: refactor the promisc mode setting · c631c696
      由 Jian Shen 提交于 
      As the HNS3 driver doesn't update the MAC address directly in
function hns3_set_rx_mode() now, it can't know whether the
MAC table is full from __dev_uc_sync() and __dev_mc_sync(),
so it's senseless to handle the overflow promisc here.

This patch removes the handle of overflow promisc from function
hns3_set_rx_mode(), and updates the promisc mode in the service
task.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c631c696
    • J
      net: hns3: refactor the MAC address configure · ee4bcd3b
      由 Jian Shen 提交于 
      Currently, the HNS3 driver sync and unsync MAC address in function
hns3_set_rx_mode(). For PF, it adds and deletes MAC address directly
in the path of dev_set_rx_mode(). If failed, it won't retry until
next calling of hns3_set_rx_mode(). On the other hand, if request
add and remove a same address many times at a short interval, each
request must be done one by one, can't be merged. For VF, it sends
mailbox messages to PF to request adding or deleting MAC address in
the path of function hns3_set_rx_mode(), no matter the address is
configured success.

This patch refines it by recording the MAC address in function
hns3_set_rx_mode(), and updating MAC address in the service task.
If failed, it will retry by the next calling of periodical service
task. It also uses some state to mark the state of each MAC address
in the MAC list, which can help merge configure request for a same
address. With these changes, when global reset or IMP reset occurs,
we can restore the MAC table with the MAC list.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee4bcd3b
  7. 21 4月, 2020 1 次提交
  9. 20 2月, 2020 1 次提交
  11. 21 1月, 2020 1 次提交
  13. 12 1月, 2020 1 次提交
    • H
      net: hns3: refactor the precedure of PF FLR · 8627bded
      由 Huazhong Tan 提交于 
      Currently, the actual work of PF FLR is handled in the reset task,
which is asynchronous. So in some case, if the preparing and
rebuilding are not done, then the PF FLR will trigger some problems,
for example, makes hardware go into chaos.

So this patch separates the process of PF FLR from reset task, and
adds a semaphore to serialize this reset and others.

When FLR's preparing fails, if there has other higher level reset
pending or failing times less than the HCLGE_FLR_RETRY_CNT, this
preparing should be retried, otherwise PF and its VF may get into
wrong state.

BTW, while the hardware reports misc interrupt during pcie_flr(),
the driver can not receive this interrupt anymore, so disable it
when hclge_flr_prepare() return, and re-enable it when enter
hclge_flr_done().
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8627bded
  15. 21 12月, 2019 1 次提交
  17. 17 12月, 2019 2 次提交
  19. 20 11月, 2019 1 次提交
  21. 06 11月, 2019 2 次提交
  23. 01 11月, 2019 2 次提交
  25. 20 10月, 2019 1 次提交
  27. 09 10月, 2019 4 次提交
  29. 11 9月, 2019 1 次提交
  31. 30 8月, 2019 4 次提交
  33. 25 8月, 2019 1 次提交
  35. 19 8月, 2019 1 次提交
  37. 10 8月, 2019 1 次提交
  39. 02 8月, 2019 1 次提交
  41. 29 7月, 2019 2 次提交
  43. 26 6月, 2019 2 次提交
  45. 15 6月, 2019 1 次提交
  47. 10 6月, 2019 2 次提交
  49. 04 6月, 2019 1 次提交