From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F37FCA0A02; Tue, 27 Apr 2021 15:19:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BB0F540150; Tue, 27 Apr 2021 15:19:52 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 619C44014E for ; Tue, 27 Apr 2021 15:19:51 +0200 (CEST) IronPort-SDR: OcKiVyZ0xou2fdYi5hVIRYwdfbzg6PxWwCIKByq14RFgW3fKg6V9CPzCP5dDUo57EegwEzfzAw O50/NujvS9hA== X-IronPort-AV: E=McAfee;i="6200,9189,9966"; a="196618004" X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="196618004" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 06:19:50 -0700 IronPort-SDR: tkLkFQheFylWABGhPQeHBOgZjHmV0vSFqmxPWWXMIRdGkQft5JkiIbk8TKbWPvnb5pA4K4IcEP aNrbjVUwPx4Q== X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="457640036" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.221.231]) ([10.213.221.231]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 06:19:49 -0700 To: "Min Hu (Connor)" , dev@dpdk.org References: <1619056552-43937-4-git-send-email-humin29@huawei.com> <1619525859-4182-1-git-send-email-humin29@huawei.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <3ffaf71d-3d39-579e-e9e0-56669f90f3c0@intel.com> Date: Tue, 27 Apr 2021 14:19:45 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] net/hns3: fix parse link fails code fail X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/27/2021 2:03 PM, Min Hu (Connor) wrote: > > > 在 2021/4/27 20:45, Ferruh Yigit 写道: >> On 4/27/2021 1:17 PM, Min Hu (Connor) wrote: >>> From: Chengwen Feng >>> >>> The link fails code should be parsed using the structure >>> hns3_mbx_vf_to_pf_cmd, else it will parse fail. >>> >>> Fixes: 109e4dd1bd7a ("net/hns3: get link state change through mailbox") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Chengwen Feng >>> Signed-off-by: Min Hu (Connor) >>> --- >>> v3: >>> * get the parameter as 'struct hns3_mbx_vf_to_pf_cmd' at first place. >>> >>> v2: >>> * kept original API interface. >>> --- >>>   drivers/net/hns3/hns3_mbx.c | 11 +++++++++-- >>>   1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c >>> index ba04ac9..31ab130 100644 >>> --- a/drivers/net/hns3/hns3_mbx.c >>> +++ b/drivers/net/hns3/hns3_mbx.c >>> @@ -347,7 +347,7 @@ hns3_link_fail_parse(struct hns3_hw *hw, uint8_t >>> link_fail_code) >>>     static void >>>   hns3pf_handle_link_change_event(struct hns3_hw *hw, >>> -                  struct hns3_mbx_pf_to_vf_cmd *req) >>> +                struct hns3_mbx_vf_to_pf_cmd *req) >>>   { >>>   #define LINK_STATUS_OFFSET     1 >>>   #define LINK_FAIL_CODE_OFFSET  2 >>> @@ -513,7 +513,14 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) >>>               hns3_handle_asserting_reset(hw, req); >>>               break; >>>           case HNS3_MBX_PUSH_LINK_STATUS: >>> -            hns3pf_handle_link_change_event(hw, req); >>> +            /* >>> +             * 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. >>> +             */ >> >> I am asking just to double check, the 'msg' type is different of >> 'hns3_mbx_pf_to_vf_cmd' & 'hns3_mbx_vf_to_pf_cmd', one is 'uint8_t', other is >> 'uint16_t', and 'msg' is used in the function >> 'hns3pf_handle_link_change_event()'. >> Is the 'msg' usage still correct after this change? >> > Hi, it is correct. > Currently, msg from PF or VF are all handled in the same > handler（hns3_dev_handle_mbx_msg）, we do different handling > according to different msg. > In futrue, we will separate handler from PF and VF. > Let me clarify what I mean, 'msg' is accessed with an index like "req->msg[LINK_FAIL_CODE_OFFSET]", and the 'req->msg' type is different as you change the 'req' type. It changes 'uint8_t' -> 'uint16_t', which makes "req->msg[LINK_FAIL_CODE_OFFSET]" point completely different location, can you please confirm this is expected/correct? >>> +            hns3pf_handle_link_change_event(hw, >>> +                (struct hns3_mbx_vf_to_pf_cmd *)req); >> >> Will it be more readable if 'desc->data' cast to "struct hns3_mbx_vf_to_pf_cmd >> *" (instead of 'req')? Up to you, I can proceed with this one if you prefer. >> . > OK, thanks Ferruh. So do you prefer to continue as it is, or will there be a change?