netdev - Re: net-shapers plan

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: <9768e1e0-3a76-47af-b0f5-17793721bb0a@nvidia.com>
Date: Mon, 14 Apr 2025 11:27:00 +0300
From: Carolina Jubran <cjubran@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Cosmin Ratiu <cratiu@...dia.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "horms@...nel.org" <horms@...nel.org>,
 "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
 "davem@...emloft.net" <davem@...emloft.net>, Tariq Toukan
 <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>,
 "jiri@...nulli.us" <jiri@...nulli.us>,
 "edumazet@...gle.com" <edumazet@...gle.com>,
 Saeed Mahameed <saeedm@...dia.com>, "pabeni@...hat.com" <pabeni@...hat.com>
Subject: Re: net-shapers plan

On 11/04/2025 2:16, Jakub Kicinski wrote:
> On Thu, 10 Apr 2025 18:23:56 +0300 Carolina Jubran wrote:
>> We do configure the correct priority-to-queue mapping in the driver when
>> mqprio is used in DCB mode. In this setup, each traffic class has its
>> own dedicated Tx queue(s), and the driver programs the mapping
>> accordingly. The hardware performs its default priority check, sees that
>> the packet matches the configured queue, and proceeds to transmit
>> without taking any further action — everything behaves as expected.
>>
>> When DCB mode is not enabled, there is no fixed mapping between traffic
>> classes and Tx queues. In this case, the hardware still performs the
>> check, and if it detects a mismatch, it moves the send queue to the
>> appropriate scheduling queue to maintain proper traffic class behavior.
>> The priority check is always active by default, but when the mapping is
>> configured properly, it’s followed by a noop.
> 
> I hope you understand my concern, tho. Since you're providing the first
> implementation, if the users can grow dependent on such behavior we'd
> be in no position to explain later that it's just a quirk of mlx5 and
> not how the API is intended to operate.

Thanks for bringing this up. I want to make it clear that traffic 
classes must be properly matched to queues. We don’t rely on the 
hardware fallback behavior in mlx5. If the driver or firmware isn’t 
configured correctly, traffic class bandwidth control won’t work as 
expected — the user will suffer from constant switching of the TX queue 
between scheduling queues and head-of-line blocking. As a result, users 
shouldn’t expect reliable performance or correct bandwidth allocation.
We don’t encourage configuring this without proper TX queue mapping, so 
users won’t grow dependent on behavior that only happens to work without it.
We tried to highlight this in the plan section discussing queue 
selection and head-of-line blocking: To make traffic class shaping work, 
we must keep traffic classes separate for each transmit queue.