Message-ID: <20241216214528.42dc9a1b@kernel.org>
Date: Mon, 16 Dec 2024 21:45:28 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Cosmin Ratiu <cratiu@...dia.com>
Cc: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
 "ttoukan.linux@...il.com" <ttoukan.linux@...il.com>, Tariq Toukan
 <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>, "davem@...emloft.net"
 <davem@...emloft.net>, "jiri@...nulli.us" <jiri@...nulli.us>, Leon
 Romanovsky <leonro@...dia.com>, "edumazet@...gle.com"
 <edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>, Saeed
 Mahameed <saeedm@...dia.com>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next V5 00/11] net/mlx5: ConnectX-8 SW Steering +
 Rate management on traffic classes

On Fri, 13 Dec 2024 13:42:46 +0000 Cosmin Ratiu wrote:
> > > 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.

I'm not sure if Paolo is familiar with details of any device capable of
implementing shaping based on TC. You are, I hope, as you're trying
to add Linux uAPI for it.

> > > 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.

"I just need these few extra fields" is not conducive to good
designs which can stand the test of time.

> 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.

net-shapers took months of meetings and many, many revisions.
Providing an abstraction for all scheduling hierarchies was
an explicit goal. And someone from nVidia was actively reviewing.
Now you say that in another part of nVidia a decision was made
to ignore what the community was working on, sit out discussions 
and then try to get your own code merged. Did I get that right?

> 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?

Certainly Paolo's contributions would be appreciated. But I hope 
you realize that he is a networking maintainer (like myself)
and may not have the time to solve your problem for you.

I want to be clear that I don't expect you to migrate devlink rate
to net-shaper style API at this point. But we do need at the very
least a clear understanding of how the objects are mapped, and
therefore how TC support would fit into net-shapers.
Ideally, also, less disregard for community efforts.

Powered by blists - more mailing lists