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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <73d7745697a9ab7507c5e4800b0dfc547823d475.camel@nvidia.com>
Date: Fri, 13 Dec 2024 13:42:46 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "kuba@...nel.org" <kuba@...nel.org>
CC: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"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 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.