Re: Understanding Flow API action RSS

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 4 Jan 2022 21:29:14 +0300 (MSK)
Ivan Malov <ivan.malov@oktetlabs.ru> wrote:

> Hi Stephen,
> 
> On Tue, 4 Jan 2022, Stephen Hemminger wrote:
> 
> > On Tue, 04 Jan 2022 13:41:55 +0100
> > Thomas Monjalon <thomas@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.