2019-09-26 14:02:00 +00:00
|
|
|
/* SPDX-License-Identifier: BSD-3-Clause
|
2021-04-07 09:19:13 +00:00
|
|
|
* Copyright(c) 2018-2021 HiSilicon Limited.
|
2019-09-26 14:02:00 +00:00
|
|
|
*/
|
|
|
|
|
|
2021-01-29 16:48:19 +00:00
|
|
|
#include <ethdev_driver.h>
|
2019-09-26 14:02:00 +00:00
|
|
|
#include <rte_io.h>
|
|
|
|
|
|
|
|
|
|
#include "hns3_ethdev.h"
|
|
|
|
|
#include "hns3_regs.h"
|
|
|
|
|
#include "hns3_logs.h"
|
2019-09-26 14:02:05 +00:00
|
|
|
#include "hns3_intr.h"
|
net/hns3: support setting VF PVID by PF driver
This patch adds support setting VF PVID by hns3 PF kernel ethdev driver
on the host by "ip link set <eth num> vf <vf id> vlan <vlan tag>"
command.
Because of the hardware constraints, the striped VLAN tag will always in
Rx descriptors which should has been dropped when PVID is enabled and
the PVID will overwrite the outer VLAN tag in Tx descriptor. So, hns3
PMD driver need to change the processing of VLAN tags in the process of
Tx and Rx according to whether PVID is enabled.
1) If the hns3 PF kernel ethdev driver sets the PVID for VF device
before the initialization of the related VF device, hns3 VF PMD
driver should get the PVID state from PF driver through mailbox and
update the related state in txq and rxq maintained by hns3 VF driver
to change the process of Tx and Rx.
2) If the hns3 PF kernel ethdev driver sets the PVID for VF device after
initialization of the related VF device, the PF driver will notify VF
driver to update the PVID state. The VF driver will update the PVID
configuration state immediately to ensure that the VLAN process in Tx
and Rx is correct. But in the window period of this state transition,
packets loss or packets with wrong VLAN may occur.
3) Due to hardware limitations, we only support two-layer VLAN hardware
offload in Tx direction based on hns3 network engine, so when PVID is
enabled, QinQ insert is no longer supported. And when PVID is
enabled, in the following two cases:
i) packets with more than two VLAN tags.
ii) packets with one VLAN tag while the hardware VLAN insert is
enabled.
The packets will be regarded as abnormal packets and discarded by
hardware in Tx direction. For debugging purposes, a validation check
for these types of packets is added to the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts to inform users that
these packets will be discarded.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
2020-07-01 11:54:36 +00:00
|
|
|
#include "hns3_rxtx.h"
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
#define HNS3_CMD_CODE_OFFSET 2
|
|
|
|
|
|
|
|
|
|
static const struct errno_respcode_map err_code_map[] = {
|
|
|
|
|
{0, 0},
|
|
|
|
|
{1, -EPERM},
|
|
|
|
|
{2, -ENOENT},
|
|
|
|
|
{5, -EIO},
|
|
|
|
|
{11, -EAGAIN},
|
|
|
|
|
{12, -ENOMEM},
|
|
|
|
|
{16, -EBUSY},
|
|
|
|
|
{22, -EINVAL},
|
|
|
|
|
{28, -ENOSPC},
|
|
|
|
|
{95, -EOPNOTSUPP},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
hns3_resp_to_errno(uint16_t resp_code)
|
|
|
|
|
{
|
|
|
|
|
uint32_t i, num;
|
|
|
|
|
|
|
|
|
|
num = sizeof(err_code_map) / sizeof(struct errno_respcode_map);
|
|
|
|
|
for (i = 0; i < num; i++) {
|
|
|
|
|
if (err_code_map[i].resp_code == resp_code)
|
|
|
|
|
return err_code_map[i].err_no;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
static void
|
|
|
|
|
hns3_mbx_proc_timeout(struct hns3_hw *hw, uint16_t code, uint16_t subcode)
|
|
|
|
|
{
|
|
|
|
|
if (hw->mbx_resp.matching_scheme ==
|
|
|
|
|
HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL) {
|
|
|
|
|
hw->mbx_resp.lost++;
|
|
|
|
|
hns3_err(hw,
|
|
|
|
|
"VF could not get mbx(%u,%u) head(%u) tail(%u) "
|
|
|
|
|
"lost(%u) from PF",
|
|
|
|
|
code, subcode, hw->mbx_resp.head, hw->mbx_resp.tail,
|
|
|
|
|
hw->mbx_resp.lost);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hns3_err(hw, "VF could not get mbx(%u,%u) from PF", code, subcode);
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-26 14:02:00 +00:00
|
|
|
static int
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
|
2019-09-26 14:02:00 +00:00
|
|
|
uint8_t *resp_data, uint16_t resp_len)
|
|
|
|
|
{
|
2021-04-13 11:50:03 +00:00
|
|
|
#define HNS3_MAX_RETRY_US 500000
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
#define HNS3_WAIT_RESP_US 100
|
2019-09-26 14:02:07 +00:00
|
|
|
struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
|
2019-09-26 14:02:00 +00:00
|
|
|
struct hns3_mbx_resp_status *mbx_resp;
|
2021-04-13 11:50:03 +00:00
|
|
|
uint32_t wait_time = 0;
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
bool received;
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
if (resp_len > HNS3_MBX_MAX_RESP_DATA_SIZE) {
|
2020-11-09 14:28:57 +00:00
|
|
|
hns3_err(hw, "VF mbx response len(=%u) exceeds maximum(=%d)",
|
2019-09-26 14:02:00 +00:00
|
|
|
resp_len, HNS3_MBX_MAX_RESP_DATA_SIZE);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-13 11:50:03 +00:00
|
|
|
while (wait_time < HNS3_MAX_RETRY_US) {
|
2021-02-03 12:23:53 +00:00
|
|
|
if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
|
2019-09-26 14:02:07 +00:00
|
|
|
hns3_err(hw, "Don't wait for mbx respone because of "
|
|
|
|
|
"disable_cmd");
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_reset_pending(hns)) {
|
|
|
|
|
hw->mbx_resp.req_msg_data = 0;
|
|
|
|
|
hns3_err(hw, "Don't wait for mbx respone because of "
|
|
|
|
|
"reset pending");
|
|
|
|
|
return -EIO;
|
|
|
|
|
}
|
|
|
|
|
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
hns3_dev_handle_mbx_msg(hw);
|
|
|
|
|
rte_delay_us(HNS3_WAIT_RESP_US);
|
|
|
|
|
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
if (hw->mbx_resp.matching_scheme ==
|
|
|
|
|
HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL)
|
|
|
|
|
received = (hw->mbx_resp.head ==
|
|
|
|
|
hw->mbx_resp.tail + hw->mbx_resp.lost);
|
|
|
|
|
else
|
|
|
|
|
received = hw->mbx_resp.received_match_resp;
|
|
|
|
|
if (received)
|
|
|
|
|
break;
|
|
|
|
|
|
2021-04-13 11:50:03 +00:00
|
|
|
wait_time += HNS3_WAIT_RESP_US;
|
2019-09-26 14:02:00 +00:00
|
|
|
}
|
|
|
|
|
hw->mbx_resp.req_msg_data = 0;
|
2021-04-13 11:50:03 +00:00
|
|
|
if (wait_time >= HNS3_MAX_RETRY_US) {
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
hns3_mbx_proc_timeout(hw, code, subcode);
|
2019-09-26 14:02:00 +00:00
|
|
|
return -ETIME;
|
|
|
|
|
}
|
|
|
|
|
rte_io_rmb();
|
|
|
|
|
mbx_resp = &hw->mbx_resp;
|
|
|
|
|
|
|
|
|
|
if (mbx_resp->resp_status)
|
|
|
|
|
return mbx_resp->resp_status;
|
|
|
|
|
|
|
|
|
|
if (resp_data)
|
|
|
|
|
memcpy(resp_data, &mbx_resp->additional_info[0], resp_len);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
static void
|
|
|
|
|
hns3_mbx_prepare_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Init both matching scheme fields because we may not know the exact
|
|
|
|
|
* scheme will be used when in the initial phase.
|
|
|
|
|
*
|
|
|
|
|
* Also, there are OK to init both matching scheme fields even though
|
|
|
|
|
* we get the exact scheme which is used.
|
|
|
|
|
*/
|
|
|
|
|
hw->mbx_resp.req_msg_data = (uint32_t)code << 16 | subcode;
|
|
|
|
|
hw->mbx_resp.head++;
|
|
|
|
|
|
|
|
|
|
/* Update match_id and ensure the value of match_id is not zero */
|
|
|
|
|
hw->mbx_resp.match_id++;
|
|
|
|
|
if (hw->mbx_resp.match_id == 0)
|
|
|
|
|
hw->mbx_resp.match_id = 1;
|
|
|
|
|
hw->mbx_resp.received_match_resp = false;
|
|
|
|
|
|
|
|
|
|
hw->mbx_resp.resp_status = 0;
|
|
|
|
|
memset(hw->mbx_resp.additional_info, 0, HNS3_MBX_MAX_RESP_DATA_SIZE);
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-26 14:02:00 +00:00
|
|
|
int
|
|
|
|
|
hns3_send_mbx_msg(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
|
|
|
|
|
const uint8_t *msg_data, uint8_t msg_len, bool need_resp,
|
|
|
|
|
uint8_t *resp_data, uint16_t resp_len)
|
|
|
|
|
{
|
|
|
|
|
struct hns3_mbx_vf_to_pf_cmd *req;
|
|
|
|
|
struct hns3_cmd_desc desc;
|
2020-01-09 03:15:56 +00:00
|
|
|
bool is_ring_vector_msg;
|
|
|
|
|
int offset;
|
2019-09-26 14:02:00 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
req = (struct hns3_mbx_vf_to_pf_cmd *)desc.data;
|
|
|
|
|
|
|
|
|
|
/* first two bytes are reserved for code & subcode */
|
|
|
|
|
if (msg_len > (HNS3_MBX_MAX_MSG_SIZE - HNS3_CMD_CODE_OFFSET)) {
|
|
|
|
|
hns3_err(hw,
|
2020-11-09 14:28:57 +00:00
|
|
|
"VF send mbx msg fail, msg len %u exceeds max payload len %d",
|
2019-09-26 14:02:00 +00:00
|
|
|
msg_len, HNS3_MBX_MAX_MSG_SIZE - HNS3_CMD_CODE_OFFSET);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_MBX_VF_TO_PF, false);
|
|
|
|
|
req->msg[0] = code;
|
2020-01-09 03:15:56 +00:00
|
|
|
is_ring_vector_msg = (code == HNS3_MBX_MAP_RING_TO_VECTOR) ||
|
|
|
|
|
(code == HNS3_MBX_UNMAP_RING_TO_VECTOR) ||
|
|
|
|
|
(code == HNS3_MBX_GET_RING_VECTOR_MAP);
|
|
|
|
|
if (!is_ring_vector_msg)
|
|
|
|
|
req->msg[1] = subcode;
|
|
|
|
|
if (msg_data) {
|
|
|
|
|
offset = is_ring_vector_msg ? 1 : HNS3_CMD_CODE_OFFSET;
|
|
|
|
|
memcpy(&req->msg[offset], msg_data, msg_len);
|
|
|
|
|
}
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
/* synchronous send */
|
|
|
|
|
if (need_resp) {
|
|
|
|
|
req->mbx_need_resp |= HNS3_MBX_NEED_RESP_BIT;
|
|
|
|
|
rte_spinlock_lock(&hw->mbx_resp.lock);
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
hns3_mbx_prepare_resp(hw, code, subcode);
|
|
|
|
|
req->match_id = hw->mbx_resp.match_id;
|
2019-09-26 14:02:00 +00:00
|
|
|
ret = hns3_cmd_send(hw, &desc, 1);
|
|
|
|
|
if (ret) {
|
2021-03-31 10:01:41 +00:00
|
|
|
hw->mbx_resp.head--;
|
2019-09-26 14:02:00 +00:00
|
|
|
rte_spinlock_unlock(&hw->mbx_resp.lock);
|
|
|
|
|
hns3_err(hw, "VF failed(=%d) to send mbx message to PF",
|
|
|
|
|
ret);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = hns3_get_mbx_resp(hw, code, subcode, resp_data, resp_len);
|
|
|
|
|
rte_spinlock_unlock(&hw->mbx_resp.lock);
|
|
|
|
|
} else {
|
|
|
|
|
/* asynchronous send */
|
|
|
|
|
ret = hns3_cmd_send(hw, &desc, 1);
|
|
|
|
|
if (ret) {
|
|
|
|
|
hns3_err(hw, "VF failed(=%d) to send mbx message to PF",
|
|
|
|
|
ret);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
hns3_cmd_crq_empty(struct hns3_hw *hw)
|
|
|
|
|
{
|
|
|
|
|
uint32_t tail = hns3_read_dev(hw, HNS3_CMDQ_RX_TAIL_REG);
|
|
|
|
|
|
|
|
|
|
return tail == hw->cmq.crq.next_to_use;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2021-04-13 11:50:00 +00:00
|
|
|
hns3vf_handle_link_change_event(struct hns3_hw *hw,
|
|
|
|
|
struct hns3_mbx_pf_to_vf_cmd *req)
|
2019-09-26 14:02:00 +00:00
|
|
|
{
|
2021-01-22 10:18:52 +00:00
|
|
|
uint8_t link_status, link_duplex;
|
2021-04-13 11:50:00 +00:00
|
|
|
uint16_t *msg_q = req->msg;
|
2021-04-09 04:45:21 +00:00
|
|
|
uint8_t support_push_lsc;
|
2021-01-22 10:18:52 +00:00
|
|
|
uint32_t link_speed;
|
2019-09-26 14:02:00 +00:00
|
|
|
|
2021-04-13 11:50:00 +00:00
|
|
|
memcpy(&link_speed, &msg_q[2], sizeof(link_speed));
|
|
|
|
|
link_status = rte_le_to_cpu_16(msg_q[1]);
|
|
|
|
|
link_duplex = (uint8_t)rte_le_to_cpu_16(msg_q[4]);
|
|
|
|
|
hns3vf_update_link_status(hw, link_status, link_speed,
|
|
|
|
|
link_duplex);
|
|
|
|
|
support_push_lsc = (*(uint8_t *)&msg_q[5]) & 1u;
|
|
|
|
|
hns3vf_update_push_lsc_cap(hw, support_push_lsc);
|
|
|
|
|
}
|
2019-09-26 14:02:00 +00:00
|
|
|
|
2021-04-13 11:50:00 +00:00
|
|
|
static void
|
|
|
|
|
hns3_handle_asserting_reset(struct hns3_hw *hw,
|
|
|
|
|
struct hns3_mbx_pf_to_vf_cmd *req)
|
|
|
|
|
{
|
|
|
|
|
enum hns3_reset_level reset_level;
|
|
|
|
|
uint16_t *msg_q = req->msg;
|
2019-09-26 14:02:00 +00:00
|
|
|
|
2021-04-13 11:50:00 +00:00
|
|
|
/*
|
|
|
|
|
* PF has asserted reset hence VF should go in pending
|
|
|
|
|
* state and poll for the hardware reset status till it
|
|
|
|
|
* has been completely reset. After this stack should
|
|
|
|
|
* eventually be re-initialized.
|
|
|
|
|
*/
|
|
|
|
|
reset_level = rte_le_to_cpu_16(msg_q[1]);
|
|
|
|
|
hns3_atomic_set_bit(reset_level, &hw->reset.pending);
|
2019-09-26 14:02:00 +00:00
|
|
|
|
2021-04-13 11:50:00 +00:00
|
|
|
hns3_warn(hw, "PF inform reset level %d", reset_level);
|
|
|
|
|
hw->reset.stats.request_cnt++;
|
|
|
|
|
hns3_schedule_reset(HNS3_DEV_HW_TO_ADAPTER(hw));
|
2019-09-26 14:02:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Case1: receive response after timeout, req_msg_data
|
|
|
|
|
* is 0, not equal resp_msg, do lost--
|
|
|
|
|
* Case2: receive last response during new send_mbx_msg,
|
|
|
|
|
* req_msg_data is different with resp_msg, let
|
|
|
|
|
* lost--, continue to wait for response.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
hns3_update_resp_position(struct hns3_hw *hw, uint32_t resp_msg)
|
|
|
|
|
{
|
|
|
|
|
struct hns3_mbx_resp_status *resp = &hw->mbx_resp;
|
|
|
|
|
uint32_t tail = resp->tail + 1;
|
|
|
|
|
|
|
|
|
|
if (tail > resp->head)
|
|
|
|
|
tail = resp->head;
|
|
|
|
|
if (resp->req_msg_data != resp_msg) {
|
|
|
|
|
if (resp->lost)
|
|
|
|
|
resp->lost--;
|
|
|
|
|
hns3_warn(hw, "Received a mismatched response req_msg(%x) "
|
2020-11-09 14:28:57 +00:00
|
|
|
"resp_msg(%x) head(%u) tail(%u) lost(%u)",
|
2019-09-26 14:02:00 +00:00
|
|
|
resp->req_msg_data, resp_msg, resp->head, tail,
|
|
|
|
|
resp->lost);
|
|
|
|
|
} else if (tail + resp->lost > resp->head) {
|
|
|
|
|
resp->lost--;
|
|
|
|
|
hns3_warn(hw, "Received a new response again resp_msg(%x) "
|
2020-11-09 14:28:57 +00:00
|
|
|
"head(%u) tail(%u) lost(%u)", resp_msg,
|
2019-09-26 14:02:00 +00:00
|
|
|
resp->head, tail, resp->lost);
|
|
|
|
|
}
|
|
|
|
|
rte_io_wmb();
|
|
|
|
|
resp->tail = tail;
|
|
|
|
|
}
|
|
|
|
|
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
static void
|
|
|
|
|
hns3_handle_mbx_response(struct hns3_hw *hw, struct hns3_mbx_pf_to_vf_cmd *req)
|
|
|
|
|
{
|
|
|
|
|
struct hns3_mbx_resp_status *resp = &hw->mbx_resp;
|
|
|
|
|
uint32_t msg_data;
|
|
|
|
|
|
|
|
|
|
if (req->match_id != 0) {
|
|
|
|
|
/*
|
|
|
|
|
* If match_id is not zero, it means PF support copy request's
|
|
|
|
|
* match_id to its response. So VF could use the match_id
|
|
|
|
|
* to match the request.
|
|
|
|
|
*/
|
|
|
|
|
if (resp->matching_scheme !=
|
|
|
|
|
HNS3_MBX_RESP_MATCHING_SCHEME_OF_MATCH_ID) {
|
|
|
|
|
resp->matching_scheme =
|
|
|
|
|
HNS3_MBX_RESP_MATCHING_SCHEME_OF_MATCH_ID;
|
|
|
|
|
hns3_info(hw, "detect mailbox support match id!");
|
|
|
|
|
}
|
|
|
|
|
if (req->match_id == resp->match_id) {
|
|
|
|
|
resp->resp_status = hns3_resp_to_errno(req->msg[3]);
|
|
|
|
|
memcpy(resp->additional_info, &req->msg[4],
|
|
|
|
|
HNS3_MBX_MAX_RESP_DATA_SIZE);
|
|
|
|
|
rte_io_wmb();
|
|
|
|
|
resp->received_match_resp = true;
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the below instructions can be executed, it means PF does not
|
|
|
|
|
* support copy request's match_id to its response. So VF follows the
|
|
|
|
|
* original scheme to process.
|
|
|
|
|
*/
|
|
|
|
|
resp->resp_status = hns3_resp_to_errno(req->msg[3]);
|
|
|
|
|
memcpy(resp->additional_info, &req->msg[4],
|
|
|
|
|
HNS3_MBX_MAX_RESP_DATA_SIZE);
|
|
|
|
|
msg_data = (uint32_t)req->msg[1] << 16 | req->msg[2];
|
|
|
|
|
hns3_update_resp_position(hw, msg_data);
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-21 10:32:46 +00:00
|
|
|
static void
|
|
|
|
|
hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
|
|
|
|
|
{
|
|
|
|
|
switch (link_fail_code) {
|
|
|
|
|
case HNS3_MBX_LF_NORMAL:
|
|
|
|
|
break;
|
|
|
|
|
case HNS3_MBX_LF_REF_CLOCK_LOST:
|
|
|
|
|
hns3_warn(hw, "Reference clock lost!");
|
|
|
|
|
break;
|
|
|
|
|
case HNS3_MBX_LF_XSFP_TX_DISABLE:
|
|
|
|
|
hns3_warn(hw, "SFP tx is disabled!");
|
|
|
|
|
break;
|
|
|
|
|
case HNS3_MBX_LF_XSFP_ABSENT:
|
|
|
|
|
hns3_warn(hw, "SFP is absent!");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
hns3_warn(hw, "Unknown fail code:%u!", link_fail_code);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2021-04-13 11:50:00 +00:00
|
|
|
hns3pf_handle_link_change_event(struct hns3_hw *hw,
|
2021-04-27 12:17:39 +00:00
|
|
|
struct hns3_mbx_vf_to_pf_cmd *req)
|
2019-12-21 10:32:46 +00:00
|
|
|
{
|
|
|
|
|
#define LINK_STATUS_OFFSET 1
|
|
|
|
|
#define LINK_FAIL_CODE_OFFSET 2
|
|
|
|
|
|
|
|
|
|
if (!req->msg[LINK_STATUS_OFFSET])
|
|
|
|
|
hns3_link_fail_parse(hw, req->msg[LINK_FAIL_CODE_OFFSET]);
|
|
|
|
|
|
2021-04-09 04:45:22 +00:00
|
|
|
hns3_update_linkstatus_and_event(hw, true);
|
2019-12-21 10:32:46 +00:00
|
|
|
}
|
|
|
|
|
|
net/hns3: support setting VF PVID by PF driver
This patch adds support setting VF PVID by hns3 PF kernel ethdev driver
on the host by "ip link set <eth num> vf <vf id> vlan <vlan tag>"
command.
Because of the hardware constraints, the striped VLAN tag will always in
Rx descriptors which should has been dropped when PVID is enabled and
the PVID will overwrite the outer VLAN tag in Tx descriptor. So, hns3
PMD driver need to change the processing of VLAN tags in the process of
Tx and Rx according to whether PVID is enabled.
1) If the hns3 PF kernel ethdev driver sets the PVID for VF device
before the initialization of the related VF device, hns3 VF PMD
driver should get the PVID state from PF driver through mailbox and
update the related state in txq and rxq maintained by hns3 VF driver
to change the process of Tx and Rx.
2) If the hns3 PF kernel ethdev driver sets the PVID for VF device after
initialization of the related VF device, the PF driver will notify VF
driver to update the PVID state. The VF driver will update the PVID
configuration state immediately to ensure that the VLAN process in Tx
and Rx is correct. But in the window period of this state transition,
packets loss or packets with wrong VLAN may occur.
3) Due to hardware limitations, we only support two-layer VLAN hardware
offload in Tx direction based on hns3 network engine, so when PVID is
enabled, QinQ insert is no longer supported. And when PVID is
enabled, in the following two cases:
i) packets with more than two VLAN tags.
ii) packets with one VLAN tag while the hardware VLAN insert is
enabled.
The packets will be regarded as abnormal packets and discarded by
hardware in Tx direction. For debugging purposes, a validation check
for these types of packets is added to the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts to inform users that
these packets will be discarded.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
2020-07-01 11:54:36 +00:00
|
|
|
static void
|
|
|
|
|
hns3_update_port_base_vlan_info(struct hns3_hw *hw,
|
|
|
|
|
struct hns3_mbx_pf_to_vf_cmd *req)
|
|
|
|
|
{
|
|
|
|
|
#define PVID_STATE_OFFSET 1
|
|
|
|
|
uint16_t new_pvid_state = req->msg[PVID_STATE_OFFSET] ?
|
|
|
|
|
HNS3_PORT_BASE_VLAN_ENABLE : HNS3_PORT_BASE_VLAN_DISABLE;
|
|
|
|
|
/*
|
|
|
|
|
* Currently, hardware doesn't support more than two layers VLAN offload
|
|
|
|
|
* based on hns3 network engine, which would cause packets loss or wrong
|
|
|
|
|
* packets for these types of packets. If the hns3 PF kernel ethdev
|
|
|
|
|
* driver sets the PVID for VF device after initialization of the
|
|
|
|
|
* related VF device, the PF driver will notify VF driver to update the
|
|
|
|
|
* PVID configuration state. The VF driver will update the PVID
|
|
|
|
|
* configuration state immediately to ensure that the VLAN process in Tx
|
|
|
|
|
* and Rx is correct. But in the window period of this state transition,
|
|
|
|
|
* packets loss or packets with wrong VLAN may occur.
|
|
|
|
|
*/
|
|
|
|
|
if (hw->port_base_vlan_cfg.state != new_pvid_state) {
|
|
|
|
|
hw->port_base_vlan_cfg.state = new_pvid_state;
|
net/hns3: add VLAN configuration compatibility
Because of hardware limitation based on the old version of hns3 network
engine, there are some restrictions:
a) HNS3 PMD driver needs select different processing mode for VLAN based
on whether PVID is set which means our driver need sense the PVID
states.
b) For packets transmitting process, only two layer of VLAN tag is
supported. If the total number of VLAN tags in mbuf and VLAN offload
by hardware (VLAN insert by descriptor) exceeds two, the VLAN in mbuf
will be overwritten by VLAN in the descriptor.
c) If port based VLAN is set, only one VLAN header is allowed in mbuf or
it will be discard by hardware.
In order to solve these restriction, two change is implemented on the
new versions of network engine.
1) add a new VLAN tagged insertion mode, named tag shift mode;
2) add a new VLAN strip control bit, named strip hide enable;
The tag shift mode means that VLAN tag will shift automatically when the
inserted place has a tag. For PMD driver, the VLAN tag1 and tag2
configurations in Tx side do not need to be considered because the
hardware completes it. However, the related configuration will still be
retained to be compatible with the old version of network engine.
The VLAN strip hide means that hardware will strip the VLAN tag and hide
VLAN in descriptor (VLAN ID exposed as zero and related STRIP_TAGP is
off).
These changes make it no longer necessary for the hns3 PMD driver to be
aware of the PVID status and have the ability to send mult-layer (more
than two) VLANs packets. Therefore, hns3 PMD driver introduces the
concept of VLAN mode and adds a new VLAN mode named HNS3_PVID_MODE to
indicate that PVID-related IO process can be implemented by the
hardware. And VF driver does not need to be modified because the related
mailbox messages will not be sent by PF kernel mode netdev driver under
new network engine and all the related hardware configuration is on the
PF side.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
2020-09-22 12:03:13 +00:00
|
|
|
hns3_update_all_queues_pvid_proc_en(hw);
|
net/hns3: support setting VF PVID by PF driver
This patch adds support setting VF PVID by hns3 PF kernel ethdev driver
on the host by "ip link set <eth num> vf <vf id> vlan <vlan tag>"
command.
Because of the hardware constraints, the striped VLAN tag will always in
Rx descriptors which should has been dropped when PVID is enabled and
the PVID will overwrite the outer VLAN tag in Tx descriptor. So, hns3
PMD driver need to change the processing of VLAN tags in the process of
Tx and Rx according to whether PVID is enabled.
1) If the hns3 PF kernel ethdev driver sets the PVID for VF device
before the initialization of the related VF device, hns3 VF PMD
driver should get the PVID state from PF driver through mailbox and
update the related state in txq and rxq maintained by hns3 VF driver
to change the process of Tx and Rx.
2) If the hns3 PF kernel ethdev driver sets the PVID for VF device after
initialization of the related VF device, the PF driver will notify VF
driver to update the PVID state. The VF driver will update the PVID
configuration state immediately to ensure that the VLAN process in Tx
and Rx is correct. But in the window period of this state transition,
packets loss or packets with wrong VLAN may occur.
3) Due to hardware limitations, we only support two-layer VLAN hardware
offload in Tx direction based on hns3 network engine, so when PVID is
enabled, QinQ insert is no longer supported. And when PVID is
enabled, in the following two cases:
i) packets with more than two VLAN tags.
ii) packets with one VLAN tag while the hardware VLAN insert is
enabled.
The packets will be regarded as abnormal packets and discarded by
hardware in Tx direction. For debugging purposes, a validation check
for these types of packets is added to the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts to inform users that
these packets will be discarded.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
2020-07-01 11:54:36 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-09 09:32:42 +00:00
|
|
|
static void
|
|
|
|
|
hns3_handle_promisc_info(struct hns3_hw *hw, uint16_t promisc_en)
|
|
|
|
|
{
|
|
|
|
|
if (!promisc_en) {
|
|
|
|
|
/*
|
|
|
|
|
* When promisc/allmulti mode is closed by the hns3 PF kernel
|
|
|
|
|
* ethdev driver for untrusted, modify VF's related status.
|
|
|
|
|
*/
|
|
|
|
|
hns3_warn(hw, "Promisc mode will be closed by host for being "
|
|
|
|
|
"untrusted.");
|
|
|
|
|
hw->data->promiscuous = 0;
|
|
|
|
|
hw->data->all_multicast = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-13 11:50:02 +00:00
|
|
|
static void
|
|
|
|
|
hns3_handle_mbx_msg_out_intr(struct hns3_hw *hw)
|
|
|
|
|
{
|
|
|
|
|
struct hns3_cmq_ring *crq = &hw->cmq.crq;
|
|
|
|
|
struct hns3_mbx_pf_to_vf_cmd *req;
|
|
|
|
|
struct hns3_cmd_desc *desc;
|
|
|
|
|
uint32_t tail, next_to_use;
|
|
|
|
|
uint8_t opcode;
|
|
|
|
|
uint16_t flag;
|
|
|
|
|
|
|
|
|
|
tail = hns3_read_dev(hw, HNS3_CMDQ_RX_TAIL_REG);
|
|
|
|
|
next_to_use = crq->next_to_use;
|
|
|
|
|
while (next_to_use != tail) {
|
|
|
|
|
desc = &crq->desc[next_to_use];
|
|
|
|
|
req = (struct hns3_mbx_pf_to_vf_cmd *)desc->data;
|
|
|
|
|
opcode = req->msg[0] & 0xff;
|
|
|
|
|
|
|
|
|
|
flag = rte_le_to_cpu_16(crq->desc[next_to_use].flag);
|
|
|
|
|
if (!hns3_get_bit(flag, HNS3_CMDQ_RX_OUTVLD_B))
|
|
|
|
|
goto scan_next;
|
|
|
|
|
|
|
|
|
|
if (crq->desc[next_to_use].opcode == 0)
|
|
|
|
|
goto scan_next;
|
|
|
|
|
|
|
|
|
|
if (opcode == HNS3_MBX_PF_VF_RESP) {
|
|
|
|
|
hns3_handle_mbx_response(hw, req);
|
|
|
|
|
/*
|
|
|
|
|
* Clear opcode to inform intr thread don't process
|
|
|
|
|
* again.
|
|
|
|
|
*/
|
|
|
|
|
crq->desc[crq->next_to_use].opcode = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
scan_next:
|
|
|
|
|
next_to_use = (next_to_use + 1) % hw->cmq.crq.desc_num;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-26 14:02:00 +00:00
|
|
|
void
|
|
|
|
|
hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
|
|
|
|
|
{
|
2021-04-22 01:55:50 +00:00
|
|
|
struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
|
2019-09-26 14:02:00 +00:00
|
|
|
struct hns3_cmq_ring *crq = &hw->cmq.crq;
|
|
|
|
|
struct hns3_mbx_pf_to_vf_cmd *req;
|
|
|
|
|
struct hns3_cmd_desc *desc;
|
2021-04-22 01:55:50 +00:00
|
|
|
bool handle_out;
|
2020-03-26 07:14:32 +00:00
|
|
|
uint8_t opcode;
|
2019-09-26 14:02:00 +00:00
|
|
|
uint16_t flag;
|
|
|
|
|
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
rte_spinlock_lock(&hw->cmq.crq.lock);
|
|
|
|
|
|
2021-04-22 01:55:50 +00:00
|
|
|
handle_out = (rte_eal_process_type() != RTE_PROC_PRIMARY ||
|
|
|
|
|
!rte_thread_is_intr()) && hns->is_vf;
|
|
|
|
|
if (handle_out) {
|
2021-04-13 11:50:02 +00:00
|
|
|
/*
|
|
|
|
|
* Currently, any threads in the primary and secondary processes
|
|
|
|
|
* could send mailbox sync request, so it will need to process
|
|
|
|
|
* the crq message (which is the HNS3_MBX_PF_VF_RESP) in there
|
|
|
|
|
* own thread context. It may also process other messages
|
|
|
|
|
* because it uses the policy of processing all pending messages
|
|
|
|
|
* at once.
|
|
|
|
|
* But some messages such as HNS3_MBX_PUSH_LINK_STATUS could
|
|
|
|
|
* only process within the intr thread in primary process,
|
|
|
|
|
* otherwise it may lead to report lsc event in secondary
|
|
|
|
|
* process.
|
|
|
|
|
* So the threads other than intr thread in primary process
|
|
|
|
|
* could only process HNS3_MBX_PF_VF_RESP message, if the
|
|
|
|
|
* message processed, its opcode will rewrite with zero, then
|
|
|
|
|
* the intr thread in primary process will not process again.
|
|
|
|
|
*/
|
|
|
|
|
hns3_handle_mbx_msg_out_intr(hw);
|
|
|
|
|
rte_spinlock_unlock(&hw->cmq.crq.lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-26 14:02:00 +00:00
|
|
|
while (!hns3_cmd_crq_empty(hw)) {
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
|
|
|
|
|
rte_spinlock_unlock(&hw->cmq.crq.lock);
|
2019-09-26 14:02:00 +00:00
|
|
|
return;
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
}
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
desc = &crq->desc[crq->next_to_use];
|
|
|
|
|
req = (struct hns3_mbx_pf_to_vf_cmd *)desc->data;
|
2020-03-26 07:14:32 +00:00
|
|
|
opcode = req->msg[0] & 0xff;
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
flag = rte_le_to_cpu_16(crq->desc[crq->next_to_use].flag);
|
|
|
|
|
if (unlikely(!hns3_get_bit(flag, HNS3_CMDQ_RX_OUTVLD_B))) {
|
|
|
|
|
hns3_warn(hw,
|
2020-11-09 14:28:57 +00:00
|
|
|
"dropped invalid mailbox message, code = %u",
|
2020-03-26 07:14:32 +00:00
|
|
|
opcode);
|
2019-09-26 14:02:00 +00:00
|
|
|
|
|
|
|
|
/* dropping/not processing this invalid message */
|
|
|
|
|
crq->desc[crq->next_to_use].flag = 0;
|
|
|
|
|
hns3_mbx_ring_ptr_move_crq(crq);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-22 01:55:50 +00:00
|
|
|
handle_out = hns->is_vf && desc->opcode == 0;
|
|
|
|
|
if (handle_out) {
|
2021-04-13 11:50:02 +00:00
|
|
|
/* Message already processed by other thread */
|
|
|
|
|
crq->desc[crq->next_to_use].flag = 0;
|
|
|
|
|
hns3_mbx_ring_ptr_move_crq(crq);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-26 07:14:32 +00:00
|
|
|
switch (opcode) {
|
2019-09-26 14:02:00 +00:00
|
|
|
case HNS3_MBX_PF_VF_RESP:
|
net/hns3: fix possible mismatched response of mailbox
Currently, the mailbox synchronous communication between VF and PF use
the following fields to maintain communication:
1. Req_msg_data which was combined by message code and subcode, used to
match request and response.
2. Head which means the number of requests successfully sent by VF.
3. Tail which means the number of responses successfully received by VF.
4. Lost which means the number of requests which are timeout.
There may possible mismatches of the following situation:
1. VF sends message A with code=1 subcode=1.
Then head=1, tail=0, lost=0.
2. PF was blocked about 500ms when processing the message A.
3. VF will detect message A timeout because it can't get the response
within 500ms.
Then head=1, tail=0, lost=1.
4. VF sends message B with code=1 subcode=1 which equal message A.
Then head=2, tail=0, lost=1.
5. PF processes the first message A and send the response message to VF.
6. VF will update tail field to 1, but the lost field will remain
unchanged because the code/subcode equal message B's, so driver will
return success because now the head(2) equals tail(1) plus lost(1).
This will lead to mismatch of request and response.
To fix the above bug, we use the following scheme:
1. The message sent from VF was labelled with match_id which was a
unique 16-bit non-zero value.
2. The response sent from PF will label with match_id which got from the
request.
3. The VF uses the match_id to match request and response message.
This scheme depends on the PF driver, if the PF driver don't support
then VF will uses the original scheme.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-04-13 11:50:01 +00:00
|
|
|
hns3_handle_mbx_response(hw, req);
|
2019-09-26 14:02:00 +00:00
|
|
|
break;
|
|
|
|
|
case HNS3_MBX_LINK_STAT_CHANGE:
|
2021-04-13 11:50:00 +00:00
|
|
|
hns3vf_handle_link_change_event(hw, req);
|
|
|
|
|
break;
|
2019-09-26 14:02:00 +00:00
|
|
|
case HNS3_MBX_ASSERTING_RESET:
|
2021-04-13 11:50:00 +00:00
|
|
|
hns3_handle_asserting_reset(hw, req);
|
2019-09-26 14:02:00 +00:00
|
|
|
break;
|
2019-12-21 10:32:46 +00:00
|
|
|
case HNS3_MBX_PUSH_LINK_STATUS:
|
2021-04-27 12:17:39 +00:00
|
|
|
/*
|
|
|
|
|
* This message is reported by the firmware and is
|
|
|
|
|
* reported in 'struct hns3_mbx_vf_to_pf_cmd' format.
|
|
|
|
|
* Therefore, we should cast the req variable to
|
|
|
|
|
* 'struct hns3_mbx_vf_to_pf_cmd' and then process it.
|
|
|
|
|
*/
|
|
|
|
|
hns3pf_handle_link_change_event(hw,
|
|
|
|
|
(struct hns3_mbx_vf_to_pf_cmd *)req);
|
2019-12-21 10:32:46 +00:00
|
|
|
break;
|
net/hns3: support setting VF PVID by PF driver
This patch adds support setting VF PVID by hns3 PF kernel ethdev driver
on the host by "ip link set <eth num> vf <vf id> vlan <vlan tag>"
command.
Because of the hardware constraints, the striped VLAN tag will always in
Rx descriptors which should has been dropped when PVID is enabled and
the PVID will overwrite the outer VLAN tag in Tx descriptor. So, hns3
PMD driver need to change the processing of VLAN tags in the process of
Tx and Rx according to whether PVID is enabled.
1) If the hns3 PF kernel ethdev driver sets the PVID for VF device
before the initialization of the related VF device, hns3 VF PMD
driver should get the PVID state from PF driver through mailbox and
update the related state in txq and rxq maintained by hns3 VF driver
to change the process of Tx and Rx.
2) If the hns3 PF kernel ethdev driver sets the PVID for VF device after
initialization of the related VF device, the PF driver will notify VF
driver to update the PVID state. The VF driver will update the PVID
configuration state immediately to ensure that the VLAN process in Tx
and Rx is correct. But in the window period of this state transition,
packets loss or packets with wrong VLAN may occur.
3) Due to hardware limitations, we only support two-layer VLAN hardware
offload in Tx direction based on hns3 network engine, so when PVID is
enabled, QinQ insert is no longer supported. And when PVID is
enabled, in the following two cases:
i) packets with more than two VLAN tags.
ii) packets with one VLAN tag while the hardware VLAN insert is
enabled.
The packets will be regarded as abnormal packets and discarded by
hardware in Tx direction. For debugging purposes, a validation check
for these types of packets is added to the '.tx_pkt_prepare' ops
implementation function named hns3_prep_pkts to inform users that
these packets will be discarded.
Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
2020-07-01 11:54:36 +00:00
|
|
|
case HNS3_MBX_PUSH_VLAN_INFO:
|
|
|
|
|
/*
|
|
|
|
|
* When the PVID configuration status of VF device is
|
|
|
|
|
* changed by the hns3 PF kernel driver, VF driver will
|
|
|
|
|
* receive this mailbox message from PF driver.
|
|
|
|
|
*/
|
|
|
|
|
hns3_update_port_base_vlan_info(hw, req);
|
|
|
|
|
break;
|
2020-03-09 09:32:42 +00:00
|
|
|
case HNS3_MBX_PUSH_PROMISC_INFO:
|
|
|
|
|
/*
|
|
|
|
|
* When the trust status of VF device changed by the
|
|
|
|
|
* hns3 PF kernel driver, VF driver will receive this
|
|
|
|
|
* mailbox message from PF driver.
|
|
|
|
|
*/
|
|
|
|
|
hns3_handle_promisc_info(hw, req->msg[1]);
|
|
|
|
|
break;
|
2019-09-26 14:02:00 +00:00
|
|
|
default:
|
2021-04-22 01:55:49 +00:00
|
|
|
hns3_err(hw, "received unsupported(%u) mbx msg",
|
2019-09-26 14:02:00 +00:00
|
|
|
req->msg[0]);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
crq->desc[crq->next_to_use].flag = 0;
|
|
|
|
|
hns3_mbx_ring_ptr_move_crq(crq);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Write back CMDQ_RQ header pointer, IMP need this pointer */
|
|
|
|
|
hns3_write_dev(hw, HNS3_CMDQ_RX_HEAD_REG, crq->next_to_use);
|
net/hns3: fix setting default MAC address in bonding of VF
When start testpmd with two hns3 VFs(0000:bd:01.0, 0000:bd:01.7), and
then execute the following commands:
testpmd> create bonded device 1 0
testpmd> set bonding mac_addr 2 3c:12:34:56:78:9a
testpmd> add bonding slave 0 2
testpmd> add bonding slave 1 2
testpmd> set portmask 0x4
testpmd> port start 2
It will occurs the following error in a low probability:
0000:bd:01.0 hns3_get_mbx_resp(): VF could not get mbx(3,0)
head(16) tail(15) lost(1) from PF in_irq:0
0000:bd:01.0 hns3vf_set_default_mac_addr(): Failed to set mac
addr(3C:**:**:**:78:9A) for vf: -62
mac_address_slaves_update(1541) - Failed to update port Id 0
MAC address
The problem replay:
1. The 'port start 2' command will start slave ports and then set slave
mac address, the function call flow: bond_ethdev_start ->
mac_address_slaves_update.
2. There are also a monitor task which running in intr thread will check
slave ports link status and update slave ports mac address, the
function call flow: bond_ethdev_slave_link_status_change_monitor ->
bond_ethdev_lsc_event_callback -> mac_address_slaves_update.
3. Because the above step1&2 running on different threads, they may both
call drivers ops mac_addr_set which is hns3vf_set_default_mac_addr.
4. hns3vf_set_default_mac_addr will first acquire hw.lock and then send
mailbox to PF and wait PF's response message. Note: the PF's
response is an independent message which will received in hw.cmq.crq,
the receiving operation can only performed in intr thread.
5. So if the step1 operation hold the hw.lock and try get response
message, and step2 operation try acquire the hw.lock and so it can't
process the response message, this will lead to step1 fail.
The solution:
1. make all threads could process the mailbox response message, which
protected by the hw.cmq.crq.lock.
2. use the following rules to avoid deadlock:
2.1. ensure use the correct locking sequence: hw.lock >
hw.mbx_resp.lock > hw.cmq.crq.lock.
2.2. make sure don't acquire such as hw.lock & hw.mbx_resp.lock again
when process mailbox response message.
Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
2021-03-31 10:01:36 +00:00
|
|
|
|
|
|
|
|
rte_spinlock_unlock(&hw->cmq.crq.lock);
|
2019-09-26 14:02:00 +00:00
|
|
|
}
|
