netdev - Re: [net 06/10] net/mlx5: RSS, Block changing channels number when RXFH is configured

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: <87ca050f-5643-4b90-8768-1d624e367cac@gmail.com>
Date: Mon, 1 Apr 2024 09:54:26 +0300
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, Saeed Mahameed <saeed@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
 netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>,
 Gal Pressman <gal@...dia.com>, Leon Romanovsky <leonro@...dia.com>,
 Carolina Jubran <cjubran@...dia.com>
Subject: Re: [net 06/10] net/mlx5: RSS, Block changing channels number when
 RXFH is configured

On 29/03/2024 8:31, Jakub Kicinski wrote:
> On Tue, 26 Mar 2024 07:46:42 -0700 Saeed Mahameed wrote:
>> Changing the channels number after configuring the receive
>> flow hash indirection table may alter the RSS table size.
>> The previous configuration may no longer be compatible with
>> the new receive flow hash indirection table.
>>
>> Block changing the channels number when RXFH is configured.
> 
> Do I understand correctly that this will block all set_channels
> calls after indir table changes?

Right.

> This may be a little too risky
> for a fix. Perhaps okay for net-next, but not a fix.
> 

This fixes an issue introduced only in v6.7, not before that.

> I'd think that setting indir table and then increasing the number
> of channels is a pretty legit maneuver, or even best practice
> to allocate a queue outside of RSS.
> 
> Is it possible to make a narrower change, only rejecting the truly
> problematic transitions?
> 

The rationale of having a "single flow" or "single "logic" is to make it 
simple, and achieve a fine user experience.

Otherwise, users would, for example, question why increasing the number 
of channels (after setting the indir table) from 24 channels to 120 
works, but doesn't work when trying with 130 channels, although max num 
channels is much higher.

The required order looks pretty natural: first set the desired num of 
channels, and only then set your indirection table.

At the end, there are pros and cons for each solution.
If you still strongly prefer narrowing it down only to the truly 
problematic transitions, then we'll have no big issue in changing this.