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: <20250409150639.30a4c041@kernel.org>
Date: Wed, 9 Apr 2025 15:06:39 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Carolina Jubran <cjubran@...dia.com>
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 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.