| Message ID | 20211027152001.1320496-1-idosch@idosch.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | mlxsw: Offload root TBF as port shaper | expand |
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski <kuba@kernel.org>: On Wed, 27 Oct 2021 18:19:58 +0300 you wrote: > From: Ido Schimmel <idosch@nvidia.com> > > Petr says: > > Egress configuration in an mlxsw deployment would generally have an ETS > qdisc at root, with a number of bands and a priority dispatch between them. > Some of those bands could then have a RED and/or TBF qdiscs attached. > > [...] Here is the summary with links: - [net-next,1/3] mlxsw: spectrum_qdisc: Offload root TBF as port shaper https://git.kernel.org/netdev/net-next/c/48e4d00b1b93 - [net-next,2/3] selftests: mlxsw: Test offloadability of root TBF https://git.kernel.org/netdev/net-next/c/3d5290ea1dae - [net-next,3/3] selftests: mlxsw: Test port shaper https://git.kernel.org/netdev/net-next/c/2b11e24ebaef You are awesome, thank you!
From: Ido Schimmel <idosch@nvidia.com> Petr says: Egress configuration in an mlxsw deployment would generally have an ETS qdisc at root, with a number of bands and a priority dispatch between them. Some of those bands could then have a RED and/or TBF qdiscs attached. When TBF is used like this, mlxsw configures shaper on a subgroup, which is the pair of traffic classes (UC + BUM) corresponding to the band where TBF is installed. This way it is possible to limit traffic on several bands (subgroups) independently by configuring several TBF qdiscs, each on a different band. It is however not possible to limit traffic flowing through the port as such. The ASIC supports this through port shapers (as opposed to the abovementioned subgroup shapers). An obvious way to express this as a user would be to configure a root TBF qdisc, and then add the whole ETS hierarchy as its child. TBF (and RED) can currently be used as a root qdisc. This usage has always been accepted as a special case, when only one subgroup is configured, and that is the subgroup that root TBF and RED configure. However it was never possible to install ETS under that TBF. In this patchset, this limitation is relaxed. TBF qdisc in root position is now always offloaded as a port shaper. Such TBF qdisc does not limit offload of further children. It is thus possible to configure the usual priority classification through ETS, with RED and/or TBF on individual bands, all that below a port-level TBF. For example: (1) # tc qdisc replace dev swp1 root handle 1: tbf rate 800mbit burst 16kb limit 1M (2) # tc qdisc replace dev swp1 parent 1:1 handle 11: ets strict 8 priomap 7 6 5 4 3 2 1 0 (3) # tc qdisc replace dev swp1 parent 11:1 handle 111: tbf rate 600mbit burst 16kb limit 1M (4) # tc qdisc replace dev swp1 parent 11:2 handle 112: tbf rate 600mbit burst 16kb limit 1M Here, (1) configures a 800-Mbps port shaper, (2) adds an ETS element with 8 strictly-prioritized bands, and (3) and (4) configure two more shapers, each 600 Mbps, one under 11:1 (band 0, TCs 7 and 15), one under 11:2 (band 1, TCs 6 and 14). This way, traffic on bands 0 and 1 are each independently capped at 600 Mbps, and at the same time, traffic through the port as a whole is capped at 800 Mbps. In patch #1, TBF is permitted as root qdisc, under which the usual qdisc tree can be installed. In patch #2, the qdisc offloadability selftest is extended to cover the root TBF as well. Patch #3 then tests that the offloaded TBF shapes as expected. Petr Machata (3): mlxsw: spectrum_qdisc: Offload root TBF as port shaper selftests: mlxsw: Test offloadability of root TBF selftests: mlxsw: Test port shaper .../ethernet/mellanox/mlxsw/spectrum_qdisc.c | 55 +++++++++++++------ .../drivers/net/mlxsw/sch_offload.sh | 14 +++++ .../net/forwarding/sch_tbf_etsprio.sh | 28 ++++++++++ 3 files changed, 79 insertions(+), 18 deletions(-)