Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 11月, 2018 2 次提交
  3. 23 10月, 2018 1 次提交
  5. 11 10月, 2018 2 次提交
  7. 06 10月, 2018 1 次提交
  9. 29 9月, 2018 1 次提交
  11. 22 9月, 2018 5 次提交
  13. 20 9月, 2018 4 次提交
  15. 04 8月, 2018 1 次提交
  17. 07 7月, 2018 1 次提交
  19. 02 7月, 2018 2 次提交
  21. 29 6月, 2018 3 次提交
  23. 07 6月, 2018 1 次提交
  25. 06 6月, 2018 1 次提交
  27. 02 6月, 2018 3 次提交
  29. 29 5月, 2018 1 次提交
  31. 21 5月, 2018 1 次提交
  33. 16 5月, 2018 2 次提交
  35. 11 5月, 2018 1 次提交
  37. 23 3月, 2018 7 次提交
    • S
      net: hns3: Changes to support ARQ(Asynchronous Receive Queue) · 07a0556a
      由 Salil Mehta 提交于 
      Current mailbox CRQ could consists of both synchronous and async
responses from the PF. Synchronous responses are time critical
and should be handed over to the waiting tasks/context as quickly
as possible otherwise timeout occurs.

Above problem gets accentuated if CRQ consists of even single
async message. Hence, it is important to have quick handling of
synchronous messages and maybe deferred handling of async messages
This patch introduces separate ARQ(async receive queues) for the
async messages. These messages are processed later with repsect
to mailbox task while synchronous messages still gets processed
in context to mailbox interrupt.

ARQ is important as VF reset introduces some new async messages
like MBX_ASSERTING_RESET which adds up to the presssure on the
responses for synchronousmessages and they timeout even more
quickly.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07a0556a
    • S
      net: hns3: Add support to re-initialize the hclge device · 7a01c897
      由 Salil Mehta 提交于 
      After the hardware reset we should re-fetch the configuration from
PF like queue info and tc info. This might have impact on allocations
made like that of TQPs. Hence, we should release all such allocations
and re-allocate fresh according to new fetched configuration after
reset.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a01c897
    • S
      net: hns3: Add support to reset the enet/ring mgmt layer · 6988eb2a
      由 Salil Mehta 提交于 
      After VF driver knows that hardware reset has been performed
successfully, it should proceed ahead and reset the enet layer.
This primarily consists of bringing down interface, clearing
TX/RX rings, disassociating vectors from ring etc.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6988eb2a
    • S
      net: hns3: Add support to request VF Reset to PF · a8dedb65
      由 Salil Mehta 提交于 
      VF driver depends upon PF to eventually reset the hardware. This
request is made using the mailbox command. This patch adds the
required function to acheive above.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8dedb65
    • S
      net: hns3: Add VF Reset device state and its handling · 436667d2
      由 Salil Mehta 提交于 
      This introduces the hclge device reset states of "requested" and
"pending" and also its handling in context to Reset Service Task.

Device gets into requested state because of any VF reset request
asserted from upper layers, for example due to watchdog timeout
expiration. Requested state would result in eventually forwarding
the VF reset request to PF which would actually reset the VF.

Device will get into pending state if:
1. VF receives the acknowledgement from PF for the VF reset
   request it originally sent to PF.
2. Reset Service Task detects that after asserting VF reset for
   certain times the data-path is not working and device then
   decides to assert full VF reset(this means also resetting the
   PCIe interface).
3. PF intimates the VF that it has undergone reset.
Pending state would result in VF to poll for hardware reset
completion status and then resetting the stack/enet layer, which
in turn means reinitializing the ring management/enet layer.

Note: we would be adding support of 3. later as a separate patch.
This decision should not affect VF reset as its event handling
is generic in nature.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      436667d2
    • S
      net: hns3: Add VF Reset Service Task to support event handling · 35a1e503
      由 Salil Mehta 提交于 
      VF reset would involve handling of different reset related events
from the stack, physical function, mailbox etc. Reset service task
would be used in servicing such reset event requests and later
handling the hardware completions waits and initiating the stack
resets.
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35a1e503
    • S
      net: hns3: Changes to make enet watchdog timeout func common for PF/VF · 6d4c3981
      由 Salil Mehta 提交于 
      HNS3 drivers enet layer, used for the ring management and stack
interaction, is common to both VF and PF. PF already supports reset
functionality to handle the network stack watchdog timeout trigger
but the existing code is not generic enough to be used to support VF
reset as well.
This patch does following:
1. Makes the existing watchdog timeout handler in enet layer generic
   i.e. suitable for both VF and PF and
2. Introduces the new reset event handler for the VF code.
3. Changes existing reset event handler of PF code to initialize the
   reset level
Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d4c3981