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 CB051A00C5; Tue, 4 Jan 2022 19:29:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 59F9E40042; Tue, 4 Jan 2022 19:29:21 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id C168840040 for ; Tue, 4 Jan 2022 19:29:19 +0100 (CET) Received: by shelob.oktetlabs.ru (Postfix, from userid 122) id 3067C7F53F; Tue, 4 Jan 2022 21:29:18 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shelob.oktetlabs.ru X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_DISCARD, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from bree.oktetlabs.ru (bree.oktetlabs.ru [192.168.34.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPS id 3BE7F7F408; Tue, 4 Jan 2022 21:29:14 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 3BE7F7F408 Authentication-Results: shelob.oktetlabs.ru/3BE7F7F408; dkim=none; dkim-atps=neutral Date: Tue, 4 Jan 2022 21:29:14 +0300 (MSK) From: Ivan Malov To: Stephen Hemminger cc: Thomas Monjalon , Adrien Mazarguil , dev@dpdk.org, Andrew Rybchenko , orika@nvidia.com Subject: Re: Understanding Flow API action RSS In-Reply-To: <20220104085442.4e406f2a@hermes.local> Message-ID: <13f1886-d714-7e8-e176-4872a1c8e85@oktetlabs.ru> References: <76f98055-c517-5185-b79-d16ec5ef5ff@oktetlabs.ru> <4677833.GXAFRqVoOG@thomas> <20220104085442.4e406f2a@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 Hi Stephen, On Tue, 4 Jan 2022, Stephen Hemminger wrote: > On Tue, 04 Jan 2022 13:41:55 +0100 > Thomas Monjalon wrote: > >> +Cc Ori Kam, rte_flow maintainer >> >> 29/12/2021 15:34, Ivan Malov: >>> Hi all, >>> >>> In 'rte_flow.h', there is 'struct rte_flow_action_rss'. In it, 'queue' is >>> to provide "Queue indices to use". But it is unclear whether the order of >>> elements is meaningful or not. Does that matter? Can queue indices repeat? > > The order probably doesn't matter, it is like the RSS indirection table. Sorry, but RSS indirection table (RETA) assumes some structure. In it, queue indices can repeat, and the order is meaningful. In DPDK, RETA may comprise multiple "groups", each one comprising 64 entries. This 'queue' array in flow action RSS does not stick with the same terminology, it does not reuse the definition of RETA "group", etc. Just "queue indices to use". No definition of order, no structure. The API contract is not clear. Neither to users, nor to PMDs. > > rx queue = RSS_indirection_table[ RSS_hash_value % RSS_indirection_table_size ] > > So you could play with multiple queues matching same hash value, but that > would be uncommon. > >>> An ethdev may have "global" RSS setting with an indirection table of some >>> fixed size (say, 512). In what comes to flow rules, does that size matter? > > Global RSS is only used if the incoming packet does not match any rte_flow > action. If there is a a RTE_FLOW_ACTION_TYPE_QUEUE or RTE_FLOW_ACTION_TYPE_RSS > these take precedence. Yes, I know all of that. The question is how does the PMD select RETA size for this action? Can it select an arbitrary value? Or should it stick with the "global" one (eg. 512)? How does the user know the table size? If the user simply wants to spread traffic across the given queues, the effective table size is a don't care to them, and the existing API contract is fine. But if the user expects that certain packets hit some precise queues, they need to know the table size for that. So, the question is whether the users should or should not build any expectations of the effective table size and, if they should, are they supposed to use the "global" table size for that? > >>> When the user selects 'RTE_ETH_HASH_FUNCTION_DEFAULT' in action RSS, does >>> that allow the PMD to configure an arbitrary, non-Toeplitz hash algorithm? > > No the default is always Toeplitz. This goes back to the original definition > of RSS which is in Microsoft NDIS and uses Toeplitz. Then why have a dedicated enum named TOEPLITZ? Also, once again, the documentation should be more specific to say which algorithm exactly this DEFAULT choice provides. Otherwise, it is very vague. > > DPDK should have more examples of using rte_flow, I have some samples > but they aren't that useful. > I could not agree more. Thanks, Ivan M.