| Message ID | 20211209151631.138326-1-boon.leong.ong@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: stmmac: add EthType Rx Frame steering | expand |
Hi David, Jakub, On Thu, Dec 09, 2021 at 11:16:29PM +0800, Ong Boon Leong wrote: > Hi, > > Patch 1/2: Fixes issue in tc filter delete flower for VLAN priority > steering. Patch has been sent to 'net' ML. Link as follow: > > https://patchwork.kernel.org/project/netdevbpf/patch/20211209130335.81114-1-boon.leong.ong@intel.com/ > > Patch 2/2: Patch to add LLDP and IEEE1588 EtherType RX frame steering > in tc flower that is implemented on-top of patch 1/2. > > Below are the test steps for checking out the newly added feature:- > > # Setup traffic class and ingress filter > $ IFDEVNAME=eth0 > $ tc qdisc add dev $IFDEVNAME ingress > $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \ > map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \ > queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 > > # Add two VLAN priority based RX Frame Steering > $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ > flower vlan_prio 1 hw_tc 1 > $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ > flower vlan_prio 2 hw_tc 2 > > # For LLDP > $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88cc \ > flower hw_tc 5 > > # For PTP > $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88f7 \ > flower hw_tc 6 > > # Show the ingress tc filters > $ tc filter show dev $IFDEVNAME ingress > > filter parent ffff: protocol ptp pref 49149 flower chain 0 > filter parent ffff: protocol ptp pref 49149 flower chain 0 handle 0x1 hw_tc 6 > eth_type 88f7 > in_hw in_hw_count 1 > filter parent ffff: protocol LLDP pref 49150 flower chain 0 > filter parent ffff: protocol LLDP pref 49150 flower chain 0 handle 0x1 hw_tc 5 > eth_type 88cc > in_hw in_hw_count 1 > filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 > filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 handle 0x1 hw_tc 2 > vlan_prio 2 > in_hw in_hw_count 1 > filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 > filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 handle 0x1 hw_tc 1 > vlan_prio 1 > in_hw in_hw_count 1 > > # Delete tc filters > $ tc filter del dev $IFDEVNAME parent ffff: pref 49149 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49150 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49152 > > Thanks, > BL > > Ong Boon Leong (2): > net: stmmac: fix tc flower deletion for VLAN priority Rx steering > net: stmmac: add tc flower filter for EtherType matching > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 20 ++ > .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 189 +++++++++++++++++- > 2 files changed, 205 insertions(+), 4 deletions(-) > > -- > 2.25.1 > 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?
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?
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Friday, December 10, 2021 11:38 AM > To: Vladimir Oltean <olteanv@gmail.com> > Cc: Ong, Boon Leong <boon.leong.ong@intel.com>; David S . Miller > <davem@davemloft.net>; Giuseppe Cavallaro <peppe.cavallaro@st.com>; > Alexandre Torgue <alexandre.torgue@st.com>; Jose Abreu > <joabreu@synopsys.com>; Maxime Coquelin > <mcoquelin.stm32@gmail.com>; alexandre.torgue@foss.st.com; > Kanzenbach, Kurt <kurt.kanzenbach@linutronix.de>; > netdev@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; > linux-arm-kernel@lists.infradead.org; Nambiar, Amritha > <amritha.nambiar@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
>On Fri, 10 Dec 2021 23:57:50 +0000 Nambiar, Amritha wrote: >> ethtool did not support directing flows to a queue-group, but only a specific >individual >> queue > >Just to clarify - not sure how true that part is, ethtool rules can >direct to RSS contexts since March 2018, your presentation is from 2020. Just realized there is mistake in reply-to email list. Now that the VLAN priority based RX steering patch is merged to net branch [1], I would like to resume the discussion for this track. Currently, we have vlan priority based RX steering be configured for stmmac driver using tc flower way. Will community agree to the same tc flower interface for EtherType based RX frame steering? If there is no further concern on this, I will send v2 for the patch. [1] https://patchwork.kernel.org/project/netdevbpf/patch/20211211145134.630258-1-boon.leong.ong@intel.com/
Hi, Patch 1/2: Fixes issue in tc filter delete flower for VLAN priority steering. Patch has been sent to 'net' ML. Link as follow: https://patchwork.kernel.org/project/netdevbpf/patch/20211209130335.81114-1-boon.leong.ong@intel.com/ Patch 2/2: Patch to add LLDP and IEEE1588 EtherType RX frame steering in tc flower that is implemented on-top of patch 1/2. Below are the test steps for checking out the newly added feature:- # Setup traffic class and ingress filter $ IFDEVNAME=eth0 $ tc qdisc add dev $IFDEVNAME ingress $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 # Add two VLAN priority based RX Frame Steering $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ flower vlan_prio 1 hw_tc 1 $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ flower vlan_prio 2 hw_tc 2 # For LLDP $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88cc \ flower hw_tc 5 # For PTP $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88f7 \ flower hw_tc 6 # Show the ingress tc filters $ tc filter show dev $IFDEVNAME ingress filter parent ffff: protocol ptp pref 49149 flower chain 0 filter parent ffff: protocol ptp pref 49149 flower chain 0 handle 0x1 hw_tc 6 eth_type 88f7 in_hw in_hw_count 1 filter parent ffff: protocol LLDP pref 49150 flower chain 0 filter parent ffff: protocol LLDP pref 49150 flower chain 0 handle 0x1 hw_tc 5 eth_type 88cc in_hw in_hw_count 1 filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 handle 0x1 hw_tc 2 vlan_prio 2 in_hw in_hw_count 1 filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 handle 0x1 hw_tc 1 vlan_prio 1 in_hw in_hw_count 1 # Delete tc filters $ tc filter del dev $IFDEVNAME parent ffff: pref 49149 $ tc filter del dev $IFDEVNAME parent ffff: pref 49150 $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 $ tc filter del dev $IFDEVNAME parent ffff: pref 49152 Thanks, BL Ong Boon Leong (2): net: stmmac: fix tc flower deletion for VLAN priority Rx steering net: stmmac: add tc flower filter for EtherType matching drivers/net/ethernet/stmicro/stmmac/stmmac.h | 20 ++ .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 189 +++++++++++++++++- 2 files changed, 205 insertions(+), 4 deletions(-)