Re:net-shapers plan

[Dave Ertman <david.m.ertman@intel.com>]

On 3/6/2025 6:03 AM, Cosmin Ratiu wrote:
> Hello,
> 
> This (long) email presents a plan agreed with Simon and Paolo for
> extending net-shapers with use cases currently serviced by devlink-
> rate. The goal is to get net-shapers to feature parity with devlink-
> rate so that the amount of code dedicated to traffic shaping in the
> kernel could eventually be reduced significantly.
> 
> This is in response to Jakub's concerns raised in [3] and [4].
> 
> Context
> -------
> devlink-rate ([1]) can control traffic shaping for a VF / VF group and
> is currently implemented by the Intel ice and NVIDIA mlx5 drivers. It
> operates either on devlink ports (for VF rates) or on devlink objects
> (for group rates). Rate objects are owned by the devlink object.
> 
> net-shapers ([2]) is a recently added API for shaping traffic for a
> netdev tx queue / queue group / entire netdev. It is more granular than
> devlink-rate but cannot currently control shaping for groups of
> netdevs. It operates with netdev handles. Stores the shaping hierarchy
> in the netdevice.
> 
> [3] & [4] add support to devlink-rate for traffic-class shaping, which
> is controlling the shaping hierarchy in hardware to control the
> bandwidth allocation different traffic classes get. The question is how
> to represent traffic classes in net-shapers.

[ ... ]

> 3. Extend NODE scope to group multiple netdevs and new DEVLINK binding
> Today, all net-shapers objects are owned by a netdevice. Who should own
> a net shaper that represents a group of netdevices? It needs to be a
> stable object that isn't affected by group membership changes and
> therefore cannot be any netdev from the group. The only sensible option
> would be to pick an object corresponding to the eswitch to own such
> groups, which neatly corresponds to the devlink object today.

Will you be using two sets of _ops structs?

One for the netdev (ndo_shaper_ops) when the scope is meant to target a
VF handling its own sub-tree, and another for devlink
(devlink_ops .rate_*) for when the scope is for the hypervisor managing
its netdevs?

DaveE