[PATCH net-next 0/2] net: stmmac: add EthType Rx Frame steering

[Nambiar, Amritha]

> -----Original Message-----
> From: Jakub Kicinski <kuba at kernel.org>
> Sent: Friday, December 10, 2021 11:38 AM
> To: Vladimir Oltean <olteanv at gmail.com>
> Cc: Ong, Boon Leong <boon.leong.ong at intel.com>; David S . Miller
> <davem at davemloft.net>; Giuseppe Cavallaro <peppe.cavallaro at st.com>;
> Alexandre Torgue <alexandre.torgue at st.com>; Jose Abreu
> <joabreu at synopsys.com>; Maxime Coquelin
> <mcoquelin.stm32 at gmail.com>; alexandre.torgue at foss.st.com;
> Kanzenbach, Kurt <kurt.kanzenbach at linutronix.de>;
> netdev at vger.kernel.org; linux-stm32 at st-md-mailman.stormreply.com;
> linux-arm-kernel at lists.infradead.org; Nambiar, Amritha
> <amritha.nambiar at intel.com>
> Subject: Re: [PATCH net-next 0/2] net: stmmac: add EthType Rx Frame
> steering
> 
> On Fri, 10 Dec 2021 13:57:30 +0200 Vladimir Oltean wrote:
> > Is it the canonical approach to perform flow steering via tc-flower hw_tc,
> > as opposed to ethtool --config-nfc? My understanding from reading the
> > documentation is that tc-flower hw_tc only selects the hardware traffic
> > class for a packet, and that this has to do with prioritization
> > (although the concept in itself is a bit ill-defined as far as I
> > understand it, how does it relate to things like offloaded skbedit priority?).
> > But selecting a traffic class, in itself, doesn't (directly or
> > necessarily) select a ring per se, as ethtool does? Just like ethtool
> > doesn't select packet priority, just RX queue. When the RX queue
> > priority is configurable (see the "snps,priority" device tree property
> > in stmmac_mtl_setup) and more RX queues have the same priority, I'm not
> > sure what hw_tc is supposed to do in terms of RX queue selection?
> 
> You didn't mention the mqprio, but I think that's the piece that maps
> TCs to queue pairs. You can have multiple queues in a TC.
> 
> Obviously that's still pretty weird what the flow rules should select
> is an RSS context. mqprio is a qdisc, which means Tx, not Rx.
> 
> Adding Amritha who I believe added the concept of selecting Rx queues
> via hw_tc. Can you comment?

So tc-mpqrio is the piece that is needed to set up the queue-groups. The offload
mode "hw 2" in mqprio will offload the TCs, the queue configurations and
bandwidth rate limits. The prio-tc map in mqprio will map a user priority to the
TC/queue-group. The priority to traffic class mapping and the user specified
queue ranges are used to configure the traffic class when the 'hw' option is set to 2.
Drivers can then configure queue-pairs based on the offsets and queue ranges
in mqprio.

The hw_tc option in tc-flower for ingress filter is used to direct Rx traffic to the
queue-group (configured via mqprio). Queue selection within the queue group can
be achieved using RSS.

I agree mqprio qdisc should be used to set up Tx queues only, but the limitation was the
absence of a single interface that could configure both Tx and Rx queue-groups/queue-sets
(ethtool did not support directing flows to a queue-group, but only a specific individual
queue, TC does not support Rx queue-group configuration either). The hw_tc in mqprio is a
range of class ids reserved to identify hardware traffic classes normally reported
via dev->num_tc. For Rx queue-group configuration, the gap is that the ingress/clsact qdisc
does not expose a set of virtual qdiscs similar to HW traffic classes in mqprio.
This was discussed in Slide 20 from Netdev 0x14 
(https://legacy.netdevconf.info/0x14/pub/slides/28/Application%20Device%20Queues%20for%20system-level%20network%20IO%20performance%20improvements.pdf)

-Amritha