On Wed, 2024-12-11 at 17:49 -0800, Jakub Kicinski wrote: > 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. I understand your point now. > > 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). My terminology was slightly off. "TC queues" are a logical construct, not necessarily corresponding to device queues. As far as I know, packet traffic classes are determined with a variety of methods, and can be encoded in the IP header (ToS) or as metadata in the tx descriptor somewhere. I am not sure there's any correspondence with device queues although one could define specific queues for specific traffic classes, I guess. The "TC queues" I was mentioning are a logical representation of the packet flow and refer to the hardware's ability to treat different TCs differently with HW scheduling elements. > > 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. Another side effect of the terminology I used. net-shapers currently deals with device queues and grouping them, I was thinking about defining another logical view for traffic split according to traffic class, grouping of traffic classes and applying limits to the group. Right now TCs are not modeled in net-shapers at all. That's why I'm waiting for Paolo to comment, I have no idea what thoughts were put into modeling traffic classes in net-shapers. > > 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. The current patchset extends the well-established devlink rate API with the minimal set of fields required to model traffic classes and offers a full implementation of this new feature in a driver. It was designed and started before net-shapers was merged. We did consider integrating with net-shapers, but because it wasn't yet merged, it couldn't do TCs or multi-device grouping (nor intend to do multi-device), it was rejected as the API of choice. Can the missing link between TC modeling in net-shapers can be added in another series once it is better understood and discussed with Paolo? Cosmin.
