netdev - Re: [PATCH net-next v3 01/11] ethtool: rss: initial RSS

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: <83b6e47b-0413-4b0c-9739-9a61656fae14@nvidia.com>
Date: Wed, 16 Jul 2025 10:30:10 +0300
From: Gal Pressman <gal@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Cc: netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 andrew+netdev@...n.ch, horms@...nel.org, donald.hunter@...il.com,
 shuah@...nel.org, kory.maincent@...tlin.com, maxime.chevallier@...tlin.com,
 sdf@...ichev.me, ecree.xilinx@...il.com, jdamato@...tly.com, andrew@...n.ch
Subject: Re: [PATCH net-next v3 01/11] ethtool: rss: initial RSS_SET
 (indirection table handling)

On 16/07/2025 3:03, Jakub Kicinski wrote:
> Add initial support for RSS_SET, for now only operations on
> the indirection table are supported.
> 
> Unlike the ioctl don't check if at least one parameter is
> being changed. This is how other ethtool-nl ops behave,
> so pick the ethtool-nl consistency vs copying ioctl behavior.
> 
> There are two special cases here:
>  1) resetting the table to defaults;
>  2) support for tables of different size.
> 
> For (1) I use an empty Netlink attribute (array of size 0).
> 
> (2) may require some background. AFAICT a lot of modern devices
> allow allocating RSS tables of different sizes. mlx5 can upsize
> its tables, bnxt has some "table size calculation", and Intel
> folks asked about RSS table sizing in context of resource allocation
> in the past. The ethtool IOCTL API has a concept of table size,
> but right now the user is expected to provide a table exactly
> the size the device requests. Some drivers may change the table
> size at runtime (in response to queue count changes) but the
> user is not in control of this. What's not great is that all
> RSS contexts share the same table size. For example a device
> with 128 queues enabled, 16 RSS contexts 8 queues in each will
> likely have 256 entry tables for each of the 16 contexts,
> while 32 would be more than enough given each context only has
> 8 queues. To address this the Netlink API should avoid enforcing
> table size at the uAPI level, and should allow the user to express
> the min table size they expect.
> 
> To fully solve (2) we will need more driver plumbing but
> at the uAPI level this patch allows the user to specify
> a table size smaller than what the device advertises. The device
> table size must be a multiple of the user requested table size.
> We then replicate the user-provided table to fill the full device
> size table. This addresses the "allow the user to express the min
> table size" objective, while not enforcing any fixed size.
> From Netlink perspective .get_rxfh_indir_size() is now de facto
> the "max" table size supported by the device.
> 
> We may choose to support table replication in ethtool, too,
> when we actually plumb this thru the device APIs.
> 
> Initially I was considering moving full pattern generation
> to the kernel (which queues to use, at which frequency and
> what min sequence length). I don't think this complexity
> would buy us much and most if not all devices have pow-2
> table sizes, which simplifies the replication a lot.
> 
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>

Reviewed-by: Gal Pressman <gal@...dia.com>