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: <2f747aac-767c-4631-b1db-436b11b83015@nvidia.com>
Date: Thu, 10 Apr 2025 18:23:56 +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 10/04/2025 1:06, Jakub Kicinski wrote:
> On Tue, 8 Apr 2025 17:43:19 +0300 Carolina Jubran wrote:
>>>> I don't believe there's a specific real-world scenario. It's really
>>>> about maximizing flexibility. Essentially, if a user sets things up in a
>>>> less-than-optimal way, the hardware can ensure that traffic is
>>>> classified and managed properly.
>>>
>>> I see. If you could turn it off and leave it out, at least until clear
>>> user appears that'd be great. Reclassifying packets on Tx slightly goes
>>> against the netdev recommendation to limit any packet parsing and
>>> interpretation on Tx.
>>
>> The hardware enforces a match between the packet’s priority and the
>> scheduling queue’s configured priority. If they match, the packet is
>> transmitted without further processing. If not, the hardware moves the
>> Tx queue to the right scheduling queue to ensure proper traffic class
>> separation.
>> This check is always active and cannot currently be disabled. Even when
>> the queue is configured with the correct priority, the hardware still
>> verifies the match before sending.
> 
> It needs to work as intended :( so you probably need to enforce
> the correct mapping in the FW or the driver.

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.