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 3AE1942814; Wed, 29 Mar 2023 03:56:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD38940F18; Wed, 29 Mar 2023 03:56:44 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 708D440EE7; Wed, 29 Mar 2023 03:56:43 +0200 (CEST) Received: from kwepemm600004.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4PmV4h4RLtzrWMK; Wed, 29 Mar 2023 09:55:32 +0800 (CST) Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Wed, 29 Mar 2023 09:56:40 +0800 Message-ID: Date: Wed, 29 Mar 2023 09:56:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 01/16] net/hns3: fix possible truncation of hash key when config To: Ferruh Yigit , CC: , , Dongdong Liu , , References: <20230310093518.5198-1-liudongdong3@huawei.com> <20230310093518.5198-2-liudongdong3@huawei.com> <987538c3-9269-aeaf-58c3-879dd23abbe2@amd.com> From: "lihuisong (C)" In-Reply-To: <987538c3-9269-aeaf-58c3-879dd23abbe2@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected 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 在 2023/3/11 3:36, Ferruh Yigit 写道: > On 3/10/2023 9:35 AM, Dongdong Liu wrote: >> From: Huisong Li >> >> The hash key length of hns3 driver is obtained from firmware. If the >> length isn't a multiple of HNS3_RSS_HASH_KEY_NUM (16), the last part >> of hash key will be truncated. >> > I am not sure if the explanation is correct, according below code last > part of the key is truncated if key_len *is* multiple of > HNS3_RSS_HASH_KEY_NUM. > > Because code assumes "key_len % HNS3_RSS_HASH_KEY_NUM" will give the > remaining part of the key, but when key_len is multiple of > HNS3_RSS_HASH_KEY_NUM it gives 0, causing last HNS3_RSS_HASH_KEY_NUM > chunk truncated. > > If above understanding correct, I can fix commit log while merging. Sorry for my late reply. Your understanding correct. Thanks. > >> Fixes: 4a7384e3c34d ("net/hns3: refactor set RSS hash algorithm and key interface") >> Fixes: c37ca66f2b27 ("net/hns3: support RSS") >> Cc: stable@dpdk.org >> > I am not sure if `c37ca66f2b27 ("net/hns3: support RSS")` is needed > here, issue seems because of commit 4a7384e3c34d, so this should be: > > Fixes: 4a7384e3c34d ("net/hns3: refactor set RSS hash algorithm and key > interface") > Cc: stable@dpdk.org > > >> Signed-off-by: Huisong Li >> Signed-off-by: Dongdong Liu >> --- >> drivers/net/hns3/hns3_rss.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c >> index d6e0754273..2011c18b9b 100644 >> --- a/drivers/net/hns3/hns3_rss.c >> +++ b/drivers/net/hns3/hns3_rss.c >> @@ -301,7 +301,8 @@ hns3_rss_set_algo_key(struct hns3_hw *hw, uint8_t hash_algo, >> req->hash_config |= (hash_algo & HNS3_RSS_HASH_ALGO_MASK); >> req->hash_config |= (idx << HNS3_RSS_HASH_KEY_OFFSET_B); >> >> - if (idx == max_bd_num - 1) >> + if (idx == max_bd_num - 1 && >> + (key_len % HNS3_RSS_HASH_KEY_NUM) != 0) >> cur_key_size = key_len % HNS3_RSS_HASH_KEY_NUM; >> else >> cur_key_size = HNS3_RSS_HASH_KEY_NUM; > .