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

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.