-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[ upstream commit be3590f54d0e415c23d4ed6ea55d967139c3ad10 ] Currently, hns3 VF driver uses the following points to match the response and request message for the mailbox synchronous message between VF and PF. 1. req_msg_data which is consist of message code and subcode, is used to match request and response. 2. head means the number of send success for VF. 3. tail means the number of receive success for VF. 4. lost means the number of send timeout for VF. And 'head', 'tail' and 'lost' are dynamically updated during the communication. Now there is a issue that all sync mailbox message will send failure forever at the flollowing case: 1. VF sends the message A then head=UINT32_MAX-1, tail=UINT32_MAX-3, lost=2. 2. VF sends the message B then head=UINT32_MAX, tail=UINT32_MAX-2, lost=2. 3. VF sends the message C, the message will be timeout because it can't get the response within 500ms. then head=0, tail=0, lost=2 note: tail is assigned to head if tail > head according to current code logic. From now on, all subsequent sync milbox messages fail to be sent. It's very complicated to use the fields 'lost','tail','head'. The code and subcode of the request sync mailbox are used as the matching code of the message, which is used to match the response message for receiving the synchronization response. This patch drops these fields and uses the following solution to solve this issue: In the handling response message process, using the req_msg_data of the request and response message to judge whether the sync mailbox message has been received. Fixes: 463e748 ("net/hns3: support mailbox") Signed-off-by: Dengdui Huang <huangdengdui@huawei.com> Signed-off-by: Jie Hai <haijie1@huawei.com> Acked-by: Huisong Li <lihuisong@huawei.com>
- Loading branch information
1 parent
7e63046
commit 1d9d4b5
Showing
3 changed files
with
13 additions
and
81 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters