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 AC4C142643; Tue, 26 Sep 2023 14:08:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3A266402AA; Tue, 26 Sep 2023 14:08:49 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 7F86F4028C for ; Tue, 26 Sep 2023 14:08:46 +0200 (CEST) Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Rvz1f11PlztSrW; Tue, 26 Sep 2023 20:04:22 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemi500020.china.huawei.com (7.221.188.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 26 Sep 2023 20:08:42 +0800 Message-ID: Date: Tue, 26 Sep 2023 20:08:42 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4 1/7] ethdev: recomment some definitions related to RSS To: Ferruh Yigit , , Thomas Monjalon , Andrew Rybchenko , Ori Kam CC: References: <20230904072851.7384-1-haijie1@huawei.com> <20230908080030.3837515-1-haijie1@huawei.com> <20230908080030.3837515-2-haijie1@huawei.com> <7eaf8d21-e86f-4f59-b126-aa8eac72a6f1@amd.com> From: Jie Hai In-Reply-To: <7eaf8d21-e86f-4f59-b126-aa8eac72a6f1@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemi500020.china.huawei.com (7.221.188.8) 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 On 2023/9/21 0:39, Ferruh Yigit wrote: > On 9/8/2023 9:00 AM, Jie Hai wrote: >> 1. Recomment fields of 'rte_eth_rss_conf'. >> 2. Add comments for RTE_ETH_HASH_FUNCTION_DEFAULT. >> >> Signed-off-by: Jie Hai >> --- >> lib/ethdev/rte_ethdev.h | 28 +++++++++++++--------------- >> lib/ethdev/rte_flow.h | 4 ++++ >> 2 files changed, 17 insertions(+), 15 deletions(-) >> >> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h >> index 04a2564f222a..40cfbb7efddd 100644 >> --- a/lib/ethdev/rte_ethdev.h >> +++ b/lib/ethdev/rte_ethdev.h >> @@ -448,24 +448,22 @@ struct rte_vlan_filter_conf { >> /** >> * A structure used to configure the Receive Side Scaling (RSS) feature >> * of an Ethernet port. >> - * If not NULL, the *rss_key* pointer of the *rss_conf* structure points >> - * to an array holding the RSS key to use for hashing specific header >> - * fields of received packets. The length of this array should be indicated >> - * by *rss_key_len* below. Otherwise, a default random hash key is used by >> - * the device driver. >> - * >> - * The *rss_key_len* field of the *rss_conf* structure indicates the length >> - * in bytes of the array pointed by *rss_key*. To be compatible, this length >> - * will be checked in i40e only. Others assume 40 bytes to be used as before. >> - * >> - * The *rss_hf* field of the *rss_conf* structure indicates the different >> - * types of IPv4/IPv6 packets to which the RSS hashing must be applied. >> - * Supplying an *rss_hf* equal to zero disables the RSS feature. >> */ >> struct rte_eth_rss_conf { >> - uint8_t *rss_key; /**< If not NULL, 40-byte hash key. */ >> + /** >> + * If not NULL, 40-byte hash key to use for hashing specific header >> + * fields of received packets. The size of rss_key should be indicated >> + * by *rss_key_len* below. >> > > It says key length is 40 bytes, also says key length is defined by > 'rss_key_len'. I wonder how can we clarify this more, what about like: > > If not NULL, hash key to use for hashing. > The size of rss_key should be indicated by *rss_key_len* below. Drivers > are free to ignore the *rss_key_len* and assume key length is 40 bytes. > Not all drivers use 40-bytes hash key, e.g. the cnxk driver use hash key with length ROC_NIX_RSS_KEY_LEN(48). I think it's best not to mention '40 bytes' in the comments. This structure is used for querying and configuring, How about the following statements: /** * If used to query, the'rss_key_len' indicates the sizeof rss key of * the hardware. And only when rss_key_len is not zero, the 'rss_key' * is valid. * If used to configure, rss_key_len indicates the length of the * 'rss_key' if 'rss_key' is not empty. */ > >> + * Otherwise, a default random hash key is used by the device driver. >> + */ >> + uint8_t *rss_key; >> uint8_t rss_key_len; /**< hash key length in bytes. */ >> - uint64_t rss_hf; /**< Hash functions to apply - see below. */ >> + /** >> + * The different types of packets to which the RSS hashing must be >> + * applied, may be combined with SRC/DST_ONLY, see below. > > I find this difficult to understand, can we simplify it? > > The name 'hf' (hash function) is confusing on its own, but it is too > much burden to update it, at least we can clarify it with the above > documentation. > > rte_flow defines it as 'types' (rte_flow_action_rss.type) > (and it has 'func' for "hash algorithm" to increase confusion). > > Can we define something like (please don't use as it is, just thinking): > " > Set part of the packet that hashing will be applied for RSS purposes > (see RTE_ETH_RSS_*). How about "Indicating which type of packets and which part of the packets to be applied for RSS hash, (see RTE_ETH_RSS_*)." > " > >> + * Supplying an *rss_hf* equal to zero disables the RSS feature. >> + */ > > s/Supply/Set/ ? > "Setting *rss_hf* to zero disables the RSS feature." Will correct. > >> + uint64_t rss_hf; >> }; >> >> /* >> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h >> index 2ebb76dbc083..3bd0dc64fbe2 100644 >> --- a/lib/ethdev/rte_flow.h >> +++ b/lib/ethdev/rte_flow.h >> @@ -3187,6 +3187,10 @@ struct rte_flow_query_count { >> * Hash function types. >> */ >> enum rte_eth_hash_function { >> + /** >> + * DEFAULT means that conformance to a specific hash algorithm is >> + * uncared to the caller. The driver can pick the one it deems optimal. > > Not sure about word 'uncared' usage here, what about: > > " > DEFAULT means driver decides which hash algorithm to pick. > " > That's better. > > .