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: <1593e9dd015dafcce967a9c328452ff963a69d68.camel@nvidia.com>
Date: Wed, 11 Dec 2024 09:49:28 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "ttoukan.linux@...il.com" <ttoukan.linux@...il.com>, "jiri@...nulli.us"
	<jiri@...nulli.us>, "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>,
	"davem@...emloft.net" <davem@...emloft.net>, Tariq Toukan
	<tariqt@...dia.com>, Gal Pressman <gal@...dia.com>, Leon Romanovsky
	<leonro@...dia.com>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"edumazet@...gle.com" <edumazet@...gle.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 Mon, 2024-12-09 at 13:41 -0800, Jakub Kicinski wrote:
> On Mon, 9 Dec 2024 21:32:11 +0200 Tariq Toukan wrote:
> > > Do you expect TC bw allocation to work on non-leaf nodes?
> > 
> > Yes. That's the point. It works.
> 
> Let's level -- I'm not trying to be difficult, but you're defining
> uAPI with little to no documentation. "It works" is not going to cut
> it.

The original intent was to document this in the devlink man page. But
we will add something in the kernel documentation as well in the next
submission.

> 
> > > How does this relate to the rate API which Paolo added? He was
> > > asked
> > > to build in a way to integrate with devlink now devlink is
> > > growing
> > > extra features again, which presumably the other API will also
> > > need.
> > > And the integration may turn out to be challenging.
> > 
> > AFAIU Paolo's work is not for shapers 'above' the network device
> > level, 
> > i.e. groups.
> 
> What's the difference between queue group and a VF?
> 

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.

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.

Then, it would need to have the ability to group TC queues into a node.

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?

Cosmin.

[1]
https://lore.kernel.org/netdev/7195630a-1021-4e1e-b48b-a07945477863@redhat.com/