netdev - Re: [PATCH net-next 10/11] ethtool: rss: support setting flow hashing fields

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: <20250714092933.029a6847@kernel.org>
Date: Mon, 14 Jul 2025 09:29:33 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Gal Pressman <gal@...dia.com>
Cc: davem@...emloft.net, 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
Subject: Re: [PATCH net-next 10/11] ethtool: rss: support setting flow
 hashing fields

On Sun, 13 Jul 2025 14:12:33 +0300 Gal Pressman wrote:
> On 11/07/2025 4:53, Jakub Kicinski wrote:
> > Add support for ETHTOOL_SRXFH (setting hashing fields) in RSS_SET.
> > 
> > The tricky part is dealing with symmetric hashing, user can change
> > the hashing fields and symmetric hash in one request. Since fields
> > and hash function config are separate driver callback changes to
> > the two are not atomic. Keep things simple and validate the settings
> > against both pre- and post- change ones. Meaning that we will reject
> > the config request if user tries to correct the flow fields and set
> > input_xfrm in one request, or disables input_xfrm and makes flow
> > fields non-symmetric.  
> 
> How is it different than what we have in ioctl?

Because:

  user can change the hashing fields and symmetric hash in one request

IOCTL has two separate calls for this so there's no way to even try
to change both at once. I'll add "unlike IOCTL which has separate
calls" ?

> > We can adjust it later if there's a real need. Starting simple feels
> > right, and potentially partially applying the settings isn't nice,
> > either.
> > 
> > Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> > ---
> >  static void
> >  rss_set_ctx_update(struct ethtool_rxfh_context *ctx, struct nlattr **tb,
> >  		   struct rss_reply_data *data, struct ethtool_rxfh_param *rxfh)
> > @@ -673,11 +767,11 @@ ethnl_rss_set(struct ethnl_req_info *req_info, struct genl_info *info)
> >  	struct rss_req_info *request = RSS_REQINFO(req_info);
> >  	struct ethtool_rxfh_context *ctx = NULL;
> >  	struct net_device *dev = req_info->dev;
> > +	bool mod = false, fields_mod = false;  
> 
> Why not use mod?

Because it's a difference driver-facing op.