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
