netdev - Re: [net 0/2] rxfh with custom RSS fixes

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: <f565a8d6-e3b8-96d1-a7ac-212c64c60b1c@gmail.com>
Date: Tue, 25 Jul 2023 09:40:24 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Joe Damato <jdamato@...tly.com>, netdev@...r.kernel.org,
 saeedm@...dia.com, tariqt@...dia.com, ecree@...arflare.com, andrew@...n.ch,
 davem@...emloft.net, leon@...nel.org, pabeni@...hat.com,
 bhutchings@...arflare.com, arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [net 0/2] rxfh with custom RSS fixes

On 24/07/2023 23:08, Jakub Kicinski wrote:
> What's the status on your work? Are you planning to split the RSS
> config from ethtool or am I reading too much into what you said?

I was just thinking that when netlink dumps get added it would make
 sense to also extend the netlink version of SRSSH (which is what
 calls the rxfh_context ethtool_ops, via the misleadingly named
 ethtool_set_rxfh()) to include the hash fields setting that's
 currently done through ETHTOOL_SRXFH.  In which case I should add
 that data to struct ethtool_rxfh_context, and include it in the
 get/create/modify_rss_context ethtool_ops API.
Since it only occurred to me to consider that setting when I saw
 Joe's patches, I haven't really figured out yet how to go about
 the implementation of that.

More generally the status of my RSS work is that I've been umming
 and ahhing about that mutex you didn't like (I still think it's
 the Right Thing) so I've not made much progress with it.
And I should place on record that probably once I've gotten the
 kernel-driver API done I'll leave the netlink/uAPI stuff for
 someone else to do as I really don't have the relevant expertise.

> It'd be great to push the uAPI extensions back and make them
> netlink-only, but we can't make Joe wait if it takes a long time
> to finish up the basic conversion :(

Yeah as I said upthread I don't think we should make Joe wait, if
 he's got a use case that actually needs it (have you, Joe?  Or
 is it only GRXFH you need and the investigation just led you to
 notice SRXFH was broken?)

-ed