On Tue, 4 Jan 2022 21:29:14 +0300 (MSK) Ivan Malov <ivan.ma...@oktetlabs.ru> wrote:
> Hi Stephen, > > On Tue, 4 Jan 2022, Stephen Hemminger wrote: > > > On Tue, 04 Jan 2022 13:41:55 +0100 > > Thomas Monjalon <tho...@monjalon.net> 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? You are right this area is completely undocumented. Personally would really like it if rte_flow had a reference software implementation and all the HW vendors had to make sure their HW matched the SW reference version. But this a case where the funding is all on the HW side, and no one has time or resources to do a complete SW version.. A sane implementation would configure RSS indirection as across all rx queues that were available when the device was started; ie all queues that did not have deferred start set. Then the application would start/stop queues and use rte_flow to reach them. But it doesn't appear the HW follows that model. > >>> 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.
