[dpdk-dev] [RFC v1 1/5] ethdev: support rss level on tunnel

[Nelio Laranjeiro]

On Mon, Dec 04, 2017 at 02:24:53PM +0000, Xueming(Steven) Li wrote:
> 
<snip>
> > > > >  	const struct rte_eth_rss_conf *rss_conf; /**< RSS parameters.
> > */
> > > > > +	/**
> > > > > +	 * RSS on tunnel level:
> > > > > +	 *  0: outer RSS
> > > > > +	 *  1: inner RSS
> > > > > +	 *  2-254: deep inner tunnel level RSS
> > > > > +	 *  -1: inner most level according to flow pattern
> > > > > +	 */
> > > >
> > > > Not clear enough, some PMD like MLX5 accept rules starting from the
> > > > VXLAN level, the comment "Inner most level according to flow pattern"
> > > > does not inform inside which tunnel the RSS will be done as this
> > > > pattern does not provide any information related to the position of
> > > > the tunnel in the packet.
> > > > What are the expectation for such situation?
> > > Regarding to supported tunnel types, VXLAN, L3VXLAN, GRE or GENEVE as
> > > long as the PMD supports. RTE_PTYPE_TUNNEL_MASK is a good mask of
> > > supported tunnel types.
> > 
> > Seems you did not understood my question, if I set a flow rule as
> > 
> >  flow create 0 ingress vxlan / end action rss level -1 queues 0 1 end /
> > end
> > 
> > According to your definition: "inner most level according to flow pattern"
> > in my example, the pattern does not provide any "level", this rule can
> > match the first level as the 254th as well, this leads to an undefined
> > situation when using level = -1.
> > 
> > What is your expectation in such situation?
> > 
> This rule looks a little confused to users, it covers fowling cases?
> 	Vxlan
> 	Gre/vxlan
> 	Vxlan/vxlan/vxlan

For my understanding, what I expect from this rule is an RSS spreading
on the inner *most* tunnel.  If the NIC was recognising at most 4
tunnels in the packet, it would mean RSS on the 4th tunnel, i.e. an
equivalent to:

 vxlan / end actions rss level 4 queues 0 1 end / end

> Auto rss level detection will get 1,2,3 for each of above examples from
> Pattern in a left to right order, based on what defined in pattern. 
> Users has to define tunnel pattern one by one exactly.
> 
> Actually we seldom see real requirement beyond inner tunnel, the auto-
> detection could be abandoned if it conflict with existing definition.

I agree on this last one,  if the definition is not clear enough
(multiple interpretation in this case), it is better to not expose such
functionality.

Thanks,

-- 
Nélio Laranjeiro
6WIND