1. 01 6月, 2021 2 次提交
  2. 25 5月, 2021 2 次提交
  3. 21 5月, 2021 1 次提交
  4. 15 5月, 2021 3 次提交
    • Jiaran Zhang's avatar
      net: hns3: refactor dump reset info of debugfs · 1a7ff828
      Jiaran Zhang 提交于
      Currently, the debugfs command for reset info is implemented by
      "echo xxxx > cmd", and record the information in dmesg. It's
      unnecessary and heavy. To improve it, create a single file
      "reset_info" for it, and query it by command "cat reset_info",
      return the result to userspace, rather than record in dmesg.
      
      The display style is below:
      $cat reset_info
      PF reset count: 0
      FLR reset count: 0
      GLOBAL reset count: 0
      IMP reset count: 0
      reset done count: 0
      HW reset done count: 0
      reset count: 0
      reset fail count: 0
      vector0 interrupt enable status: 0x1
      reset interrupt source: 0x0
      reset interrupt status: 0x0
      RAS interrupt status:0x0
      hardware reset status: 0x0
      handshake status: 0x80
      function reset status: 0x0
      
      Change to the "hclge_show_rst_info" in the "hclge_reset_err_handle",
      when the reset fails, display reset info immediately.
      Signed-off-by: Jiaran Zhang's avatarJiaran Zhang <zhangjiaran@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a7ff828
    • Y
      net: hns3: refactor the debugfs process · 5e69ea7e
      Yufeng Mo 提交于
      Currently, each debugfs command needs to create a file to get
      the information. To better support more debugfs commands, the
      debugfs process is reconstructed, including the process of
      creating dentries and files, and obtaining information.
      Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e69ea7e
    • H
      net: hns3: support RXD advanced layout · 79664077
      Huazhong Tan 提交于
      Currently, the driver gets packet type by parsing the
      L3_ID/L4_ID/OL3_ID/OL4_ID from RX descriptor, it's
      time-consuming.
      
      Now some new devices support RXD advanced layout, which combines
      previous OL3_ID/OL4_ID to 8bit ptype field, so the driver gets
      packet type by looking up only one table, and L3_ID/L4_ID become
      reserved fields.
      
      Considering compatibility, the firmware will report capability of
      RXD advanced layout, the driver will identify and enable it by
      default. This patch provides basic function: identify and enable
      the RXD advanced layout, and refactor out hns3_rx_checksum() by
      using ptype table to handle RX checksum if supported.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79664077
  5. 16 4月, 2021 1 次提交
  6. 30 3月, 2021 1 次提交
  7. 27 3月, 2021 1 次提交
  8. 23 3月, 2021 3 次提交
    • J
      net: hns3: add support for user-def data of flow director · 67b0e142
      Jian Shen 提交于
      For DEVICE_VERSION_V3, the hardware supports to match specified
      data in the specified offset of packet payload. Each layer can
      have one offset, and can't be masked when configure flow director
      rule by ethtool command. The layer is selected based on the
      flow-type, ether for L2, ip4/ipv6 for L3, and tcp4/tcp6/udp4/udp6
      for L4. For example, tcp4/tcp6/udp4/udp6 rules share the same
      user-def offset, but each rule can have its own user-def value.
      
      For the user-def field of ethtool -N/U command is 64 bits long.
      The bit 0~15 is used for user-def value, and bit 32~47 for user-def
      offset in HNS3 driver.
      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>
      67b0e142
    • J
      net: hns3: refactor flow director configuration · fc4243b8
      Jian Shen 提交于
      Currently, the flow director rule of aRFS is configured in
      the IO path. It's time-consuming. So move out the configuration,
      and configure it asynchronously. And keep ethtool and tc flower
      rule using synchronous way, otherwise the application maybe
      unable to know the rule is installed or pending.
      
      Add a state member for each flow director rule to indicate the
      rule state. There are 4 states:
      TO_ADD: the rule is waiting to add to hardware
      TO_DEL: the rule is waiting to remove from hardware
      DELETED: the rule has been removed from hardware. It's a middle
              state, used to remove the rule node in the fd_rule_list.
      ACTIVE: the rule is already added in hardware
      
      For asynchronous way, when receive a new request to add or delete
      flow director rule by aRFS, update the rule list, then request to
      schedule the service task to finish the configuration.
      
      For synchronous way, when receive a new request to add or delete
      flow director rule by ethtool or tc flower, configure hardware
      directly, then update the rule list if success.
      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>
      fc4243b8
    • J
      net: hns3: refactor for function hclge_fd_convert_tuple · fb72699d
      Jian Shen 提交于
      Currently, there are too many branches for hclge_fd_convert_tuple().
      And it may be more when add new tuples. Refactor it by sorting the
      tuples according to their length. So it only needs several KEY_OPT
      now, and being flexible to add new tuples.
      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>
      fb72699d
  9. 10 2月, 2021 2 次提交
  10. 07 2月, 2021 3 次提交
  11. 30 1月, 2021 1 次提交
  12. 06 1月, 2021 1 次提交
  13. 10 12月, 2020 3 次提交
  14. 09 12月, 2020 1 次提交
    • G
      net: hns3: refine the VLAN tag handle for port based VLAN · 592b0179
      Guojia Liao 提交于
      For DEVICE_VERSION_V2, the hardware only supports max two layer
      VLAN tags, including port based tag inserted by hardware, tag in
      tx buffer descriptor(get from skb->tci) and tag in packet.
      
      For transmit packet:
      If port based VLAN disabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the Outer_VLAN_TAG field
      (tag near to DMAC) of tx buffer descriptor, otherwise it may
      be inserted after the tag in packet.
      
      If port based VLAN enabled, and vf driver gets a VLAN tag from
      skb, the VLAN tag must be filled to the VLAN_TAG field (tag
      far to DMAC) of tx buffer descriptor, otherwise it may be
      conflicted with port based VLAN, and raise a hardware error.
      
      For receive packet:
      The hardware will strip the VLAN tags and fill them in the rx
      buffer descriptor, no matter port based VLAN enable or not.
      Because port based VLAN tag is useless for stack, so vf driver
      needs to discard the port based VLAN tag get from rx buffer
      descriptor when port based VLAN enabled.
      
      So vf must know about the port based VLAN state.
      
      For DEVICE_VERSION_V3, the hardware provides some new
      configuration to improve it.
      
      For transmit packet:
      When enable tag shift mode, hardware will handle the VLAN tag
      in outer_VLAN_TAG field as VLAN_TAG, so it won't conflict with
      port based VLAN. And hardware also make sure the tag before
      the tag in packet. So vf driver doesn't need to specify the tag
      position according to the port based VLAN state anymore.
      
      For receive packet:
      When enable discard mode, hardware will strip and discard the
      port based VLAN tag, so vf driver doesn't need to identify it
      from rx buffer descriptor.
      
      So modify the port based VLAN configuration, simplify the process
      for vf handling the VLAN tag.
      Signed-off-by: NGuojia Liao <liaoguojia@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      592b0179
  15. 22 11月, 2020 2 次提交
    • Y
      net: hns3: add support for pf querying new interrupt resources · 3a6863e4
      Yufeng Mo 提交于
      For HNAE3_DEVICE_VERSION_V3, a maximum of 1281 interrupt
      resources are supported. To utilize these new resources,
      extend the corresponding field or variable to 16bit type,
      and remove the restriction of NIC client that only use a
      maximum of 65 interrupt vectors. In addition, the I/O address
      of the extended interrupt resources are different, so an extra
      handler is needed.
      
      Currently, the total number of interrupts is the sum of RoCE's
      number and RoCE's offset (RoCE is in front of NIC), since
      the number of both NIC and RoCE are same. For readability,
      rewrite the corresponding field of the command, rename the
      RoCE's offset field as the number of NIC interrupts, then
      the total number of interrupts is sum of the number of RoCE
      and NIC, and replace vport->back with hdev in
      hclge_init_roce_base_info() for simplifying the code.
      Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      3a6863e4
    • H
      net: hns3: add support for mapping device memory · 30ae7f8a
      Huazhong Tan 提交于
      For device who has device memory accessed through the PCI BAR4,
      IO descriptor push of NIC and direct WQE(Work Queue Element) of
      RoCE will use this device memory, so add support for mapping
      this device memory, and add this info to the RoCE client whose
      new feature needs.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      30ae7f8a
  16. 25 9月, 2020 1 次提交
  17. 09 9月, 2020 2 次提交
  18. 22 7月, 2020 1 次提交
  19. 29 5月, 2020 1 次提交
  20. 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
  21. 21 4月, 2020 1 次提交
  22. 20 2月, 2020 1 次提交
  23. 21 1月, 2020 1 次提交
  24. 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