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

On Mon, 2024-12-09 at 13:41 -0800, Jakub Kicinski wrote:

On Mon, 9 Dec 2024 21:32:11 +0200 Tariq Toukan wrote:

quoted

quoted

Do you expect TC bw allocation to work on non-leaf nodes?

Yes. That's the point. It works.

Let's level -- I'm not trying to be difficult, but you're defining
uAPI with little to no documentation. "It works" is not going to cut
it.

The original intent was to document this in the devlink man page. But
we will add something in the kernel documentation as well in the next
submission.

quoted

quoted

How does this relate to the rate API which Paolo added? He was
asked
to build in a way to integrate with devlink now devlink is
growing
extra features again, which presumably the other API will also
need.
And the integration may turn out to be challenging.

AFAIU Paolo's work is not for shapers 'above' the network device
level, 
i.e. groups.

What's the difference between queue group and a VF?

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.

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.

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

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?

Cosmin.

[1]
https://lore.kernel.org/netdev/7195630a-1021-4e1e-b48b-a07945477863@redhat.com/ (local)