On 14/07/2025 19:29, Jakub Kicinski wrote:
On Sun, 13 Jul 2025 14:12:33 +0300 Gal Pressman wrote:
quoted
On 11/07/2025 4:53, Jakub Kicinski wrote:
quoted
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" ?
So it's different because you can use netlink directly to change both,
but from userspace ethtool perspective there's no difference, right?
It's still two commands.
Makes sense, thanks for the explanation.
quoted
quoted
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@kernel.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.
Why do we need to differentiate where the mod originated? We have a
single return value.