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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 1 Apr 2024 07:34:16 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Tariq Toukan <ttoukan.linux@...il.com>
Cc: Saeed Mahameed <saeed@...nel.org>, "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 Mon, 1 Apr 2024 09:54:26 +0300 Tariq Toukan wrote:
> 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.

Any way to preserve the indir table in case it has to grow?
If it increases by pow2 maybe we can "duplicate" the old table?
90% of the time when user changes the settings it's to exclude
a queue from RSS, the remaining 10% to change the balance. 
In both cases "mirroring" the settings would be fine.

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

Say user allocated 16 queues for RSS and 4 for flow rules and/or other
RSS context. Now they want to bump the 4 to 8. Resetting RSS and to be
able to allocate new queues may not be an option, as traffic from the
two "domains" would start mixing. Admittedly a bit contrived but not
impossible, so my vote would be to only nak the cases we really can't
reliably support :(

> 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.