From: Chengwen Feng fengchengwen@huawei.com
VF's command receive queue was mainly used to receive mailbox messages from PF. There are two type mailbox messages: request response message and message pushed by PF.
There are two types of threads that can handle these messages: 1) the interrupt thread of the main process: it could handle both types of messages. 2) other threads: it could only handle request response messages.
The collaboration mechanism between the two type threads is that other threads set the opcode of processed messages to zero so that the interrupt thread of the main process does not process these messages again.
Unfortunately, the other threads mark the message pointed to by the crq->next-to-use variable which is fixed in the loop, not the message pointed to by the next-to-use variable.
Fixes: dbbbad23e380 ("net/hns3: fix VF handling LSC event in secondary process") Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Dongdong Liu liudongdong3@huawei.com --- drivers/net/hns3/hns3_mbx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c index 2de55a6417..9a05f0d1ee 100644 --- a/drivers/net/hns3/hns3_mbx.c +++ b/drivers/net/hns3/hns3_mbx.c @@ -429,7 +429,7 @@ hns3_handle_mbx_msg_out_intr(struct hns3_hw *hw) * Clear opcode to inform intr thread don't process * again. */ - crq->desc[crq->next_to_use].opcode = 0; + crq->desc[next_to_use].opcode = 0; }
scan_next: