Re: [PATCH net-next V5 00/11] net/mlx5: ConnectX-8 SW Steering + Rate management on traffic classes

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 11 Dec 2024 09:49:28 +0000 Cosmin Ratiu wrote:
> I've looked over the latest version of the net-shapers API.
> There is some conceptual overlap between this patchset and net-shapers
> ability to define a group of device queues and manipulate its tx
> limits. But as far as I am aware ([1]), the net-shapers API doesn't
> intend to shape entities above netdev level.

It's not about the uAPI but about having a uniform way of representing
the shaping hierarchy.

> So there are two things to discuss here:
> 1. Integrating device-level TC shaping into net-shapers. The net-
> shapers model would need to be extended with the ability to define TC
> queues. At the moment I see it's concerned with device tx queues which
> don't necessarily map 1:1 to traffic classes.

What are "TC queues"? NIC queues with assigned TC? Your patches shape
on a group of VFs, so the equivalent would be a group of queues 
(e.g. group of queues assigned to a container).

> Then, it would need to have the ability to group TC queues into a node.

🧐️ .. grouping of queues was the main direct use case for net-shapers,
so it's definitely there, perhaps I don't understand what you mean.

> Then the integration should be easy. Either API can call the device
> driver implementation or one API can call the other's function to do
> so.
> 
> Paolo, what are your thoughts on tc shaping in the net-shapers API?
> 
> 2. VF-group TC shaping. The current patchset offers the ability to
> split TC bandwidth on a devlink rate node, applying to all VFs in the
> node. As far as I am aware, net-shapers doesn't intend to address this
> use case. Do we want to have two completely different APIs to
> manipulate tc bandwidth?

Exactly my point. We have too many disjoint APIs. net-shapers was
merged on the premise that it will at least align the internal and
driver facing APIs, even if we still need multiple uAPIs.