On 14/07/2025 19:21, Jakub Kicinski wrote:
On Sun, 13 Jul 2025 14:10:20 +0300 Gal Pressman wrote:
quoted
quoted
@@ -617,7 +623,11 @@ ethnl_rss_set(struct ethnl_req_info *req_info, struct genl_info *info)
goto exit_clean_data;
mod |= indir_mod;
- rxfh.hfunc = ETH_RSS_HASH_NO_CHANGE;
+ rxfh.hfunc = data.hfunc;
What is this for?
WDYM? data is filled in by the GET handler. So we init rxfh.hfunc
to what driver returned from GET.
quoted
quoted
+ ethnl_update_u8(&rxfh.hfunc, tb[ETHTOOL_A_RSS_HFUNC], &mod);
+ if (rxfh.hfunc == data.hfunc)
+ rxfh.hfunc = ETH_RSS_HASH_NO_CHANGE;
I think that this is a distinction that we don't currently make in the
drivers/ioctl flow.
NO_CHANGE was specifically used for cases where the user didn't specify
a parameter, not for cases where the request is equal to the configured one.
mlx5 for example, performs this check internally because it can't rely
on NO_CHANGE for requested == configured.
Yeah, no strong preference. We have to live with the ioctl path so
the drivers will need to keep handling all corner cases. In this case
I chose behaving somewhat consistently with the ioctl behavior (assuming
user space is well behaved).
There's no harm in passing NO_CHANGE in such cases, but it is not
something that the driver developers will be able to rely on. There's a
certain risk of someone assuming ioctl will behave the same.