Re: [PATCH net-next 00/15] Rate management on traffic classes + misc

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 9 Feb 2025 12:17:01 +0200 Tariq Toukan wrote:
> This feature extends the devlink-rate API to support traffic class (TC)
> bandwidth management, enabling more granular control over traffic
> shaping and rate limiting across multiple TCs. The API now allows users
> to specify bandwidth proportions for different traffic classes in a
> single command. This is particularly useful for managing Enhanced
> Transmission Selection (ETS) for groups of Virtual Functions (VFs),
> allowing precise bandwidth allocation across traffic classes.
> 
> Additionally, it refines the QoS handling in net/mlx5 to support TC
> arbitration and bandwidth management on vports and rate nodes.
> 
> Discussions on traffic class shaping in net-shapers began in V5 [2],
> where we discussed with maintainers whether net-shapers should support
> traffic classes and how this could be implemented.
> 
> Later, after further conversations with Paolo Abeni and Simon Horman,
> Cosmin provided an update [3], confirming that net-shapers' tree-based
> hierarchy aligns well with traffic classes when treated as distinct
> subsets of netdev queues. Since mlx5 enforces a 1:1 mapping between TX
> queues and traffic classes, this approach seems feasible, though some
> open questions remain regarding queue reconfiguration and certain mlx5
> scheduling behaviors.

/trim CC, add Carolina.

I don't understand what the plan is for shapers. As you say at netdev
level the classes will likely be associated with queues, so there isn't
much to do. So how will we represent the TCs based on classification?
I appreciate you working with Paolo and Simon, but from my perspective
none of the questions have been answered.

I'm not even asking you to write the code, just to have a solid plan.


Tariq, LMK if you want me to apply the patches starting from patch 6.
The rest of the series looks good. Two process notes, FWIW:
 - pretty sure we agreed in the past that it's okay to have patches
   which significantly extend uAPI or core to be handled outside of
   the main "driver update stream"; what "significant" means may take
   a bit of trial and error but I can't think of any misunderstandings 
   so far
 - from my PoV it'd be perfectly fine if you were to submit multiple
   series at once if they are independent. Just as long as there's not
   more than 15 patches for either tree outstanding. But I understand
   that comes at it's own cost