From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 50C06A00BE; Wed, 29 Apr 2020 08:41:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99B451D8E2; Wed, 29 Apr 2020 08:41:33 +0200 (CEST) Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) by dpdk.org (Postfix) with ESMTP id D946C1D8E1 for ; Wed, 29 Apr 2020 08:41:31 +0200 (CEST) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 09AFFF2C56F47D8102C7; Wed, 29 Apr 2020 14:41:30 +0800 (CST) Received: from [127.0.0.1] (10.67.102.30) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Wed, 29 Apr 2020 14:41:19 +0800 To: Ferruh Yigit , Andrew Rybchenko , CC: , References: <1587990889-56408-1-git-send-email-oulijun@huawei.com> <909bd3c1-6ed4-15a4-d706-39d68e8deff5@intel.com> From: oulijun Message-ID: <59c19bbe-281a-9258-385c-47ce9b9c5889@huawei.com> Date: Wed, 29 Apr 2020 14:41:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <909bd3c1-6ed4-15a4-d706-39d68e8deff5@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.102.30] X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH] ethdev: check for Rx RSS distribution and RSS hash X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 在 2020/4/27 21:27, Ferruh Yigit 写道: > On 4/27/2020 1:49 PM, Andrew Rybchenko wrote: >> On 4/27/20 3:34 PM, Lijun Ou wrote: >>> When rte api checks the Rx RSS distribution is enable but the RSS >>> hash is disabled, it will return an error. >>> >>> Signed-off-by: Lijun Ou >>> --- >>> lib/librte_ethdev/rte_ethdev.c | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c >>> index 0854ef8..07734c4 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.c >>> +++ b/lib/librte_ethdev/rte_ethdev.c >>> @@ -1411,6 +1411,17 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, >>> goto rollback; >>> } >>> >>> + /* Check if Rx RSS distribution is enable but RSS hash is disabled. */ >>> + if (((dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG) != 0) && >>> + !(dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_RSS_HASH)) { >>> + RTE_ETHDEV_LOG(ERR, >>> + "Ethdev port_id=%u config valid Rx mq_mode with RSS but %s offload is no-requested\n", >>> + port_id, >>> + rte_eth_dev_rx_offload_name(DEV_RX_OFFLOAD_RSS_HASH)); >>> + ret = -EINVAL; >>> + goto rollback; >>> + } >>> + >>> /* >>> * Setup new number of RX/TX queues and reconfigure device. >>> */ >> >> NACK. It is perfectly fine to do distribution, but do not need RSS hash >> information. >> - ETH_MQ_RX_RSS_FLAG controls RSS hash calculation and distribution >> - DEV_RX_OFFLOAD_RSS_HASH controls delivery of the hash value >> itself from HW to SW >> > > Hi Lijun, > > As Andrew described, now 'DEV_RX_OFFLOAD_RSS_HASH' controls to copy calculated > hash value to 'mbuf::hash::rss' or not. When rss hash copied to mubf, > 'PKT_RX_RSS_HASH' flag of 'mbuf::ol_flags' set to notify the application that > hash value is valid. This was a performance optimization. > if the user is not configure the DEV_RX_OFFLOAD_RSS_HASH and the users add the ETH_MQ_RX_RSS_FLAG， as a result, the hardware has calculated the hash result and distributed, the mbuf::o1_flags have set the PKT_RX_RSS_HASH and the mbuf::hash::rss have set the hash result. What are the advantage of this configuration with DEV_RX_OFFLOAD_RSS_HASH? Can I understand it this way, If the user does not apply this rss hash, does it mean that rss cannot be used to improve performance, even if the hardware has calculated the rss hash result? > We know above because we were involved in development of it, if this is not > clean for third party, can you please amend your patch to clarify above behavior? > > Thanks, > ferruh > > . >