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.
